On Wednesday, March 17th, 2021 at 9:32 AM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > On 2021-03-17 9:21 a.m., Simon Ser wrote: > > On Thursday, March 11th, 2021 at 3:13 PM, Michel Dänzer <michel@xxxxxxxxxxx> wrote: > > > >>> I'm not a fan of adding kernel hacks like setting up a transparent FB, when > >>> user-space can just avoid the failure with atomic test-only commits (and e.g. > >>> use the overlay to display the cursor image instead of the cursor plane). > >> > >> I'm not a fan of requiring each atomic client to handle this complexity. > > > > That's just how atomic works though. User-space is expected to incrementally > > build the atomic request, bailing out if something doesn't work along the way. > > Being unable to disable a plane which is currently enabled is quite different > from being unable to enable a plane which is currently disabled. How is user > space supposed to react to that, other than maybe disabling everything and > starting from scratch? What I mean by "singular atomic commit" is an atomic commit that tries to change a single thing, and expects that to just work. Whether it's about disabling a plane or not doesn't matter much from my point of view. For instance, maybe scaling is enabled and user-space wants to disable scaling, but the driver can't? This would be surprising to user-space because "user-space is just trying to disable $feature", just like the the case we're talking about. > > Doing it the old way (ie. issuing singular atomic commits, ie. using the atomic > > API just like the legacy API is used) won't work in many situations anyways. > > This isn't about that, not sure why you keep bringing it up. Well, a client that incrementally builds the full atomic commit (like Weston and libliftoff) won't have this issue. _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
