Mario Limonciello <[email protected]> writes: Hello Mario,
> 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. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
