Make DRM plane-assignment algorithm tolerant of more than one fullscreen opaque surface?

[Daniel Stone]

Hi Matt,

On 12 August 2017 at 12:18, Matt Hoosier <matt.hoosier at gmail.com> wrote:
> Any interest (this is probably mostly a question for Daniel)?

Sorry, I've been travelling the past few days.

> On Thu, Aug 10, 2017 at 1:41 PM, Matt Hoosier <matt.hoosier at gmail.com>
> wrote:
>> Currently the DRM backend ends up picking the bottom-most view which meets
>> all the checks for eligibility, for direct scanout usage. If more than one
>> such view exists, we get a visual result counter to expectations -- it
>> should be the highest-sorted such view that the user sees.
>>
>> The big loop in drm_assign_planes() that assigns views to planes iterates
>> top-down through the weston_layer's, and the particular way that the results
>> are progressively stored in variables means that if more than one pass
>> through the loop encounters a view which is fullscreen and opaque then the
>> last (bottom-most) of these passes is the one whose results are preserved
>> upon exit from the loop.
>>
>> This normally isn't a problem because mostly only the desktop shell has a
>> notion of fullscreen surfaces. desktop-shell takes care (whether
>> intentionally or not I can't tell) that when running full-screen only the
>> logical topmost view is actively left in a visible weston_layer.
>>
>> Is it informally expected that the shell must not allow more than one
>> fullscreen view at a time? Would there be interest in a patch to
>> drm_assign_planes() that adds a bit more awareness to the plane assignment
>> so that only the topmost fullscreen opaque view is picked for scanout?

No, that's all the way broken. I assume the only way this hasn't yet
bitten us is that the background in stock desktop-shell is a SHM-only
client, so won't get promoted to a plane.

That should be fixed in the atomic branch though, AFAICT. I'd happily
review a discrete fix, but if you can hold on then it should already
(hopefully) be fixed.

Cheers,
Daniel