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
signature.asc
Description: PGP signature
