Re: [PATCH] Wayland X server uses xwayand.conf instead of xorg.conf
On Wed, 05 Sep 2012 12:44:27 -0700 Bill Spitzak spit...@gmail.com wrote: Are you saying that if I make $PREFIX/etc/X11/xorg.conf.d/foo and put my config in there, xwayland will read it? And it will then ignore the xorg.conf? You need to read 'man xorg.conf'. I still do not see this solving the real problem however. The normal Xorg will follow the exact same rules, so if xwayland is compiled without $PREFIX then it is impossible to use this to make xwayland and normal Xorg see different config files. Even with $PREFIX this does not allow xwayland to see no config file, as the missing file will make it still fall back to searching everywhere and it will find the xorg.conf file that I do not want it to see. What I said was not a suggested solution but pointing out a flaw in your plan. I never mentioned $prefix. So I still feel that my solution of changing the conf file name is the only thing that will work. We can put it in xorg.conf.d if that makes some kind of sense (though I completely do not understand the purpose of this). You are missing my point. I still say: Pekka Paalanen wrote: The whole point of xorg.conf.d is that files can have any names, and they all will be read in in alphabetical order. Maybe they need a .conf suffix or not, don't know. If you are changing names, you would have to change the name of the directory. 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. 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. Thanks, pq ___ 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 birin...@gmail.com 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
Re: [PATCH] screensaver: fix decoding of transparency in xpm files
On Thu, 6 Sep 2012 15:23:28 +0200
Philipp Brüschweiler ble...@gmail.com 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
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
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: 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 k...@bitplanet.net wrote: On Wed, Sep 5, 2012 at 8:11 PM, jegde jedge bubba...@gmail.com 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 k...@bitplanet.net 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 bubba...@gmail.com 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: 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: [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
Advantages of Wayland (Re: A barebone version of Weston?)
On Thu, 6 Sep 2012 22:40:49 -0700 Mikalai Kisialiou kisial...@gmail.com wrote: clip 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
