Move wayland-drm protocol from Mesa to wayland-core
benjamin.gaignard at linaro.org
Thu Nov 28 01:24:33 PST 2013
>From my point of view wl_drm isn't link to Mesa, it is only about
exchange buffers by using a file descriptor and, for example, doesn't
rely on EGL.
I understand that other graphic stacks could have defined their own
way to for zero-copy (and so other protocols).
I don't aim to make gstreamer wayland sink works for all of them but
at least with wl_drm protocol which is quite generic.
Since dmabuf has been adopted in kernel we have the opportunity to
rationalize also some code in userland and for that we need a common
Move wl_drm into wayland-core make it more easily accessible for all
software even for those who don't use Mesa.
PS: I have an updated version of my patch for latest wayland
2013/11/27 Jasper St. Pierre <jstpierre at mecheye.net>:
> Wasn't EGLStreams supposed to solve the use case of passing hardware buffers
> around in a standard way?
> On Wed, Nov 27, 2013 at 1:22 PM, Jason Ekstrand <jason at jlekstrand.net>
>> On Nov 27, 2013 10:53 AM, "Benjamin Gaignard"
>> <benjamin.gaignard at linaro.org> wrote:
>> > Hi all,
>> > I'm working for Linaro on enabling a zero copy path in GStreamer by
>> > using dmabuf.
>> > To make this possible I have patched gst wayland sink to use wayland
>> > drm protocol: https://bugzilla.gnome.org/show_bug.cgi?id=711155
>> > Today wayland drm protocol is limited to Mesa so I have decided to
>> > move it into wayland-core.
>> > My hardware doesn't have gpu support yet so I have patched weston
>> > (pixman) to allow usage of wl_drm buffers.
>> > With this I able to share/use a buffer allocated by DRM in gstreamer
>> > pipeline even if I don't have gpu and EGL.
>> > What do you think about make wayland drm protocol available like this ?
>> The problem here is that wl_drm is really a mesa extension. Well, more of
>> an open-source linux graphics stack extension. The point is that there are
>> other graphics stacks: Rhaspberry Pi, libhybris, other proprietary stacks,
>> etc. and each of these graphics stacks has its own extension for passing
>> hardware buffers around. This means that if you want your GStreamer sink to
>> work on these other stacks with zero-copy, you will have to talk their
>> protocols. Because wl_drm isn't global to all of wayland, it probably
>> shouldn't go into the wayland core.
>> This does not mean, however, that wl_drm can't be exposed in a more
>> sensible way. As of 1.3, we are now exporting wayland.xml to
>> /usr/share/wayland and we can put other extensions there as well. We could
>> have, for instance, a /usr/share/mesa.xml file that provides the mesa
>> extensions. Then projects wanting to talk directly to mesa can generate the
>> header and C files from the system-installed xml file. This would solve the
>> problem of keeping everything in sync.
>> One last note (this one's been bugging me for a while). If we are going
>> to export wl_drm in some way, we should probably rename it to something like
>> mesa_drm. We really need to get out of the habit of using the wl_ namespace
>> for everything that talks the wayland protocol. If we don't alter the
>> details of wl_drm in the rename, it shouldn't be too hard to move everyone
>> over from wl_drm to mesa_drm.
>> Hope that's sensible/helpful.
>> --Jason Ekstrand
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 25997 bytes
Desc: not available
More information about the wayland-devel