Hi, On Wed, 11 Jul 2018 at 14:07, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Wed, 11 Jul 2018 13:16:18 +0100 Daniel Stone <dani...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
