[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