[PATCH wayland-protocols v6] Add zwp_linux_explicit_synchronization_v1

[Alexandros Frantzis]

On Thu, Nov 08, 2018 at 03:00:58PM +0200, Pekka Paalanen wrote:
> On Wed, 07 Nov 2018 20:22:38 +0000
> Simon Ser <contact at emersion.fr> wrote:
> 
> > Thanks! With these fixes, this is now
> > 
> > Reviewed-by: Simon Ser <contact at emersion.fr>
> > 
> > Below is a small comment, I don't know if it's relevant or not, I just wanted to
> > point it out.
> > 

...

> > > +  <interface name="zwp_surface_synchronization_v1" version="1">  
> > 
> > I missed this before, but: is there a reason why the "linux" prefix has been
> > dropped here? Maybe it should be renamed to
> > zwp_linux_surface_synchronization_v1? What about zwp_buffer_release_v1?
> 
> That's a good question, because these names are kind of global. Not
> really global, but it could cause some name conflicts if the same
> program or a compilation unit needed to use two different but
> same-named interfaces. They are less global than the same of the global
> interface though, which needs to be unique per platform for real.
> 
> The stable names would be wp_surface_synchronization and
> wp_buffer_release, with the root interface being
> wp_linux_explicit_synchronization.
> 
> The dmabuf extension relies of the Linux definition of a dmabuf. This
> extension relies on the Linux definition of a fence, AFAIU.
> 
> So yes, I think repeating "linux" in the interface names would be
> appropriate.

Hi Pekka and Simon,

adding the linux_ prefix is reasonable (and means we could be winning at
the longest interface name competition :)).

This got me thinking (also see Daniel's email), though, if there would
be benefit in moving in the other direction: making this protocol
agnostic of the fence type details. So, instead of
"zwp_linux_explicit_synchronization_v1" we will have
"zwp_explicit_synchronization_v1" with the passed fd being an opaque fd
from a protocol perspective.

Of course, this reintroduces the problem of how the client can figure
out what kind of buffer/fence combinations the server can accept, which
we have resolved here by limiting this protocol to dmabuf/dma_fences.
One way would be to allow per-platform protocols that just advertise
supported combinations, e.g., having
"zwp_linux_explicit_synchronization_v1" just means that the
dmabuf/dmafence combo is supported for zwp_explicit_synchronization
operations.

Finally, if we think an opaque fd may be limiting, there are other
options to explore (e.g., a zwp_fence interface with factories in
per-platform extensions).

Thoughts?

Thanks,
Alexandros