Hi Pekka, On 16 May 2017 at 11:32, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Tue, 16 May 2017 11:02:22 +0100 > Daniel Stone <dani...@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.paala...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev