[PATCH wayland-protocols] Add the wl_drm protocol

[Daniel Stone]

Hi Emil,

On 2 November 2017 at 17:09, Emil Velikov <emil.l.velikov at gmail.com> 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