On Friday, September 9th, 2022 at 15:53, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > On Fri, 09 Sep 2022 13:39:37 +0000 > Simon Ser contact@xxxxxxxxxxx wrote: > > > On Friday, September 9th, 2022 at 12:12, Hans de Goede hdegoede@xxxxxxxxxx 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.)
