Re: [PATCH weston] compositor: automatically set opaque region for color formats
On Thu, 6 Sep 2012 11:10:39 -0400 Kristian Høgsberg wrote: > On Wed, Sep 05, 2012 at 09:36:59AM +0300, Pekka Paalanen wrote: > > Some color formats are naturally opaque: RGB, XRGB, YUV formats without > > A channel. For these, automatically set the opaque region to whole > > surface. > > > > Note: > > If a client first sends a buffer with opaque color format, and then > > sends another buffer of the same size but with non-opaque color format, > > the opaque region in the server is no longer what the client expects > > based on protocol: it has been changed from what the client earlier > > specified into whole surface. Therefore this is a protocol change. > > > > --- > > > > This patch has been only compile-tested, because I'm not sure we can do > > it like this, and temporary opaque region setup would be more complex. > > > > Kristian, do we really want to go there? > > We do want to make sure we can disable blend when possible and clip > obscured changes, regardless of whether or not the client sets the > opaque region. But maybe not this way... I think we can do it in > weston_surface_draw(), where we compute the surface_blend region. In weston_surface_draw() we certainly can disable blending as appropriate, but clipping obscured damage must be done earlier by somehow changing the opaque region going into the damage/clip/repaint region computations. > I'm working on abstracting out the gles2 rendering code, so let's put > this off for just a couple of days. Oh, cool! I've been aching to get compositor.c shorter. :-) Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Weston framerate (Re: bare bones opengl weston client sample)
On Thu, 6 Sep 2012 11:25:20 -0400 jegde jedge wrote: > Thank you so much, that did the trick! > > Next Question :) > On the same code, on the same hardware... > I am getting the glut 60 fps limit when running my app using the glut > front end via > gnome and X. > I am getting ~24 fps using the simple-egl front end on top of wayland. > I also noticed the display using wayland likes to hover around 20 fps. > > Is there some kind of throttle built into the frame rate for the > redraw callback? Hi, could you remind us, are you running Weston with the X11 or DRM backend? If you use the X11 backend, sloppy framerates are expected. X has no method of telling the X application (weston) that the image it posted has now hit the screen. Therefore the X11 backend fakes it by using a timer to blindly to trigger this "image hit the screen" callback. Obviously that is very flakey and inaccurate, but cannot really do any better. However, if you are on DRM backend, it is worth investigating. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Advantages of Wayland (Re: A barebone version of Weston?)
On Thu, 6 Sep 2012 22:40:49 -0700 Mikalai Kisialiou wrote: > Next time you guys decide to update the documentation, it may probably make > sense to explicitly list key advantages of Wayland/Weston, like the one > that the clients are completely independent unlike X where they can screw > around. I've seen articles on slashdot where people just claim that there > are no advantages to Wayland. Kristian's point of view seems to be that the > architecture by itself is the key advantage. While true, people usually > care more about the user/developer advantages that this architecture > provides rather than the architecture itself. Anyways, don't want to pile > more work on your team. Just hoping that you guys get the credit you > deserve. > > Thanks, > Nick This wish should really be on wayland-devel@, so I'm Cc'ing it. :-) Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Using Weston as my primary UI
I switched from X to Weston a couple days ago. The only thing I've needed X for in that time was playing a movie, and thanks to Alexander Preisinger I could've compiled mplayer with native Wayland support instead. Totem mostly works, but I can't get it to go into fullscreen mode (since XWayland menus pop up but don't actually work). mplayer worked the first time I ran it, but not after. Firefox works well (via XWayland). As long as you don't try to drag a tab, which immediately crashes XWayland and takes out all apps running through it. I'm not really using anything as a native Wayland client, which is annoying. The only problem with gnome-terminal is that the GTK+ clipboard gets disabled for Wayland if the X backend is also compiled in (and gnome-terminal won't run without the X backend built). And I don't think weston-terminal has clipboard capability. And Terminology, written in EFL, can't do key combinations including ctrl via Wayland ( http://trac.enlightenment.org/e/ticket/1461 ). Looks pretty neat though. (Also interesting, when used via XWayland it consistently segfaults Weston on startup.) But generally, most things that work with X work fine with XWayland. Getting fullscreen applications to pop up centered would really be nice. It's kind of surprising how much of a pleasant relief it was to just not have to manually center fullscreen mplayer under X. Things can be kind of flickery (when resizing), with random glitches pretty common. Weston occasionally segfaults. But with my minimal expectations of a UI, it's pretty usable. Supertuxkart still works (via xwayland). It might be useful to mention more what's necessary to get gnome-terminal working via Wayland. Launch weston or weston-launch via dbus-launch, and then run gnome-terminal with the --disable-factory argument. So: dbus-launch ~/install/bin/weston-launch gnome-terminal --disable-factory # which you can put in ~/.config/weston.ini: [launcher] icon=/usr/share/app-install/icons/utilities-terminal.png path=/usr/bin/gnome-terminal --disable-factory And I just verified you can set environment variables in launcher items: [launcher] icon=/usr/share/app-install/icons/utilities-terminal.png path=GDK_BACKEND=x11 /usr/bin/gnome-terminal --disable-factory I'm using a Radeon video card, with RAOF's Radeon DDX (as I recently changed the XWayland instructions to). I updated my "state of wayland" page: http://www.chaosreigns.com/wayland/state/ Let me know where it's missing something / wrong. I also updated my Wayland master build script, it had been checking out an old cairo commit for a bug probably long since fixed, and the xwayland repo urls needed to be updated: http://www.chaosreigns.com/wayland/buildscript/ Works on Ubuntu Quantal. Probably works on Ubuntu Precise. -- "As humans, we are taught to forget that we are animals." - forward to Johnny The Homicidal Maniac http://www.ChaosReigns.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Wayland X server uses xwayand.conf instead of xorg.conf
Pekka Paalanen wrote: Please, carefully read 'man xorg.conf' on how xorg.conf.d works. I assume you will want to have xwayland.conf.d replacing xorg.conf.d, just like you suggest xwayland.conf replaces xorg.conf. I get it now. Well they certainly made a mess of something that should be simple. I have NEVER seen any use of more than xorg.conf and was unaware of that directory. It is starting to sound like we should just always pass -configdir and -config as arguments to X, and have the directory passed with -configdir set in weston's ./configure, instead of changing xorg-server. I agree, that is exactly what needs to be done. Otherwise xwayland will find any existing xorg.conf.d and read that, screwing up in the same way. I hope that covers all the possible search locations. We want to make sure that it is possible for it to *not* find a config file no matter what the xorg setup somebody has on their machine. If users are required to create an xwayland.conf file for no reason other than to hide an xorg.conf file then I don't think the problem is solved. However since there is already a -wayland switch and thus the server has been patched anyway, I don't see any reason not to have that have a side-effect of also doing these two switches as well. In my patch the user can still override it with --config anyway so no functionality is lost. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
I forgot to mention. its on 945GME glut 60 fps uses 17%cpu wayland 24 fps uses 3% cpu I am hoping for an apples to apples. ! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Thank you so much, that did the trick! Next Question :) On the same code, on the same hardware... I am getting the glut 60 fps limit when running my app using the glut front end via gnome and X. I am getting ~24 fps using the simple-egl front end on top of wayland. I also noticed the display using wayland likes to hover around 20 fps. Is there some kind of throttle built into the frame rate for the redraw callback? Thank you. On Wed, Sep 5, 2012 at 8:59 PM, Kristian Høgsberg wrote: > On Wed, Sep 5, 2012 at 8:11 PM, jegde jedge wrote: >> Thanks, >> I tried that route. it is a gles2 not gles or opengl example; and that >> will not work with the fixed function pipeline functions like >> glPushMatrix et.al. > > Sure, it's a gles2 example, but it shows you how to get a minimal > egl/gles2 client working under wayland. I figured you'd want to > replace the gles2 code with your own code anyway, and yes, it is just > a matter of using EGL_OPENGL_API, removing the context attributes and > linking to libGL. > > Kristian > >> I went with the gears example since it binds the OPENGL API but it >> uses the window/toytoolkit/libshared stuff with cairo >> and I don't have enough insight to what is needed and what isnt. >> >> Is it as simple as replacing line 131: >> ret = eglBindAPI(EGL_OPENGL_ES_API); >> with >> EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? >> >> Thank you. >> I'll try in the morning. >> >> >> On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg wrote: >>> Right under your nose: >>> >>> http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c >>> >>> Kristian >>> >>> On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] screensaver: fix decoding of transparency in xpm files
On Thu, Sep 06, 2012 at 03:23:28PM +0200, Philipp Brüschweiler wrote:
> Use 0 as transparent pixel. This is needed when using premultiplied
> alpha.
Thanks, committed.
Kristian
> ---
> clients/wscreensaver-glue.c | 6 +++---
> 1 Datei geändert, 3 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
>
> diff --git a/clients/wscreensaver-glue.c b/clients/wscreensaver-glue.c
> index a548599..55d0a8c 100644
> --- a/clients/wscreensaver-glue.c
> +++ b/clients/wscreensaver-glue.c
> @@ -80,14 +80,14 @@ read_xpm_color(uint32_t *ctable, const char *line)
> value = strtol(&cstr[1], &end, 16);
>
> if (strcmp(cstr, "None") == 0)
> - ctable[key] = 0x00ff;
> + ctable[key] = 0x;
> else if (cstr[0] != '#' || !(cstr[1] != '\0' && *end == '\0')) {
> fprintf(stderr, "%s: error interpreting XPM color '%s'\n",
> progname, cstr);
> return;
> + } else {
> + ctable[key] = value | 0xff00;
> }
> -
> - ctable[key] = value | 0xff00;
> }
>
> static void
> --
> 1.7.12
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: automatically set opaque region for color formats
On Wed, Sep 05, 2012 at 09:36:59AM +0300, Pekka Paalanen wrote:
> Some color formats are naturally opaque: RGB, XRGB, YUV formats without
> A channel. For these, automatically set the opaque region to whole
> surface.
>
> Note:
> If a client first sends a buffer with opaque color format, and then
> sends another buffer of the same size but with non-opaque color format,
> the opaque region in the server is no longer what the client expects
> based on protocol: it has been changed from what the client earlier
> specified into whole surface. Therefore this is a protocol change.
>
> ---
>
> This patch has been only compile-tested, because I'm not sure we can do
> it like this, and temporary opaque region setup would be more complex.
>
> Kristian, do we really want to go there?
We do want to make sure we can disable blend when possible and clip
obscured changes, regardless of whether or not the client sets the
opaque region. But maybe not this way... I think we can do it in
weston_surface_draw(), where we compute the surface_blend region.
I'm working on abstracting out the gles2 rendering code, so let's put
this off for just a couple of days.
Kristian
> ---
> src/compositor.c | 21 +++--
> 1 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 2b963f5..e7c2c88 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -798,10 +798,15 @@ weston_surface_attach(struct wl_surface *surface,
> struct wl_buffer *buffer)
> glTexImage2D(GL_TEXTURE_2D, 0, GL_BGRA_EXT,
>es->pitch, es->buffer->height, 0,
>GL_BGRA_EXT, GL_UNSIGNED_BYTE, NULL);
> - if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
> + if (wl_shm_buffer_get_format(buffer) == WL_SHM_FORMAT_XRGB)
> {
> es->shader = &ec->texture_shader_rgbx;
> - else
> + pixman_region32_union_rect(&es->opaque, &es->opaque,
> +0, 0,
> +buffer->width,
> +buffer->height);
> + } else {
> es->shader = &ec->texture_shader_rgba;
> + }
> } else if (ec->query_buffer(ec->egl_display, buffer,
> EGL_TEXTURE_FORMAT, &format)) {
> for (i = 0; i < es->num_images; i++)
> @@ -834,6 +839,18 @@ weston_surface_attach(struct wl_surface *surface, struct
> wl_buffer *buffer)
> break;
> }
>
> + /* opaque color formats */
> + switch (format) {
> + case EGL_TEXTURE_RGB:
> + case EGL_TEXTURE_Y_UV_WL:
> + case EGL_TEXTURE_Y_U_V_WL:
> + case EGL_TEXTURE_Y_XUXV_WL:
> + pixman_region32_union_rect(&es->opaque, &es->opaque,
> +0, 0,
> +buffer->width,
> +buffer->height);
> + }
> +
> ensure_textures(es, num_planes);
> for (i = 0; i < num_planes; i++) {
> attribs[0] = EGL_WAYLAND_PLANE_WL;
> --
> 1.7.8.6
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH 1/2] cursor: Add a default cursor theme
This theme is loaded when the specified cursor theme can not be found.
These cursors are extracted from the xorg sources and transformed into
xpm files by a small helper program (commited separately).
---
cursor/bottom_left_corner.xpm | 48 ++
cursor/bottom_right_corner.xpm | 48 ++
cursor/bottom_side.xpm | 48 ++
cursor/fleur.xpm | 48 ++
cursor/hand1.xpm | 48 ++
cursor/left_ptr.xpm| 48 ++
cursor/left_side.xpm | 47 +
cursor/right_side.xpm | 47 +
cursor/top_left_corner.xpm | 48 ++
cursor/top_right_corner.xpm| 48 ++
cursor/top_side.xpm| 48 ++
cursor/watch.xpm | 48 ++
cursor/wayland-cursor.c| 211 -
cursor/xterm.xpm | 48 ++
14 Dateien geändert, 832 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
create mode 100644 cursor/bottom_left_corner.xpm
create mode 100644 cursor/bottom_right_corner.xpm
create mode 100644 cursor/bottom_side.xpm
create mode 100644 cursor/fleur.xpm
create mode 100644 cursor/hand1.xpm
create mode 100644 cursor/left_ptr.xpm
create mode 100644 cursor/left_side.xpm
create mode 100644 cursor/right_side.xpm
create mode 100644 cursor/top_left_corner.xpm
create mode 100644 cursor/top_right_corner.xpm
create mode 100644 cursor/top_side.xpm
create mode 100644 cursor/watch.xpm
create mode 100644 cursor/xterm.xpm
diff --git a/cursor/bottom_left_corner.xpm b/cursor/bottom_left_corner.xpm
new file mode 100644
index 000..d09291f
--- /dev/null
+++ b/cursor/bottom_left_corner.xpm
@@ -0,0 +1,48 @@
+/*
+* Copyright 1999 SuSE, Inc.
+*
+* Permission to use, copy, modify, distribute, and sell this software and its
+* documentation for any purpose is hereby granted without fee, provided that
+* the above copyright notice appear in all copies and that both that
+* copyright notice and this permission notice appear in supporting
+* documentation, and that the name of SuSE not be used in advertising or
+* publicity pertaining to distribution of the software without specific,
+* written prior permission. SuSE makes no representations about the
+* suitability of this software for any purpose. It is provided "as is"
+* without express or implied warranty.
+*
+* SuSE DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL SuSE
+* BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+*
+* Author: Keith Packard, SuSE, Inc.
+*/
+
+/* XPM */
+static char *bottom_left_corner[] = {
+"16 16 3 1",
+"_ c None",
+"X c #00",
+"O c #ff",
+"",
+"OXXO",
+"OXXO_OOOOO__",
+"OXXO_OXO___OXO__",
+"OXXO_OXO__OXO___",
+"OXXO_OXO_OXO",
+"OXXO_OXOOXO_",
+"OXXO_OXOXO__",
+"OXXO_OXXOO__",
+"OXXO_OXXXO__",
+"OXXO_O__",
+"OXXO",
+"OXXO",
+"OXXO",
+"OXXO",
+"",
+};
+
+static struct hotspot bottom_left_corner_hotspot = { 1, 14 };
diff --git a/cursor/bottom_right_corner.xpm b/cursor/bottom_right_corner.xpm
new file mode 100644
index 000..a66537b
--- /dev/null
+++ b/cursor/bottom_right_corner.xpm
@@ -0,0 +1,48 @@
+/*
+* Copyright 1999 SuSE, Inc.
+*
+* Permission to use, copy, modify, distribute, and sell this software and its
+* documentation for any purpose is hereby granted without fee, provided that
+* the above copyright notice appear in all copies and that both that
+* copyright notice and this permission notice appear in supporting
+* documentation, and that the name of SuSE not be used in advertising or
+* publicity pertaining to distribution of the software without specific,
+* written prior permission. SuSE makes no representations about the
+* suitability of this software for any purpose. It is provided "as is"
+* without express or implied warranty.
+*
+* SuSE DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
+* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL SuSE
+* BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+*
+* Author: Keith Packard, SuSE, Inc.
+*/
+
+/* XPM */
+static char *bottom_right_corner[] = {
+"16 16 3 1",
+"_ c None",
+"X c #00",
+"O c #ff",
+"",
+"OXXO",
+"__OOOOO_OXXO",
+"__OXO___OXO_OXXO",
+"___OXO__OXO_OXXO",
+"OXO_OXO_OXXO",
+"_OXOOXO_O
Re: [PATCH] screensaver: fix decoding of transparency in xpm files
On Thu, 6 Sep 2012 15:23:28 +0200
Philipp Brüschweiler wrote:
> Use 0 as transparent pixel. This is needed when using premultiplied
> alpha.
> ---
> clients/wscreensaver-glue.c | 6 +++---
> 1 Datei geändert, 3 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
>
> diff --git a/clients/wscreensaver-glue.c b/clients/wscreensaver-glue.c
> index a548599..55d0a8c 100644
> --- a/clients/wscreensaver-glue.c
> +++ b/clients/wscreensaver-glue.c
> @@ -80,14 +80,14 @@ read_xpm_color(uint32_t *ctable, const char *line)
> value = strtol(&cstr[1], &end, 16);
>
> if (strcmp(cstr, "None") == 0)
> - ctable[key] = 0x00ff;
> + ctable[key] = 0x;
> else if (cstr[0] != '#' || !(cstr[1] != '\0' && *end == '\0')) {
> fprintf(stderr, "%s: error interpreting XPM color '%s'\n",
> progname, cstr);
> return;
> + } else {
> + ctable[key] = value | 0xff00;
> }
> -
> - ctable[key] = value | 0xff00;
> }
>
> static void
You wanted None decoded as transparent instead of opaque here. Should
work either way, glmatrix doesn't really use it, IIRC (takes alpha from
green channel).
I trust you tried weston-screensaver and it still looks the same, so ok
by me.
Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] screensaver: fix decoding of transparency in xpm files
Use 0 as transparent pixel. This is needed when using premultiplied
alpha.
---
clients/wscreensaver-glue.c | 6 +++---
1 Datei geändert, 3 Zeilen hinzugefügt(+), 3 Zeilen entfernt(-)
diff --git a/clients/wscreensaver-glue.c b/clients/wscreensaver-glue.c
index a548599..55d0a8c 100644
--- a/clients/wscreensaver-glue.c
+++ b/clients/wscreensaver-glue.c
@@ -80,14 +80,14 @@ read_xpm_color(uint32_t *ctable, const char *line)
value = strtol(&cstr[1], &end, 16);
if (strcmp(cstr, "None") == 0)
- ctable[key] = 0x00ff;
+ ctable[key] = 0x;
else if (cstr[0] != '#' || !(cstr[1] != '\0' && *end == '\0')) {
fprintf(stderr, "%s: error interpreting XPM color '%s'\n",
progname, cstr);
return;
+ } else {
+ ctable[key] = value | 0xff00;
}
-
- ctable[key] = value | 0xff00;
}
static void
--
1.7.12
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [call for testing] clients: add cliptest program
On Thu, 06 Sep 2012 12:41:15 +0200 Birin Sanchez wrote: > Hi Pekka, > > I gave this clipping algorithm a try and I found a weird behaviour that > I don't know if it is expected of not. See attachment 1. > > And this is how to reproduce it: > > * Move the clipping area to get it side by side with the surface, > you'll see the a green line between the two rectangles. > * Change surface orientation pressing 'n' until you get to the initial > position > > Apart from this the green line showed the intersection on all my tests. Thank you, you really did find some problematic cases there. The first green line you got should not appear, I think, since the rects are only touching, not overlapping. And the half-height green line in your screenshot could be result from rounding errors, but I'll check that, too. I accidentally found yet another problem, when reproducing yours. Good work! - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
