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

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

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.

> 
> 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%.

The hardware would be left at 0%.  I press the brightness up key (or 
call brightnessctl) and I can't change it because backlight subsystem is 
100% already.

So it can't be a clean rip and replace; you need to keep both active at 
least for a while.
> 
> It would be better if the hardware specific logic to do the brightness
> control is factored out and used by both the struct
> backlight_ops.update_status and the atomic modesetting state check /
> commit.
> 
> --
> Best regards,
> 
> Javier Martinez Canillas
> Core Platforms
> Red Hat