[PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1
alexandros.frantzis at collabora.com
Tue Nov 27 16:25:04 UTC 2018
On Tue, Nov 27, 2018 at 05:17:40PM +0200, Alexandros Frantzis wrote:
> On Tue, Nov 27, 2018 at 10:53:45AM +0200, Pekka Paalanen wrote:
> > Yes, we probably should have some wording that if a client is letting
> > something like EGL to commit the buffers, it must not attempt to use
> > the fence extension on that wl_surface itself because EGL will probably
> > be using the extension already.
> > Alf?
> Hi Pekka and Tomek,
> I will send a patch with a proposal for the discussed wording updates to
> the list soon (probably tomorrow).
> I agree it's fine for the spec to be relaxed for the opaque EGL buffers.
> As Pekka mentioned, we explicitly limited the spec to support only
> zwp_linux_dmabuf to avoid the problem of having to deal with unsupported
> buffer/fence combinations, and opaque EGL buffers are not likely to pose
> problems in this regard.
Note that this will require a v2 of this protocol since we will be
requiring more from implementations compared to v1 (unless we can cheat
and not bump?). The current protocol says:
"Explicit synchronization is guaranteed to be supported only for buffers
created with any version of the wp_linux_dmabuf buffer factory."
which upon rereading isn't clear enough about if implementations are
required to support *only* linux_dmabuf, or if implementations need
to support *at least* linux_dmabuf.
If we don't want to commit to general opaque EGL buffer support,
perhaps an option here would be to change this to the more clear:
"Explicit synchronization is only guaranteed to be supported for buffers
created with any version of the wp_linux_dmabuf buffer factory, but
implementations are free to also support it for other buffer types."
This allows us to stay at v1 without explicitly naming out opaque EGL
buffers, while still allowing Weston to support opaque EGL buffers.
I guess it depends if we think the explicit sync + opaque EGL buffer
case will be interesting enough to be used outside of environments with
a controlled compositor and clients.
More information about the wayland-devel