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. It would be a much saner design to put it behind DRM_MASTER, and deprecate the sysfs interface entirely. Maxime
signature.asc
Description: PGP signature
