[PATCH v21 2/4] compositor-drm: Allow scanout plane to be occluded by overlay

[Daniel Stone]

Hi,

On Wed, 11 Jul 2018 at 14:07, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Wed, 11 Jul 2018 13:16:18 +0100 Daniel Stone <daniels at collabora.com> wrote:
> > @@ -3426,17 +3426,6 @@ drm_output_propose_state(struct weston_output *output_base,
> >               if (pixman_region32_not_empty(&surface_overlap))
> >                       force_renderer = true;
> >
> > -             /* We do not control the stacking order of overlay planes;
> > -              * the scanout plane is strictly stacked bottom and the cursor
> > -              * plane top, but the ordering of overlay planes with respect
> > -              * to each other is undefined. Make sure we do not have two
> > -              * planes overlapping each other. */
> > -             pixman_region32_intersect(&surface_overlap, &occluded_region,
> > -                                       &clipped_view);
> > -             if (pixman_region32_not_empty(&surface_overlap))
> > -                     force_renderer = true;
> > -             pixman_region32_fini(&surface_overlap);
> > -
> >               /* The cursor plane is 'special' in the sense that we can still
> >                * place it in the legacy API, and we gate that with a separate
> >                * cursors_are_broken flag. */
>
> Does this not introduce a failure mode that we get wrong z-order if an
> overlay was supposed to occlude a view that's otherwise eligible for
> the cursor plane?

It certainly does, which I seem to have noticed at the exact same time
as you. v21.1 replaces this with a separate 'view is partly occluded
by plane' bool: we don't attempt to place a cursor (cursor plane must
be above) or overlay (relative stacking order undefined) plane if this
bool is set, but we do let scanout go on.

Cheers,
Daniel