On Wed, Apr 01, 2026 at 01:25:31PM +0100, Daniel Stone wrote: > On Wed, 1 Apr 2026 at 13:11, Ville Syrjälä > <[email protected]> wrote: > > I think the idea of some kind of feedback properties in the atomic > > commit has come up before, but no one has ever tried to implement them. > > Yeah, if you're looking for context on these, the last place I > remember it coming up was wanting to know which other objects would > potentially be dragged into a commit. For example, on ye olde (?) > Intel platforms, if programming a different mode is actually > stop-the-world where all other CRTCs get affected by a CDCLK change, > being able to know that those other CRTCs would be affected before it > happens, rather than random -EBUSY after the fact.
For the success cases I think it should be pretty straightforward to just walk the props in the commit again after the atomic check and write back all the feedback values from the computed state. I think adding this for error cases would be much harder. We'd have to somehow make sure the value(s) we write back to userspace are at least somewhat valid even though the state check may have failed half way through. Although that specific -EBUSY you mention I think is checked after the actual atomic check, so it would work there. Assuming we'd have a place for eg. the affected crtcs bitmask in the ioctl structure... And speaking of which, if you'll permit me to go off on another tangent, I have occasionally pondered introducing per-device properties. We could introduce a new object type for the whole device, and add a new enumeration thing to find it. Then per-device properties could be added to atomic commits exactly like any other properties. My original idea was to use this for some kind of device wide "power vs. performance" knob, but it could also be used for this affected crtcs bitmask feedback. -- Ville Syrjälä Intel
