On Thu, 8 Nov 2018 16:34:52 +0200 Alexandros Frantzis <[email protected]> wrote:
> 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). Hi Alf, I'd keep it simple. Leave out other fence types until we have a use case. It's still an unstable protocol, and we can see if other types appear by the time people want to declare it stable. An opaque fd is kind of useless. If the spec does not say what it is, how could a compositor or a client do anything with it? You could get away with an opaque fd, if the spec could say which API the compositor and client needs to use to get/use the fd. But then we're essentially back to saying it's a Linux DRM sync_file thingy in this case. We could have an opaque fd with an enum saying what it is. But that brings complication: how do you pick or know which one to use. Do you have to support all the kinds. One option would be to say the fd is platform specific. An example of such (attempt) is in wp_presentation.clock_id. The multiple factory interfaces approach has the caveat that the interface will be stuck at version 1 then and cannot realistically ever be extended. If in some case the fence was not an fd, then there would be nothing to share anyway. Also the interface already defines that the fences are one-shot, so it would not be appropriate for the semaphores Daniel mentioned. Adding new factory methods in the global interface is possible though, and will not pose a versioning problem. We can also add new requests and events for new types of fences in a perfectly backwards-compatible fashion. For simplicity, I'd go with "linux" in the name and the explicit connection with linux_dmabuf buffers. Thanks, pq
pgp5x6D8b6MGV.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
