[PATCH v2 0/5] amd/display: improve atomic cursor checks

[Simon Ser]

On Wednesday, March 17th, 2021 at 9:32 AM, Michel Dänzer <michel at daenzer.net> 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 at daenzer.net> 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.