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. In practice we can probably support all buffers that can be imported into the graphics API without requiring a client-side wait in the compositor ("client" from a graphics API perspective) for proper use, but that's harder to specify. There were discussions about allowing everything other than wl_shm, but we decided against it, since that would make the protocol too fragile. Relaxing the spec further will probably require more radical changes, though, e.g., advertising supported buffer types, or similar. I will also add some notes/warnings about using this protocol with graphics APIs that handle buffers internally. This is also a good chance to propose some other clarifications to the spec I have been thinking about. Thanks, Alexandros _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel