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