On Thursday, March 11th, 2021 at 10:05 AM, Michel Dänzer <michel@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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). _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
