On Thu, Oct 01, 2026 at 06:55:24PM +0200, Javier Martinez Canillas wrote: > Mario Limonciello <[email protected]> writes: > > 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. > > > > That is indeed a very good idea IMO. Just depends on !BACKLIGHT_CLASS_DEVICE > and ensure that no existing user of the sysfs get affected by this new API.
Yep, sounds great Maxime
signature.asc
Description: PGP signature
