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