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

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

On 10/1/26 11:18, Maxime Ripard wrote:
> On Wed, Sep 23, 2026 at 10:07:16AM +0200, Xaver Hugl wrote:
>>> 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.
>>
>> That could cause stutter.
> 
> Is it really that bad? I mean, it would be only in scenarios where the
> legacy API is being used and I would expect it to become the standard
> pretty fast anyway, no?
> 
>>> 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 there's any property changes, userspace does need to be notified
>> about it. Whether the change is caused by hardware or software doesn't
>> matter.
> 
> Yeah, it turns out we already have a precedent for this for HDCP so it's
> not too bad I guess.
> 
>>> 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
>> For anything modified outside of the compositor's control, yes.
>>
>> The client cap avoids needing uevents for the luminance property
>> though, since backlight control is exclusive to DRM if the compositor
>> supports it.
>>
>>> "the compositor needs to be in control of it" can apply to many, like
>>> color formats, positions, tiling, etc.
>>
>> If there were other APIs that desktops relied on for controlling color
>> formats and similar, we would indeed also need a client cap for those
>> things, until definitely all software is ported away from the old API.
> 
> I really think this series should be split. We obviously need to address
> this, but it's kind of decoupled from the UAPI itself, and is only
> relevant for a small subset of its usage. And yet it's all we talk
> about. It'll be easier to merge in chunks and decoupling the legacy API
> handling from the new uapi.
> 
> Maxime

How would you feel about a (temporary) Kconfig that lets you pick which 
API to support?  This would effectively mean that we can get the new 
UAPI integrated without worrying about implications for the legacy API.

We can then get compositors all lined up to use the the new API and then 
bikeshed the compat between the two to let us drop the Kconfig.