On Tue, Sep 22, 2026 at 06:34:51AM -0500, Mario Limonciello wrote: > > > On 9/22/26 03:49, Javier Martinez Canillas wrote: > > On Tue, Sep 22, 2026 at 10:24 AM Thomas Zimmermann <[email protected]> > > wrote: > > > > > > Hi Mario > > > > > > Am 08.09.26 um 06:40 schrieb Mario Limonciello: > > > > So far backlights have only been controlled via sysfs. However, sysfs is > > > > not a proper user-space API for runtime modifications, and never was > > > > intended to provide such. The DRM drivers are now prepared to provide > > > > such a backlight link so user-space can control backlight via DRM > > > > connector properties. This allows us to employ the same > > > > access-management > > > > we use for mode-setting. > > > > > > > > This patch adds a few kernel-internal backlight helpers so we can modify > > > > backlights from within DRM, a brightness-changed notification, and a > > > > per-device takeover count so that legacy sysfs writes can be inhibited > > > > (-EBUSY) while a luminance-aware DRM client is in control. > > > > > > > > Signed-off-by: David Herrmann <[email protected]> > > > > > > > > [...] > > > > > > @@ -150,6 +153,13 @@ static ssize_t bl_power_store(struct device *dev, > > > > struct device_attribute *attr, > > > > struct backlight_device *bd = to_backlight_device(dev); > > > > unsigned long power, old_power; > > > > > > > > + /* A luminance-aware DRM client has taken over this backlight; the > > > > + * legacy sysfs interface is disabled until the last such client > > > > + * goes away. > > > > + */ > > > > + if (atomic_read(&bd->drm_takeover) > 0) > > > > + return -EBUSY; > > > > + > > > > rc = kstrtoul(buf, 0, &power); > > > > if (rc) > > > > return rc; > > > > @@ -214,6 +224,13 @@ static ssize_t brightness_store(struct device *dev, > > > > struct backlight_device *bd = to_backlight_device(dev); > > > > unsigned long brightness; > > > > > > > > + /* A luminance-aware DRM client has taken over this backlight; the > > > > + * legacy sysfs interface is disabled until the last such client > > > > + * goes away. > > > > + */ > > > > + if (atomic_read(&bd->drm_takeover) > 0) > > > > + return -EBUSY; > > > > > > Can you really do that? AFAIU sysfs is now a de-facto uapi for > > > backlights. > > > > And regardless if this can be done or not, I belive that would be > > better if this is something that drivers decide to do and just return > > -EBUSY from their struct backlight_ops..update_status. > > > > Ideally the sysfs interface should continue to be work as Thomas said > > and a write could trigger a mode set for example, but I don't know if > > that is feasible to do due locking. > > > > Well the problem ends up being that something can change brightness behind > the compositor's back if you leave sysfs available. > > The whole design here is to put the compositor in control. For example if > compositor wants to enforce brightness to be a certain value when certain > content is being displayed.
I don't see how you can solve this. The sysfs interface already shows this behaviour, so it's not a regression or anything. That being said, one way to mitigate this would be to consider the sysfs backlight interface as legacy and disable it by default. Maxime
signature.asc
Description: PGP signature
