On 10/1/26 11:06, Maxime Ripard wrote:
On Wed, Sep 23, 2026 at 08:39:33AM +0200, Thomas Zimmermann wrote:
Am 22.09.26 um 14:35 schrieb Maxime Ripard:
On Tue, Sep 22, 2026 at 02:23:17PM +0200, Thomas Zimmermann wrote:
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?
It probably would, but it would create a precedent I'm not really
familiar with. Hotplug events are kind of separate because it really is
a hardware event most of the time: you get an interrupt, and report it
to userspace. And it's largely outside of the properties space (except
maybe for things like edid).
If we start having the argument that a property changing must trigger a
uevent, then it means that we can expect *any* property to do so, and
"the compositor needs to be in control of it" can apply to many, like
color formats, positions, tiling, etc.
I'd explicitly not treat this like a change to the DRM property. More like
as if the user pressed a hardware button. The property update only comes
later from what ever the compositor does with the event.
I don't think that would work unfortunately, because then that means
that any system that used to rely on sysfs but wouldn't handle that new
event (however it is sent) would effectively have a regression.
That being said, it does look like we already notify userspace on
property change for HPCD, so maybe it's not too bad.
Maxime
Earlier iterations of my development of the series had a userspace
notification. It was very heavy. The problem is that your DE may
change a brightness in a slider and try to smooth it out and then that
turns into hundreds of calls to notify userspace.
It was heavy enough that it lagged on a beefy system. I don't think
this direction makes sense unless it was rate limited.
