[PATCH wayland-protocols v4] Add zwp_linux_explicit_synchronization_v1

[Alexandros Frantzis]

On Sat, Nov 03, 2018 at 02:44:53PM +0000, Simon Ser wrote:

Hi Simon,

> > > > +      Explicit synchronization is guaranteed to be supported only for buffers
> > > > +      created with any version of the zwp_linux_dmabuf buffer factory.
> > >
> > > I think we can drop the "z" prefix here.
> >
> > Hmm, not sure about this. We would be using a protocol prefix/name
> > combination that doesn't exist (yet). Of course the intention is clear,
> > but I think it would be better to update this to, e.g.,
> > (z)wp_linux_dmabuf, when linux_dmabuf actually becomes stable.
> 
> Then add the v1 suffix zwp_linux_dmabuf_v1?

The "any version" of zwp_linux_dmabuf was meant to cover both _v* and
version="*", but I guess that's not clear enough. Perhaps "with any
version of zwp_linux_dmabuf_v*"? In any case, I am also fine with just
adding _v1 for now and updating as needed in the future.

> > > > +    <event name="fenced_release">
> > > > +      <description summary="release buffer with fence">
> > > > +        Sent when the compositor has finalised its usage of the associated
> > > > +        buffer for the relevant commit, providing a dma_fence which will be
> > > > +        signaled when all operations by the compositor on that buffer for that
> > > > +        commit have finished.
> > > > +
> > > > +        Clients must not perform any destructive operations (e.g. clearing or
> > > > +        rendering) on the buffer until that fence has signaled.
> > >
> > > We should probably add to this request and to immediate_release something among
> > > the lines of:
> > >
> > > > Upon receiving this event, the client should destroy this object.
> >
> > In v5 I am changing zwp_buffer_release to use destroy-on-event, so this
> > doesn't apply any more. Of course, the client should still destroy the
> > proxy, but I don't think this is something we need to explicitly state.
> 
> Hmm. One should be careful when choosing destroy-on-event, it makes it
> impossible to add requests to the interface later on.

We discussed a bit about this in an earlier email, and the conclusion
was that buffer_release is expected to remain a pure event interface.
It's not expected to gain any requests, or to be used as an argument to
other requests. Of course, if people have any such use cases in mind I
would be happy to hear about them and discuss further.

Thanks,
Alexandros