> 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.
> 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. > 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. - Xaver
