Move wayland-drm protocol from Mesa to wayland-core

[Pekka Paalanen]

On Thu, 28 Nov 2013 10:24:33 +0100
Benjamin Gaignard <benjamin.gaignard at linaro.org> wrote:

> 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.

Hi,

if you aim particularly for dma-buf, then I would propose making a new
Wayland protocol extension mesa_dma_buf or gbm_dma_buf or whatever name
is appropriate, and drop all the unneeded parts compared to wl_drm.

I think dma-buf with render nodes will not need authentication, and it
certainly does not use flink names. Would that work?

Note that still it would not be about a generic fd-based buffer
passing but specifically dma-buf. If you want it really generic, then
you would need something like Android's native_buffer_t (IIRC) which
contains an arbitrary number of fds and integers, and then you are
going to need platform-specific code to handle them right and whooops,
the protocol itself is not meaningful anymore.

You might be interested in
http://lists.freedesktop.org/archives/wayland-devel/2013-October/011593.html
which is David Herrmann's proof of concept for passing mmappable
dmabufs over wl_shm, and not needing any changes to Weston or Mesa
AFAIU.

Also note that not all drivers support mmap'ing dmabufs, and mmap'ing
in general is usually not a good thing for gfx buffers. I believe you
would want to avoid mmap when possible.

If you wanted to be truely portable, I guess you might create a library
pair similar to libEGL, where the actual protocol extension would again
be just an internal detail of the library. But the question there is
how would that library bind to rendering in client side and compositing
in the server side.

Where do you want to draw the line?


Thanks,
pq

> 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
> 
> 
>