On 2021-03-11 1:10 p.m., Simon Ser wrote: > 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. This is why I wrote "Houston, we have a problem". I only realized at that point that we've painted ourselves into an uncomfortable corner. > 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. -- 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
