Re: [PATCH v8 00/14] Add support for a DRM backlight capability

[Mario Limonciello <mario.limonciello@amd.com>]

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
>>>>>>> <mario.limonciello@amd.com> 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.