On Thu, Nov 08, 2018 at 03:00:58PM +0200, Pekka Paalanen wrote: > On Wed, 07 Nov 2018 20:22:38 +0000 > Simon Ser <[email protected]> wrote: > > > Thanks! With these fixes, this is now > > > > Reviewed-by: Simon Ser <[email protected]> > > > > 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
