[ Adding Daniel again ] 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? > 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. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
