Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
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 jstpie...@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 ja...@jlekstrand.net
wrote:
On Nov 27, 2013 10:53 AM, Benjamin Gaignard
benjamin.gaign...@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-de...@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
From fe24018437529affead57dcdf1d9425f11f2c6dd Mon Sep 17 00:00:00 2001
From: Benjamin Gaignard benjamin.gaign...@linaro.org
Date: Thu, 28 Nov 2013 09:55:38 +0100
Subject: [PATCH] Move wayland-drm protocol from mesa to wayland-core.
Add WL_EXPORT to function declaration.
Add {get/put}_data callback to get access to memory.
Signed-off-by: Benjamin Gaignard benjamin.gaign...@linaro.org
---
protocol/Makefile.am |6 +-
protocol/wayland-drm.xml | 182 ++
src/Makefile.am | 11 +-
src/wayland-drm.c| 377 ++
src/wayland-drm.h| 131
5 files changed, 703 insertions(+), 4 deletions(-)
create mode 100644 protocol/wayland-drm.xml
create mode 100644 src/wayland-drm.c
create mode 100644 src/wayland-drm.h
diff --git a/protocol/Makefile.am b/protocol/Makefile.am
index e8b6290..836e8dd 100644
--- a/protocol/Makefile.am
+++ b/protocol/Makefile.am
@@ -1,4 +1,4 @@
-dist_pkgdata_DATA = wayland.xml wayland.dtd
+dist_pkgdata_DATA = wayland.xml wayland-drm.xml wayland.dtd
if HAVE_XMLLINT
.PHONY: validate
@@ -6,9 +6,9 @@ if HAVE_XMLLINT
.%.xml.valid: %.xml
$(AM_V_GEN)$(XMLLINT) --noout --dtdvalid $(srcdir)/wayland.dtd $^ $@
-validate: .wayland.xml.valid
+validate: .wayland.xml.valid .wayland-drm.xml.valid
all-local: validate
-CLEANFILES = .wayland.xml.valid
+CLEANFILES = .wayland.xml.valid .wayland-drm.xml.valid
Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
On Thu, 28 Nov 2013 10:24:33 +0100 Benjamin Gaignard benjamin.gaign...@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 jstpie...@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 ja...@jlekstrand.net wrote: On Nov 27, 2013 10:53 AM, Benjamin Gaignard benjamin.gaign...@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-de...@lists.freedesktop.org
Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
Hi, On 28 November 2013 10:04, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 28 Nov 2013 10:24:33 +0100 Benjamin Gaignard benjamin.gaign...@linaro.org wrote: 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. 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. Given that dmabuf doesn't specify format codes or anything like that, you can't make it properly generic. My original thought was to make a generic wl_dmabuf interface, but given the format code issue, it seemed prudent to leave it as a part of wl_drm for now. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
On Nov 27, 2013 10:53 AM, Benjamin Gaignard benjamin.gaign...@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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
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 ja...@jlekstrand.netwrote: On Nov 27, 2013 10:53 AM, Benjamin Gaignard benjamin.gaign...@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-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Jasper ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Move wayland-drm protocol from Mesa to wayland-core
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 ?
Please note those patches are for wayland/weston 1.1.0
Regards,
Benjamin
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
From b185fe89a1ea8ddbe19d943cb19272f369b7b438 Mon Sep 17 00:00:00 2001
From: Benjamin Gaignard benjamin.gaign...@linaro.org
Date: Mon, 25 Nov 2013 11:38:12 +0100
Subject: [PATCH] make weston able to use wl_drm protocol
Make compositor-drm able to provide wl_drm buffer even if EGL isn't used.
Update pixman to allow it to compose wl_drm buffer like it does for wl_shm.
Signed-off-by: Benjamin Gaignard benjamin.gaign...@linaro.org
---
src/compositor-drm.c | 131 +++--
src/pixman-renderer.c | 60 +++---
2 files changed, 169 insertions(+), 22 deletions(-)
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index da1ba79..b336127 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -45,6 +45,8 @@
#include pixman-renderer.h
#include udev-seat.h
#include launcher-util.h
+#include wayland-drm.h
+#include wayland-drm-server-protocol.h
static int option_current_mode = 0;
static char *output_name;
@@ -79,10 +81,12 @@ struct drm_compositor {
struct udev_monitor *udev_monitor;
struct wl_event_source *udev_drm_source;
+ struct wl_drm *wl_server_drm;
struct {
int id;
int fd;
+ char *device_name;
} drm;
struct gbm_device *gbm;
uint32_t *crtcs;
@@ -754,7 +758,7 @@ drm_output_prepare_overlay_surface(struct weston_output *output_base,
if (es-alpha != 1.0f)
return NULL;
- if (wl_buffer_is_shm(es-buffer_ref.buffer))
+ if (wl_buffer_is_shm(es-buffer_ref.buffer) || wayland_buffer_is_drm(es-buffer_ref.buffer))
return NULL;
if (!drm_surface_transform_supported(es))
@@ -876,7 +880,7 @@ drm_output_prepare_cursor_surface(struct weston_output *output_base,
if (c-cursors_are_broken)
return NULL;
if (es-buffer_ref.buffer == NULL ||
- !wl_buffer_is_shm(es-buffer_ref.buffer) ||
+ (!wl_buffer_is_shm(es-buffer_ref.buffer) !wayland_buffer_is_drm(es-buffer_ref.buffer)) ||
es-geometry.width 64 || es-geometry.height 64)
return NULL;
@@ -966,10 +970,10 @@ drm_assign_planes(struct weston_output *output)
primary = c-base.primary_plane;
wl_list_for_each_safe(es, next, c-base.surface_list, link) {
/* test whether this buffer can ever go into a plane:
- * non-shm, or small enough to be a cursor
+ * non-shm, non-drm, or small enough to be a cursor
*/
if ((es-buffer_ref.buffer
- !wl_buffer_is_shm(es-buffer_ref.buffer)) ||
+ (!wl_buffer_is_shm(es-buffer_ref.buffer) !wayland_buffer_is_drm(es-buffer_ref.buffer))) ||
(es-geometry.width = 64 es-geometry.height = 64))
es-keep_buffer = 1;
else
@@ -1174,8 +1178,120 @@ init_drm(struct drm_compositor *ec, struct udev_device *device)
weston_log(using %s\n, filename);
ec-drm.fd = fd;
+ ec-drm.device_name = strdup(filename);
+ return 0;
+}
+
+static int
+drm_display_authenticate(void *user_data, uint32_t magic)
+{
+ struct drm_compositor *ec = user_data;
+ weston_log(authentification\n);
+ return drmAuthMagic(ec-drm.fd, magic);
+}
+
+struct drm_driver_buffer {
+ uint32_t size;
+ uint32_t handle;
+ char *data;
+};
+
+static void
+drm_reference_buffer(void *user_data, uint32_t name, int prime_fd,
+ struct wl_drm_buffer *buffer)
+{
+ struct drm_compositor *ec = user_data;
+ uint32_t handles[4], pitches[4], offsets[4];
+ int ret;
+ uint32_t fd;
+ struct drm_driver_buffer *driver_buffer;
+ weston_log(reference buffer fd %d\n, prime_fd);
+ if (prime_fd == -1)
+ return;
+
+ drmPrimeFDToHandle(ec-drm.fd, prime_fd, handles[0]);
+ pitches[0] = buffer-stride[0];
+ pitches[1] = buffer-stride[1];
+ pitches[2] = buffer-stride[2];
+ offsets[0] = buffer-offset[0];
+ offsets[1] = buffer-offset[1];
+ offsets[2] = buffer-offset[2];
+
+ weston_log(drmModeAddFB2 fd %d\n, prime_fd);
+ ret = drmModeAddFB2 (ec-drm.fd, buffer-buffer.width, buffer-buffer.height,
+ buffer-format, handles, pitches, offsets, fd, 0);
+ if (ret) {
+ weston_log(addfb2 failed: %m\n);
+ return;
+ }
+
+ weston_log(addfb2 success\n);
+ driver_buffer = malloc(sizeof *driver_buffer);
+ if (driver_buffer == NULL)
+ return;
+
+ driver_buffer-size = buffer-buffer.width * buffer-buffer.height * 4;
+ driver_buffer-handle = handles[0];
+
