<div dir="ltr">Wasn't EGLStreams supposed to solve the use case of passing hardware buffers around in a standard way?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 27, 2013 at 1:22 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><p dir="ltr"><br>
On Nov 27, 2013 10:53 AM, "Benjamin Gaignard" <<a href="mailto:benjamin.gaignard@linaro.org" target="_blank">benjamin.gaignard@linaro.org</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> I'm working for Linaro on enabling a zero copy path in GStreamer by<br>
> using dmabuf.<br>
> To make this possible I have patched gst wayland sink to use wayland<br>
> drm protocol: <a href="https://bugzilla.gnome.org/show_bug.cgi?id=711155" target="_blank">https://bugzilla.gnome.org/show_bug.cgi?id=711155</a><br>
><br>
> Today wayland drm protocol is limited to Mesa so I have decided to<br>
> move it into wayland-core.<br>
> My hardware doesn't have gpu support yet so I have patched weston<br>
> (pixman) to allow usage of wl_drm buffers.<br>
> With this I able to share/use a buffer allocated by DRM in gstreamer<br>
> pipeline even if I don't have gpu and EGL.<br>
><br>
> What do you think about make wayland drm protocol available like this ?</p>
</div><p dir="ltr">Benjamin,</p>
<p dir="ltr">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.</p>


<p dir="ltr">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.</p>


<p dir="ltr">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.</p>


<p dir="ltr">Hope that's sensible/helpful.<span class="HOEnZb"><font color="#888888"><br>
--Jason Ekstrand</font></span></p>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>  Jasper<br>
</div>