[PATCH wayland-protocols] Add the wl_drm protocol

[Emil Velikov]

On 13 November 2017 at 14:21, Daniel Stone <daniel at fooishbar.org> wrote:
> 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.
>
Thanks for the elaborate answer Dan.

Being the more paranoid person (me thinks), I doubt anyone outside of
existing users will use wl_drm.
I do see your concern though - let me see if I can figure out a way to
make it harder to misuse.

What I am planning here is the de-facto deprecation of wl_drm. It's
somewhat evil, so I kept is half-hidden.
Here it is, in all its [evil] glory:
 - step 1: move wl_drm to wayland-protocols, throw as many obstacles
needed to prevent average Joe from using it
 - 2: switch users {Mesa...} to it
 - 3: in parallel with #2, propose/shout at people that wl_drm will be
gone soon (tm)
 - 4: after users have working wl_dmabuf implementation, kill off
wl_drm from wayland-protocols
 - 5: roll new wayland-protocols, bump the requirement in users
 - 6: drop 'dead' code from users
 - ...
 - Profit!

How does that sound? I could add that to the commit message if you prefer.
FTR Pekka was asking why Mesa doesn't ship/install the file - because
it leads to a circular dependency.
Plus people are more likely to misuse it, in said case.

Thanks
Emil