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

[Simon Ser]

On Friday, September 9th, 2022 at 15:53, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Fri, 09 Sep 2022 13:39:37 +0000
> Simon Ser contact at emersion.fr wrote:
> 
> > On Friday, September 9th, 2022 at 12:12, Hans de Goede hdegoede at 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.

Ah yes, that's a good point. And this wouldn't be a kernel regression,
it would be user-space like Sway or Weston taking the decision to use
the new uAPI in a way which breaks the sysfs interface.

(User-space could also take the decision to _not_ break the sysfs
interface, by implementing a simple "dirty" flag.)