Re: will wayland support multi plane?
Hi, compositor-drm is just another Wayland demo compositor backend. The -drm one is a backend for DRM/KMS, just as the -x11 and -openwfd are backends for those APIs. /BR /Marcus On 04/29/2011 03:24 AM, Zhao, Juan J wrote: That looks great!:) One simple question, what is compositor-drm? Is that one drm kernel module special for wayland? On Thu, 2011-04-28 at 12:51 +0200, Benjamin Franzke wrote: Yeah, we'll work on integrating the kms overlay stuff, thats talked about on dri-devel [1], into compositor-drm as well as compositor-openwfd. [1] http://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html Ben 2011/4/28 Marcus Lorentzon: On 04/28/2011 11:27 AM, Zhao, Juan J wrote: Hi there, Some embedded system provide more than one plan to work at the same time to get better performance. For example, one video running on one plane and one other video or graphics run on the other plane. Will wayland take this to be considered? One video on plane A, one window on Plane B, and the cursor in on Plane C Maybe the new OpenWF Display compositor will make this possible. As I understand, overlays are not "standard" in KMS, but by abstracting KMS with OpenWFD, any vendor providing OpenWFD drivers with multiple pipes should be able to get overlays in the "demo" wayland compositor (as long as the compositor is extended to make use of multiple pipes). See http://cgit.freedesktop.org/wayland/wayland-demos/tree/compositor/compositor-openwfd.c. I guess Ben can give more details on the target of this new compositor. /BR /Marcus ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: will wayland support multi plane?
On 04/28/2011 11:27 AM, Zhao, Juan J wrote: Hi there, Some embedded system provide more than one plan to work at the same time to get better performance. For example, one video running on one plane and one other video or graphics run on the other plane. Will wayland take this to be considered? One video on plane A, one window on Plane B, and the cursor in on Plane C Maybe the new OpenWF Display compositor will make this possible. As I understand, overlays are not "standard" in KMS, but by abstracting KMS with OpenWFD, any vendor providing OpenWFD drivers with multiple pipes should be able to get overlays in the "demo" wayland compositor (as long as the compositor is extended to make use of multiple pipes). See http://cgit.freedesktop.org/wayland/wayland-demos/tree/compositor/compositor-openwfd.c. I guess Ben can give more details on the target of this new compositor. /BR /Marcus ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: compositor-drm & MESA dependencies
On 04/12/2011 09:40 PM, Benjamin Franzke wrote: 2011/4/12 Marcus Lorentzon: Hi, we run Wayland on a platform without a MESA based EGL. But we still want to run the DRM compositor and use the same EGL/GLES drivers as for QtCompositor (wayland-egl platform with DRM support included). Currently this is not possible without hacking the compositor removing the MESA based code (get display& create scanout EGLimages). So, do you think it would be possible to put the MESA stuff in a separate file with a more generic API like attached sample patch? We will then implement the same functionality using non-MESA extensions. Another option is of course to add fake MESA EGL functions in a separate file, wrapping our egl stuff until there's a standard DRM<->EGL interaction extension. The DRM-image code is not really mesa specific, its only specified by mesa. What hinders you from implementing the extension, the spec is available here: http://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_drm_image.txt Whats different in your own DRM-image functions, maybe EGL_MESA_drm_image can be improved to match your requirements? Our issue is that we source 3D IP from external company which makes it hard to get any misc extension. For real products it's probably not a big deal, but for this type of early adoption it's not a perfect solution. But I think we should be able to create MESA extension as a wrapper on top of our EGL for the time being. And second, I didn't realize the MESA extension was publicly released now :). Difference in our DRM-image API is that it doesn't ask EGL to allocate the memory. Instead app use "DRM" directly for allocating buffers. And then sending the "name/handle" to EGL for wrapping. Just like most EGLimage extensions wrap existing resources. This makes the export image step unnessessary, since we already own the buffer, but at the cost of client transparency. Client needs to know how to allocate the memory. In that sense the MESA EGL extension is more generic, since we need a libKMS like API for allocating buffers. Main motivation for this, is that we can use same buffer allocation API for EGL/GLES as for non EGL based video/camera sinks. Or what about extending the wayland-egl platform API with functions to handle allocation of scanout buffers, and make use of wayland-egl in drm compositor? Right, some abstract image-creation API would be helpful in general. This'd help porting compositors to APIs like OpenWF Display which requires platform-specific image creation. Though I think it should be seperate from wayland-egl, as this is intended for client side. Yes, I think there are generic EGL extensions coming in this area. Maybe someone working with MESA/DRM and is a member of Khronos should take a look at this before it's released. Especially making sure the USE_SCANOUT usage flag is included, unless you decide you can reuse OpenWF Display type of buffers (which should be ok I guess, same target HW). As for separating wayland-egl from server code. Isn't wayland-egl the API used already by server in compositor-wayland? Or you just mean that you don't want any server only API calls made available in this lib? We are looking at putting the server buffer protocol API in the same libwayland-egl.so binary as used by clients. But of course the client platform API is the only exports that should be linked to from client binaries. Combining the server side buffer protocol in the same binary as clients use, makes it easier to handle the dependency between these two. At least until our buffer protocol is nailed down. Where do you put the MESA server side marshaling code for drm buffer protocol? libEGL or libwayland-egl? /BR /Marcus ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
compositor-drm & MESA dependencies
Hi,
we run Wayland on a platform without a MESA based EGL. But we still want
to run the DRM compositor and use the same EGL/GLES drivers as for
QtCompositor (wayland-egl platform with DRM support included). Currently
this is not possible without hacking the compositor removing the MESA
based code (get display & create scanout EGLimages). So, do you think it
would be possible to put the MESA stuff in a separate file with a more
generic API like attached sample patch? We will then implement the same
functionality using non-MESA extensions.
Another option is of course to add fake MESA EGL functions in a separate
file, wrapping our egl stuff until there's a standard DRM<->EGL
interaction extension.
Or what about extending the wayland-egl platform API with functions to
handle allocation of scanout buffers, and make use of wayland-egl in drm
compositor?
/BR
/Marcus
>From d93a7d5dd2a7d5795e5b1efe5e69abc6a713aee7 Mon Sep 17 00:00:00 2001
From: Marcus Lorentzon
Date: Tue, 12 Apr 2011 20:12:09 +0200
Subject: [PATCH] Extract compositor MESA code into separate file
---
compositor/Makefile.am |2 +-
compositor/compositor-drm.c | 22 +++---
compositor/mesa.c | 27 +++
3 files changed, 35 insertions(+), 16 deletions(-)
create mode 100644 compositor/mesa.c
diff --git a/compositor/Makefile.am b/compositor/Makefile.am
index e90830a..20dd330 100644
--- a/compositor/Makefile.am
+++ b/compositor/Makefile.am
@@ -12,7 +12,7 @@ compositor_LDADD =\
$(COMPOSITOR_LIBS)
if ENABLE_DRM_COMPOSITOR
-drm_compositor_sources = compositor-drm.c tty.c evdev.c
+drm_compositor_sources = compositor-drm.c tty.c evdev.c mesa.c
endif
if ENABLE_X11_COMPOSITOR
diff --git a/compositor/compositor-drm.c b/compositor/compositor-drm.c
index 545bde5..b6fc036 100644
--- a/compositor/compositor-drm.c
+++ b/compositor/compositor-drm.c
@@ -147,7 +147,7 @@ init_egl(struct drm_compositor *ec, struct udev_device *device)
}
ec->drm.fd = fd;
- ec->base.display = eglGetDRMDisplayMESA(ec->drm.fd);
+ ec->base.display = drm_get_egl_display(ec->drm.fd);
if (ec->base.display == NULL) {
fprintf(stderr, "failed to create display\n");
return -1;
@@ -205,13 +205,7 @@ create_output_for_connector(struct drm_compositor *ec,
drmModeEncoder *encoder;
drmModeModeInfo *mode;
int i, ret;
- EGLint handle, stride, attribs[] = {
- EGL_WIDTH, 0,
- EGL_HEIGHT, 0,
- EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA,
- EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
- EGL_NONE
- };
+ EGLint handle, stride;
output = malloc(sizeof *output);
if (output == NULL)
@@ -255,15 +249,13 @@ create_output_for_connector(struct drm_compositor *ec,
for (i = 0; i < 2; i++) {
glBindRenderbuffer(GL_RENDERBUFFER, output->rbo[i]);
- attribs[1] = output->base.width;
- attribs[3] = output->base.height;
- output->image[i] =
- eglCreateDRMImageMESA(ec->base.display, attribs);
+ output->image[i] = drm_create_scanout_image(ec->base.display,
+ output->base.width,
+ output->base.height,
+ &handle, &stride);
glEGLImageTargetRenderbufferStorageOES(GL_RENDERBUFFER,
output->image[i]);
- eglExportDRMImageMESA(ec->base.display, output->image[i],
- NULL, &handle, &stride);
-
+
ret = drmModeAddFB(ec->drm.fd,
output->base.width, output->base.height,
32, 32, stride, handle, &output->fb_id[i]);
diff --git a/compositor/mesa.c b/compositor/mesa.c
new file mode 100644
index 000..62fb2cb
--- /dev/null
+++ b/compositor/mesa.c
@@ -0,0 +1,27 @@
+
+
+int drm_get_egl_display(int fd)
+{
+ return eglGetDRMDisplayMESA(fd);
+}
+
+EGLimage drm_create_scanout_image(EGLDisplay display, EGLint w, EGLint h,
+ EGLint *handle, EGLint *stride)
+{
+ EGLImageKHR image;
+ EGLing attribs[] = {
+ EGL_WIDTH, 0,
+ EGL_HEIGHT, 0,
+ EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA,
+ EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
+ EGL_NONE
+ };
+
+ attribs[1] = w;
+ attribs[3] = h;
+ image = eglCreateDRMImageMESA(display, attribs);
+ eglExportDRMImageMESA(display, image, NULL, handle, stride);
+
+ return image;
+}
+
--
1.7.3.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland implementation conformance
On 01/26/2011 03:57 PM, Kristian Høgsberg wrote: On Wed, Jan 26, 2011 at 8:22 AM, Tiago Vignatti wrote: Hi, I hijacked this comment which Kristian made in the other email thread; my comments are inline. On 01/24/2011 09:30 PM, ext Kristian Høgsberg wrote: Once of the things that X got right was the extension model. Wayland takes it one step further by making everything an extension: the only thing that's fixed in the Wayland protocol is an interface for discovering other interfaces. If it turns out that we need to update the input model, we have versioning built in for incremental updates, and we can add an entire new model if we need to start from scratch. So what defines exactly a Wayland implementation which is conformant with the protocol then? Let's say I don't care about drm_interface and my implementation works okay without it. Does my software is called Wayland then? Nevertheless, in this case, I won't be able to connect the same clients from such implementation on some other Wayland server that relies on DRM. So if we target interoperability between clients and server, then I guess we will want to define hardly a few interfaces. That's a good question. My intention is to have wayland.xml be the official interfaces, but you're right that the drm interface is specific to the Linux drm driver model and maybe that should be split out into its own file. Additionally, it would make sense to abstract out the wl_buffer creation into a library that server and client can link to so that not every toolkit and application that use the wayland protocol directly will have to know about every driver specific interface for creating and sharing buffers. What about adding "profiles" or interface groups in the protocol xml. Client could query compositor of a list of profiles supported. And profiles could be hierarchical like: base (very basic profile allowing simple surfaces and input) desktop/netbook : base (base + d&d, mouse pointer, multi touch etc) kde/gnome : desktop (desktop + shell interfaces) pad/phone : base (base + multi touch, overlays, orientation, ...) meego : phone (phone + meego shell services) ... A sample ubuntu profile list could be "base 2.3;desktop 1.2;pad 1.3;gnome 1.1;ubuntu 2.0" That would make it easier for apps to target specific platforms, create better fallbacks and improve device/platform portability/interop. /BR /Marcus ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
