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.
