[PATCH v2 0/5] amd/display: improve atomic cursor checks
Simon Ser
contact at emersion.fr
Thu Mar 11 12:10:26 UTC 2021
On Thursday, March 11th, 2021 at 10:05 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 2021-03-11 9:57 a.m., Simon Ser wrote:
> > On Wednesday, March 10th, 2021 at 6:20 PM, Michel Dänzer <michel at daenzer.net> wrote:
> >> On 2021-03-10 3:50 p.m., Simon Ser wrote:
> >>
> >>> Changes in v2: drop "amd/display: fail on cursor plane without an
> >>> underlying plane". This retains the current behavior instead.
> >>
> >> Patches 2 & 3 (and possibly 4? not sure) would still cause the same
> >> issue in the scenario discussed in follow-ups to the dropped patch
> >> (disabling an ARGB overlay plane with a YUV primary plane and the
> >> cursor plane enabled), wouldn't they?
> >
> > Yes, but that shouldn't be too much of an issue in practice, since
> > user-space using YUV and overlays also uses atomic. Dropping the patch
> > avoids the issue to be triggered with legacy user-space.
>
> The last scenario discussed is about atomic KMS user space trying to disable
> the overlay plane. Daniel seems to agree that not being able to disable an
> overlay plane is too surprising.
Well, amdgpu can already return a failure if user-space tries to disable the
overlay:
- User-space sets up the primary plane with a scaled FB.
- User-space enables the overlay and cursor planes without scaling.
- User-space tries to disable the overlay, kernel returns a failure because a
non-scaled cursor is incompatible with a scaled underlying plane.
So this series just adds a new error condition.
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).
More information about the amd-gfx
mailing list