Hi
Am 22.09.26 um 14:16 schrieb Maxime Ripard:
On Tue, Sep 22, 2026 at 06:41:32AM -0500, Mario Limonciello wrote:
On 9/22/26 03:33, Javier Martinez Canillas wrote:
Hello Mario,
On Tue, Sep 8, 2026 at 6:41 AM Mario Limonciello
<[email protected]> wrote:
At Display Next Hackfest 2026 we reviewed progress moving brightness
control into the DRM connector properties.
There is a range LUMINANCE property that will default to 0->0.
Once a driver attaches a backlight it will be updated to 1->max.
If the panel supports the minimum backlight turning off the display
the range can later be updated to 0->max instead of 1->max.
The legacy sysfs interface is synchronized with the DRM connector.
When a compositor using this feature is loaded, sysfs writes are disabled
to prevent legacy tools from going out of sync with the compositor.
I don't think I agree with the direction of this series. The main
issue for me is that if the sysfs interface is disabled, then I don't
understand the value of doing all the hops between the DRM and
backlight subsystems...
The reason for all the hops is that users can switch between compositors
that support this and don't. If you're in a compositor that supports it
that compositor will want to affirm it's in control. If you're in a
compositor without support then you should still have a way to change
things, and that's what the sysfs interface exists for.
Couldn't we make a sysfs write trigger an atomic commit then? That way,
it would always go through the atomic commit path, no matter whether
you're on a "legacy" compositor or not.
It would also somewhat untangle the uapi from the backlight subsystem,
because it's only really relevant for panels. For all the other use
cases, you might want to control the brightness but you have no matching
backlight device.
I suggested to treat these backlight changes like display-hotplug
events. When it happens, we'd send a uevent to user space, so it can
update its internal state. Such an event could then come from any
source besides backlight's sysfs. Compositors could also implement
policies that are currently implicit in this series, such as brightness
of 0 means "display off". This is likely something a compositor should
track.
Would that work?
Best regards
Thomas
IMO when a driver sets the DRIVER_CONNECTOR_LUMINANCE feature and the
client advertise the DRM_CLIENT_CAP_LUMINANCE capability, then the DRM
driver should be in full control of the brightness control and not go
through the backlight subsystem at all.
OK but so let's say I start at 100% brightness. I open up Kwin, I change
the luminance property to 0%. Let's pretend that backlight subsystem
doesn't get updated.
Then I log into Xorg + Xfce. The luminance property should be left at 0%,
the brightness subsystem is 100%.
Make backlight read the current property then.
The way I see it, you're trying to untangle multiple issues at once, and
I'm not sure it's the best strategy here. I'd start with the luminance
property itself that wouldn't involve the backlight framework itself
(DDC/CI or MIPI-DCS sound like obvious candidates here), and once it's
in, I would figure out the relationship between backlight and that property.
Maxime
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, (HRB 36809, AG Nürnberg)
