[PATCH wayland-protocols v4] Add zwp_linux_explicit_synchronization_v1

[Simon Ser]

On Monday, November 5, 2018 10:50 AM, Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:
> 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.

It's not uncommon to refer to the not-yet-existing stable versions of the
protocols in their unstable versions.

If you think all DMA-BUFs can use this protocol, use wp_linux_dmabuf. If it only
applies to the unstable-v1 protocol, use zwp_linux_dmabuf_v1.

> > > > > +    <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.

Okay. In this case we need to make it clear which events make the compositor
destroy the object. See for instance the wl_surface.frame description:

    The object returned by this request will be destroyed by the
    compositor after the callback is fired and as such the client must not
    attempt to use it after that point.