Hi Emil, On 2 November 2017 at 17:09, Emil Velikov <[email protected]> wrote: > Import latest version (v2) of the protocol from Mesa. > > From the README: > > Warning! > The goal is to share the protocol file across Mesa and other low-level > components graphics stack such as libva and Xwayland. File is moved to > wayland-protocols for sharing purposes _only_. > > The protocol is _not_ for public use. Furthermore Mesa and others consider > the protocol as deprecated over wl_dmabuf.
I suspect the sheer fact that we've recently added it as a stable published protocol would be enough for people to ignore that objection. I have to say that I'm still against this one, for a few reasons. Firstly, yes, VA-API got it wrong: there's no way it should be using unpublished private protocol. Luckily, newer versions of VA-API and the GStreamer integration now have both proper dmabuf integration as well as the notion of simply exporting buffers rather than trying to be a presentation _and_ decoding layer in one, so using a VA-API decoder piped to waylandsink is enough to get it working without wl_drm ever being used. Happy days. (Xwayland is in the same boat: lfrb's patches mean it can use dmabuf instead.) Secondly, apart from VA-API, it's not used generically. It gets published as a side effect of Mesa calling eglBindWaylandDisplayWL(), and the Mesa client code (both in libEGL.so, though the two versions can indeed get out of sync) uses it. Compositors don't explicitly advertise it, and again for the most part clients don't use it. What I worry is that, if we publish it, clients _will_ come to use it despite the warnings, and Mesa will never be able to stop advertising it. Having it be private/unpublished protocol is an implementation detail, but with a published protocol doc, the fact Mesa advertises it will come to be seen as ABI instead. I really, really, don't want to paint ourselves into that corner: wl_drm has always been an awkward special case, but I'd much prefer to kill it off than enshrine its position. There is one gap which zwp_linux_dmabuf_v1 doesn't fill, which is passing a device handle for the composition GPU, as well as maybe another for the scanout device. That would give the allocator enough information to determine correct buffer placement and so on. But if we ignore placement as we do today, just having format + modifiers would be enough for both EGL/Vulkan and VA-API clients which were aware of modifiers to work properly. Drivers without modifiers would still need the GPU device passed down so they can decide which magic tiling mode to use, but that'll go as they get converted over. I'd much prefer to see wl_drm go completely unused where possible on the client side first, then work out a transition plan for Mesa deprecating it, then we can say with a straight face that we're not publishing it because we expect it to disappear. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
