On 13 November 2017 at 14:52, Emil Velikov <[email protected]> wrote: > On 13 November 2017 at 14:21, Daniel Stone <[email protected]> wrote: >> 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. >> > 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. > Some more ideas that come to mind:
* by moving the XML we do not make it stable, the protocol already is * users already depend on wayland-protocols ... to a degree * moving wl_drm serves as a lovely reminder, same as the version bump later on "We really want to update $user _away_ from use wl_drm" "We want to test the !wl_drm codepaths more extensively" * adding a single toggle in wayland-protocols instead of --disable-wl-drm in each of three projects --hack-hack-I-want-wl-drm-but-I-use-if-only-for-mesa-vaapu-xwayland * explicit and annoying enable ^^ ensures a) people are less likely to misuse b) people use wl_dmabuf by default * combinatoric explosion With separate toggles we have - mesa with wl_drm & vaapi w/o wl_drm etc Bump wayland-protocols req. across the board - everything is consistently built w/o wl_drm ;-) * feature parity for wl_dmabuf codepaths - EGL_WL_bind_wayland_display, others(?) This serves as a nice example of the above points ;-) HTH Emil _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
