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

Michel Dänzer michel at daenzer.net
Thu Mar 11 14:13:47 UTC 2021


On 2021-03-11 1:10 p.m., Simon Ser wrote:
> 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.

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


More information about the amd-gfx mailing list