[Mesa-dev] [PATCH] egl/wayland: Ensure we get a back buffer

Daniel Stone daniel at fooishbar.org
Tue May 16 10:48:53 UTC 2017


Hi Pekka,

On 16 May 2017 at 11:32, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Tue, 16 May 2017 11:02:22 +0100
> Daniel Stone <daniels at collabora.com> wrote:
>> This removed a guarantee that we would've processed all events inside
>> get_back_bo(), and introduced a failure whereby the server could've sent
>> a buffer release event, but we wouldn't have read it. In clients
>> unconstrained by SwapInterval (rendering ~as fast as possible), which
>> were being displayed on a hardware overlay (buffer release delayed),
>
> hardware overlay, or as in the bug report, on the primary plane, i.e.
> the only composite-bypass case in pre-atomic Weston available without
> hacks.

Sure, I'll amend to make this clear before pushing.

>> @@ -364,6 +364,14 @@ get_back_bo(struct dri2_egl_surface *dri2_surf)
>>           else if (dri2_surf->back->dri_image == NULL)
>>              dri2_surf->back = &dri2_surf->color_buffers[i];
>>        }
>> +
>> +      if (dri2_surf->back)
>> +         continue;
>
> Would 'break' be more readable?

Yes, much more readable.

>> +      /* If we don't have a buffer, then block on the server to release one for
>> +       * us, and try again. */
>> +      if (wl_display_dispatch_queue(dri2_dpy->wl_dpy, dri2_surf->wl_queue) < 0)
>> +          return -1;
>>     }
>>
>>     if (dri2_surf->back == NULL)
>
> The swrast path does not need fixing, because there buffer release can
> never be delayed due to composite bypass, right?
>
> Nothing looks suspicious to me, so:
> Acked-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>

Right, I can't imagine how swrast would have all four buffers held at
once; it probably should be fixed, and I can do that, but equally I
can't test it, so.

Cheers,
Daniel


More information about the mesa-dev mailing list