[Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core

[Benjamin Gaignard]

Jason,

>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
wayland protocol.
Move wl_drm into wayland-core make it more easily accessible for all
software even for those who don't use Mesa.

Benjamin

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>
> wrote:
>>
>>
>> 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 ?
>>
>> Benjamin,
>>
>> 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
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>
>
>
> --
>   Jasper



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org │ Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Move-wayland-drm-protocol-from-mesa-to-wayland-core.patch
Type: text/x-patch
Size: 25997 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131128/eb3586ea/attachment-0001.bin>