Re: [RFC v2] drm/kms: control display brightness through drm_connector properties

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

On Fri, 09 Sep 2022 13:39:37 +0000
Simon Ser <contact@emersion.fr> wrote:

> On Friday, September 9th, 2022 at 12:12, Hans de Goede <hdegoede@redhat.com> wrote:
> 
> > Phase 3: Deprecate /sys/class/backlight uAPI
> > ============================================
> > 
> > Once most userspace has moved over to using the new drm_connector
> > brightness props, a Kconfig option can be added to stop exporting
> > the backlight-devices under /sys/class/backlight. The plan is to
> > just disable the sysfs interface and keep the existing backlight-device
> > internal kernel abstraction as is, since some abstraction for (non GPU
> > native) backlight devices will be necessary regardless.
> > 
> > It is unsure if we will ever be able to do this. For example people using
> > non fully integrated desktop environments like e.g. sway often use custom
> > scripts binded to hotkeys to get functionality like the brightness
> > up/down keyboard hotkeys changing the brightness. This typically involves
> > e.g. the xbacklight utility.
> > 
> > Even if the xbacklight utility is ported to use kms with the new connector
> > object brightness properties then this still will not work because
> > changing the properties will require drm-master rights and e.g. sway will
> > already hold those.  
> 
> I replied to this here in another thread [1].
> 
> tl;dr I think it would be fine even for Sway-like compositors.

Furthermore, if other compositors are like Weston in their KMS state
handling, and do not track which property has already been programmed
to KMS and which hasn't, and instead just smash all KMS properties
every update anyway (it's also great for debugging, you always have the
full state in flight), anything changed via sysfs will be immediately
reverted.

Therefore I think there is a high probability that the external or
sysfs controls just naturally stop working anyway, even if the kernel
does not remove them first.


Thanks,
pq


> (Also note the utilities used right now are not xbacklight, but
> brightnessctl/light/brillo/etc [2])
> 
> [1]: https://lore.kernel.org/dri-devel/bZJU9OkYWFyaLHVa4XUE4d5iBTPFXBRyPe1wMd_ztKh5VBMu-EDNGoUDpvwtFn_u9-JMvN8QmIZVS3pzMZM_hZTkTCA9gOBnCGXc5HFmsnc=@emersion.fr/
> [2]: https://github.com/swaywm/sway/wiki#xbacklight
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]