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

2018-07-11 Thread Daniel Stone
Hi,

On Wed, 11 Jul 2018 at 14:07, Pekka Paalanen  wrote:
> On Wed, 11 Jul 2018 13:16:18 +0100 Daniel Stone  wrote:
> > @@ -3426,17 +3426,6 @@ drm_output_propose_state(struct weston_output 
> > *output_base,
> >   if (pixman_region32_not_empty(_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(_overlap, _region,
> > -   _view);
> > - if (pixman_region32_not_empty(_overlap))
> > - force_renderer = true;
> > - pixman_region32_fini(_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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2018-07-11 Thread Pekka Paalanen
On Wed, 11 Jul 2018 13:16:18 +0100
Daniel Stone  wrote:

> a0f8276fe814 ("compositor-drm: Disallow overlapping overlay planes") was
> a little too pessimistic in rejecting occluded views. Whilst it
> correctly prevented overlay planes from occluding each other, it also
> prevented overlay planes from occluding the scanout plane.
> 
> This is undesirable: the primary/scanout plane is specified to stack
> strictly below all overlay planes, so there is no need to reject a plane
> from consideration for scanout due to being occluded by an overlay
> plane.
> 
> Shift the check downwards so it only applies to overlay rather than
> scanout planes.
> 
> Signed-off-by: Daniel Stone 
> ---
>  libweston/compositor-drm.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index d192eec16..3d1847790 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -3426,17 +3426,6 @@ drm_output_propose_state(struct weston_output 
> *output_base,
>   if (pixman_region32_not_empty(_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(_overlap, _region,
> -   _view);
> - if (pixman_region32_not_empty(_overlap))
> - force_renderer = true;
> - pixman_region32_fini(_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?


Thanks,
pq

> @@ -3457,6 +3446,18 @@ drm_output_propose_state(struct weston_output 
> *output_base,
>* scanout plane. */
>   if (!ps && !force_renderer && !renderer_ok)
>   ps = drm_output_prepare_scanout_view(state, ev, mode);
> +
> + /* 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(_overlap, _region,
> +   _view);
> + if (pixman_region32_not_empty(_overlap))
> + force_renderer = true;
> + pixman_region32_fini(_overlap);
> +
>   if (!ps && !force_renderer)
>   ps = drm_output_prepare_overlay_view(state, ev, mode);
>  



pgp1rM4x2AX59.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel