Re: [RFC weston] compositor: optimize/simplify shaders

2012-09-04 Thread Pekka Paalanen 
On Fri, 31 Aug 2012 16:58:24 +0300
Pekka Paalanen  wrote:

> I couldn't find exactly duplicated vertices in cliptest, but I found
> problems:
> 
> http://people.collabora.com/~pq/geometry-test-1.png
> http://people.collabora.com/~pq/geometry-test-2.png
> http://people.collabora.com/~pq/geometry-test-3.png
> http://people.collabora.com/~pq/geometry-test-4.png
> http://people.collabora.com/~pq/geometry-test-5.png
> http://people.collabora.com/~pq/geometry-test-6.png
> 
> Later I added surface orientation mark (the red dot) and vertex
> indices:
> http://people.collabora.com/~pq/geometry-test-7.png
> This one shows a correct result.

An improved version if cliptest is at:
http://cgit.collabora.com/git/user/pq/wayland-demos.git/log/?h=cliptest

New features: keyboard controls and proper use of
weston_surface::transform.enabled, see
http://cgit.collabora.com/git/user/pq/wayland-demos.git/tree/clients/cliptest.c?h=cliptest#n24

The surface orientation dot is now bright, when the surface is not
transformed.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xwayland + radeon = consistent filesystem corruption Re: I'm the only one getting hard drive errors, right?

2012-09-04 Thread darxus 
On 09/04, Michel Dänzer wrote:
> On Mon, 2012-09-03 at 15:15 -0400, dar...@chaosreigns.com wrote: 
> > 
> > I had the latest get masters of everything as of 2012-09-03 08:36 -0400.  
> > weston commit 8538b22ff4ad8879b4e3288be053508167562859
> > wayland commit 2be6e0ed142bac669398a9ad26d33fa53216
> > raof's xf86-video-ati xwayland branch commit 
> > 8dc07e63eaf8909f7046bf746a119ec749352441
> 
> What about Mesa, the kernel and libdrm?

Mesa and libdrm are latest get masters, kernel is whatever ubuntu oneric
currently has.

mesa: commit e1673d200133b49685d07cc81826bfe4a61c0fe6
drm: commit 92fd0ce4f659d7b0680543e9e5b96a3c7737a5f3
kernel: Linux dancer 3.5.0-11-generic #11-Ubuntu SMP Thu Aug 16 21:03:52 UTC 
2012 x86_64 x86_64 x86_64 GNU/Linux


I posted to the ext4 mailing list, got a reply from Theodore Ts'o:
http://www.spinics.net/lists/linux-ext4/msg33724.html 
Not really sure where to go from here.

-- 
"I don't want people who want to dance, I want people who have to dance."
--George Balanchine
http://www.ChaosReigns.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xwayland + radeon = consistent filesystem corruption Re: I'm the only one getting hard drive errors, right?

2012-09-04 Thread darxus 
Somebody mentioned I failed to point out here that both of these, three
months apart, mention the same inode:

On 09/03, dar...@chaosreigns.com wrote:
> [732715.730069] EXT4-fs error (device sda1): ext4_ext_search_left:1275: inode 
> #21374007: comm flush-8:0: ix (10742) != EXT_FIRST_INDEX (0) (depth 1)!

> On 05/30, dar...@chaosreigns.com wrote:
> > [  496.347230] EXT4-fs error (device sda1): ext4_ext_search_left:1275: 
> > inode #21374007: comm flush-8:0:ix (10742) != EXT_FIRST_INDEX (0) (depth 1)!


Part of Ted Ts'o's response:

> If you did run e2fsck, and the file system corruptions was fixed
> between the two times that you saw the EXT4-fs error message, then
> that is very interesting.  I would discount scribbling over kernel
> memory, since it would be pretty unusual that the exact same inode and
> the exact same block had gotten corrupted in exactly the same way.  It
> could be a bug in the graphics driver, perhaps triggered by the way
> Wayland is using said graphics driver.
> 
> That also seems fairly hard to credit, so I'm going to hope you didn't
> actually run e2fsck to fix the file system corruption

I know last time this happened the first thing I did was reboot and let
fsck do whatever it wanted.  Seems unlikely that this would've been missed.


I agree this all seems incredibly unlikely, and would love suggestions.

-- 
"A ship in a port is safe, but that's not what ships are built for."
-Grace Murray Hopper
http://www.ChaosReigns.com
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to debug the xserver?

2012-09-04 Thread Tiago Vignatti 

On 09/03/2012 11:32 PM, Bill Spitzak wrote:

Thanks, it seems to be working now.


cool.



For X I'm getting a lot of black windows that only occasionally update,
drawing pieces of their contents as those areas are drawn.


I'm not seeing this here. What I was seeing is some glitches, like 
flashing, when windows are opened probably because of the opaque region 
(flashes are black so that's why I assume opaque region). I never had 
time to investigate the reason why though. Menus type of windows are 
easy to notice this.




Also if you
try to resize the top edge of the window it instead resizes as though
you are moving the bottom edge in the opposite direction.


same here. Should be easy to solve.


> There also isn't any close box or other toytoolkit decorations.

same here. This is due the fact that xwm has to draw itself the 
decorations in opposing with toykit clients or other toolkits that 
you're used to. We're trying to change it now though making xwm a client.


Tiago
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xwayland + radeon = consistent filesystem corruption Re: I'm the only one getting hard drive errors, right?

2012-09-04 Thread Pavel Sterin 
> I agree this all seems incredibly unlikely, and would love suggestions.

You probably have already done it, but in case not check your RAM with 
memcheck and run a long selfcheck on the hdd with smartctl just to be sure. 
Especially RAM errors can have peculiar effects, i.e I once had a system woking 
just fine, but the moment I wanted to compile something big I got the strangest 
errors rangig from simple segfaults to kernel oops.

Pavel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 1/3] compositor: reduce the number of triangles

2012-09-04 Thread Pekka Paalanen 
The intersection of two rectangles is guaranteed to be convex. Therefore
we do not need a center vertex for the triangle fan, we can simply use
the whatever first vertex the intersection polygon has. This reduces the
number of triangles, while still painting the exact same area.

While at it, emit_vertex() nested function is factored into the
for-loop, since that is the only calling site left.

Comments are updated to reflect the changes, and some unrelated comment
fixes are in repaint_region().

Signed-off-by: Pekka Paalanen 
Cc: Rob Clark 
---
 src/compositor.c |   55 -
 1 files changed, 17 insertions(+), 38 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 4288e89..9befd0f 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1160,10 +1160,10 @@ texture_region(struct weston_surface *es, 
pixman_region32_t *region,
rects = pixman_region32_rectangles(region, &nrects);
surf_rects = pixman_region32_rectangles(surf_region, &nsurf);
 
-   /* worst case we can have 10 vertices per rect (ie. clipped into
+   /* worst case we can have 8 vertices per rect (ie. clipped into
 * an octagon):
 */
-   v = wl_array_add(&ec->vertices, nrects * nsurf * 10 * 4 * sizeof *v);
+   v = wl_array_add(&ec->vertices, nrects * nsurf * 8 * 4 * sizeof *v);
vtxcnt = wl_array_add(&ec->vtxcnt, nrects * nsurf * sizeof *vtxcnt);
 
inv_width = 1.0 / es->pitch;
@@ -1173,26 +1173,14 @@ texture_region(struct weston_surface *es, 
pixman_region32_t *region,
pixman_box32_t *rect = &rects[i];
for (j = 0; j < nsurf; j++) {
pixman_box32_t *surf_rect = &surf_rects[j];
-   GLfloat cx, cy;
+   GLfloat sx, sy;
GLfloat ex[8], ey[8];  /* edge points in screen 
space */
int n;
 
-   void emit_vertex(GLfloat gx, GLfloat gy)
-   {
-   GLfloat sx, sy;
-   surface_from_global_float(es, gx, gy, &sx, &sy);
-   /* In groups of 4 attributes, first two are 
'position', 2nd two
-* are 'texcoord'.
-*/
-   *(v++) = gx;
-   *(v++) = gy;
-   *(v++) = sx * inv_width;
-   *(v++) = sy * inv_height;
-   }
-
/* The transformed surface, after clipping to the clip 
region,
 * can have as many as eight sides, emitted as a 
triangle-fan.
-* The first vertex is the center, followed by each 
corner.
+* The first vertex in the triangle fan can be chosen 
arbitrarily,
+* since the area is guaranteed to be convex.
 *
 * If a corner of the transformed surface falls outside 
of the
 * clip region, instead of emitting one vertex for the 
corner
@@ -1201,33 +1189,24 @@ texture_region(struct weston_surface *es, 
pixman_region32_t *region,
 *
 * To do this, we first calculate the (up to eight) 
points that
 * form the intersection of the clip rect and the 
transformed
-* surface. After that we calculate the average to 
determine
-* the center point, and emit the center and edge 
vertices of
-* the fan.
+* surface.
 */
n = calculate_edges(es, rect, surf_rect, ex, ey);
if (n < 3)
continue;
 
-   /* calculate/emit center point: */
-   cx = 0;
-   cy = 0;
+   /* emit edge points: */
for (k = 0; k < n; k++) {
-   cx += ex[k];
-   cy += ey[k];
+   surface_from_global_float(es, ex[k], ey[k], 
&sx, &sy);
+   /* position: */
+   *(v++) = ex[k];
+   *(v++) = ey[k];
+   /* texcoord: */
+   *(v++) = sx * inv_width;
+   *(v++) = sy * inv_height;
}
-   cx /= n;
-   cy /= n;
-   emit_vertex(cx, cy);
-
-   /* then emit edge points: */
-   for (k = 0; k < n; k++)
-   emit_vertex(ex[k], ey[k]);
-
-   /* and close the fan: */
-

[PATCH weston 2/3] compositor: do not duplicate ARRAY_SIZE

2012-09-04 Thread Pekka Paalanen 
Signed-off-by: Pekka Paalanen 
---
 src/compositor.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 9befd0f..868afe9 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -55,9 +55,6 @@
 #include "../shared/os-compatibility.h"
 #include "git-version.h"
 
-#define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
-
-
 static struct wl_list child_process_list;
 static struct weston_compositor *segv_compositor;
 
@@ -1246,7 +1243,7 @@ triangle_fan_debug(struct weston_surface *surface, int 
first, int count)
 
glUseProgram(compositor->solid_shader.program);
glUniform4fv(compositor->solid_shader.color_uniform, 1,
-   color[color_idx++ % ARRAY_SIZE(color)]);
+   color[color_idx++ % ARRAY_LENGTH(color)]);
glDrawElements(GL_LINES, nelems, GL_UNSIGNED_SHORT, buffer);
glUseProgram(compositor->current_shader->program);
free(buffer);
-- 
1.7.8.6

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston 3/3] compositor: do not round a zero area to non-zero

2012-09-04 Thread Pekka Paalanen 
surface_accumulate_damage() will call surface_compute_bbox() with the
extents of the surface damage region, for transformed surfaces only. If
there is no damage, surface_compute_bbox() will round up the empty
rectangle to a 1x1 rectangle. Triangles are produced for this 1x1
rectangle intersected with the surface.

The problem showed up with the triangle fan debug, where some seemingly
garbage pixels showed up relative to rotated surfaces.

Fix this by explicitly checking, that the area, for which a bounding box
is being computed for, is not zero.

Note, that the bbox will also be empty if only one of width and height
is zero. We do not paint things with zero thickness.

Signed-off-by: Pekka Paalanen 
Cc: Rob Clark 
---
 src/compositor.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index 868afe9..2b963f5 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -347,6 +347,12 @@ surface_compute_bbox(struct weston_surface *surface, 
int32_t sx, int32_t sy,
GLfloat int_x, int_y;
int i;
 
+   if (width == 0 || height == 0) {
+   /* avoid rounding empty bbox to 1x1 */
+   pixman_region32_init(bbox);
+   return;
+   }
+
for (i = 0; i < 4; ++i) {
GLfloat x, y;
weston_surface_to_global_float(surface,
-- 
1.7.8.6

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

XWayland on i915GM

2012-09-04 Thread Knut Petersen 

System: Pentium M Dothan, i915GM, linux 3.6-rc*, xorg and wayland/weston fresh 
git.

Could anybody please confirm that xwayland does (or does not) work on that 
hardware?
I don´t have problems to build the software, but any starting x client 
immediately kills xwayland:

[17:52:09.475] weston 0.95.0
http://wayland.freedesktop.org/
Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=weston
Build: 0.95.0-162-g8538b22 shell: Improve focus handling when moving surfaces 
between workspaces (2012-08-31 19:51:55 -0400)
[17:52:09.478] OS: Linux, 3.6.0-rc3-main+, #7 PREEMPT Sun Aug 26 21:03:24 CEST 
2012, i686
[17:52:09.479] Loading module '/home/knut/xorg/WX/usr/lib/weston/x11-backend.so'
[17:52:09.522] initializing x11 backend
[17:52:09.720] EGL version: 1.4 (DRI2)
[17:52:09.721] EGL vendor: Mesa Project
[17:52:09.721] EGL client APIs: OpenGL OpenGL_ES2
[17:52:09.722] EGL extensions: EGL_MESA_drm_image EGL_WL_bind_wayland_display
EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_image
EGL_KHR_gl_renderbuffer_image EGL_KHR_surfaceless_context
EGL_KHR_create_context EGL_NOK_swap_region
EGL_NOK_texture_from_pixmap EGL_NV_post_sub_buffer
[17:52:09.725] GL version: OpenGL ES 2.0 Mesa 9.0-devel (git-73dd820)
[17:52:09.725] GLSL version: OpenGL ES GLSL ES 1.0.16
[17:52:09.725] GL vendor: Intel Open Source Technology Center
[17:52:09.725] GL renderer: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
[17:52:09.725] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA
GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
GL_OES_element_index_uint GL_OES_fbo_render_mipmap
GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot
GL_OES_EGL_image GL_OES_depth_texture
GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV
GL_APPLE_texture_max_level GL_EXT_read_format_bgra
GL_NV_fbo_color_attachments GL_OES_vertex_array_object
GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
[17:52:10.005] x11 output 1024x640, window id 23068679
[17:52:10.005] Loading module '/home/knut/xorg/WX/usr/lib/weston/xwayland.so'
[17:52:10.066] unlinking stale lock file /tmp/.X1-lock
[17:52:10.066] unlinking stale lock file /tmp/.X2-lock
[17:52:10.068] xserver listening on display :2
[17:52:10.069] Loading module 
'/home/knut/xorg/WX/usr/lib/weston/desktop-shell.so'
[17:52:10.100] launching '/home/knut/xorg/WX/usr/lib/weston-desktop-shell'
[17:52:10.101] libwayland: using socket /home/knut/tmp/wayland-0
[17:52:19.643] forked X server, pid 6381

Current version of pixman: 0.27.3
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/home/knut/xorg/WX/var/log/Xorg.2.log", Time: Tue Sep 4 
17:52:19 2012
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
xdnd_atom: 69
wayland_drm_screen_init, device name /dev/dri/card0
opened drm fd: 6
xwl_input_delayed_init
[17:52:20.853] xfixes version: 4.0
[17:52:20.914] caught segv
[17:52:20.915] [08055c15] -- (/home/knut/xorg/WX/usr/bin/weston)
[17:52:20.915] [b770c40c] __kernel_rt_sigreturn ()
[17:52:20.916] [b5a9b521] -- 
(/home/knut/xorg/WX/usr/lib/weston/xwayland.so)
[17:52:20.916] [b5a9b5d6] -- 
(/home/knut/xorg/WX/usr/lib/weston/xwayland.so)
[17:52:20.916] [b5a9d1ab] -- 
(/home/knut/xorg/WX/usr/lib/weston/xwayland.so)
[17:52:20.916] [b5a9e1a3] -- 
(/home/knut/xorg/WX/usr/lib/weston/xwayland.so)
[17:52:20.917] [b5aa041a] -- 
(/home/knut/xorg/WX/usr/lib/weston/xwayland.so)
[17:52:20.917] [b742a318] -- 
(/home/knut/xorg/WX/usr/lib/libwayland-server.so.0)
[17:52:20.917] [b7421522] ffi_call_SYSV (/usr/lib/libffi.so.4)
[17:52:20.917] [b74212be] ffi_call (/usr/lib/libffi.so.4)
[17:52:20.918] [b742eaa5] -- 
(/home/knut/xorg/WX/usr/lib/libwayland-server.so.0)
[17:52:20.918] [b7428fb1] -- 
(/home/knut/xorg/WX/usr/lib/libwayland-server.so.0)
[17:52:20.918] [b742c71d] -- 
(/home/knut/xorg/WX/usr/lib/libwayland-server.so.0)
[17:52:20.918] [b742d065] wl_event_loop_dispatch 
(/home/knut/xorg/WX/usr/lib/libwayland-server.so.0)
[17:52:20.919] [b742a896] wl_display_run 
(/home/knut/xorg/WX/usr/lib/libwayland-server.so.0)
[17:52:20.919] [08056679] -- (/home/knut/xorg/WX/usr/bin/weston)
[17:52:20.919] [b6bc7003] __libc_start_main (/lib/libc.so.6)
[17:52:20.919] [0804d191] -- (/home/knut/xorg/WX/usr/bin/weston)

cu,
Knut
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] test-text-client: fix compile error

2012-09-04 Thread U. Artie Eoff 
From: "U. Artie Eoff" 

Pass surface to text_model_factory_create_text_model.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=54502

Signed-off-by: U. Artie Eoff 
---
 tests/test-text-client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/test-text-client.c b/tests/test-text-client.c
index 877fbc6..828f3a0 100644
--- a/tests/test-text-client.c
+++ b/tests/test-text-client.c
@@ -160,7 +160,7 @@ create_text_model(int fd, struct display *display)
char buf[64];
int len;
 
-   display->text_model = 
text_model_factory_create_text_model(display->factory);
+   display->text_model = 
text_model_factory_create_text_model(display->factory, display->surface);
text_model_add_listener(display->text_model, &text_model_listener, 
display);
wl_display_flush(display->display);
 
-- 
1.7.11.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XWayland on i915GM

2012-09-04 Thread Tiago Vignatti 

On 09/04/2012 06:56 PM, Knut Petersen wrote:

System: Pentium M Dothan, i915GM, linux 3.6-rc*, xorg and wayland/weston
fresh git.

Could anybody please confirm that xwayland does (or does not) work on
that hardware?
I don´t have problems to build the software, but any starting x client
immediately kills xwayland:


I don't think the hardware is the problem.

You're compiling Xwayland without debugging symbols so it's a bit tricky 
to tell what's going on, but my guess is that you're facing the same 
issues other guys had here on the ml; try to check if you're using the 
correct version of libxtrans:


http://lists.freedesktop.org/archives/wayland-devel/2012-August/005157.html

Cheers,
   Tiago
___
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

2012-09-04 Thread Bill Spitzak 



Pekka Paalanen wrote:

On Mon, 03 Sep 2012 13:36:47 -0700
Bill Spitzak  wrote:

I think changing the name at the lowest level as I did it is the correct 
solution. I see no way anybody can use this unless they can tell the x 
server to ignore any existing xorg.conf file. Changing it at the final 
program seems much cleaner than requiring every wrapping program to pass 
a --config switch.


Btw. did you ever test that your config name changes work also with
config dirs, like /etc/X11/xorg.conf.d/?

Don't take this as on opinion about what is the right approach, only
X.org server devs can take a stand (i.e. the discussion should be cc'd
to the appropriate mailing list). This is just a detail that came to my
mind.


I did not do any real testing, but it looked like all uses of those %C 
and %P, etc, symbols was that all the search paths looked in / first and 
then in $PREFIX second. This meant that it was impossible to override a 
system file by putting something into $PREFIX.


However I then realized that changing the search path would not fix any 
xwayland because a "real" installation would not have a $PREFIX anyway, 
so there had to be a different method to give wayland a different .conf 
file. So at that point I switched to using a different name for the 
.conf file.


I don't know if there are other conflicting files in xorg.conf.d. If so 
they may need renaming for the wayland version too.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XWayland on i915GM

2012-09-04 Thread Knut Petersen 



I don't think the hardware is the problem.

You're compiling Xwayland without debugging symbols so it's a bit tricky to 
tell what's going on, but my guess is that you're facing the same issues other 
guys had here on the ml; try to check if you're using the correct version of 
libxtrans:


Sorry, it´s not that easy. I built _everything_ that belongs to Xorg / Wayland/ Weston 
from the git repositories with "-g3 -O0 -H".
So it´s definitely not an old libxtrans, and I greped  the log to ensure that 
not a single old Xorg component was used.

cu,
 Knut
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] workspaces: don't segfault on invalid move_surface_to_workspace request

2012-09-04 Thread Kristian Høgsberg 
On Sat, Sep 01, 2012 at 04:03:05PM +0200, Philipp Brüschweiler wrote:
> Also fixes the off-by-one in toytoolkit that exposed the issue.

Thanks, applied.

> ---
>  clients/window.c | 2 +-
>  src/shell.c  | 4 
>  2 Dateien geändert, 5 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
> 
> diff --git a/clients/window.c b/clients/window.c
> index 472aabf..4ddbd2f 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -1704,7 +1704,7 @@ frame_menu_func(struct window *window, int index, void 
> *data)
>   break;
>   case 3: /* move to workspace below */
>   display = window->display;
> - if (display->workspace < display->workspace_count)
> + if (display->workspace < display->workspace_count - 1)
>   
> workspace_manager_move_surface(display->workspace_manager,
>  window->surface,
>  display->workspace + 1);
> diff --git a/src/shell.c b/src/shell.c
> index 6610927..06d8684 100644
> --- a/src/shell.c
> +++ b/src/shell.c
> @@ -548,6 +548,7 @@ static struct workspace *
>  get_workspace(struct desktop_shell *shell, unsigned int index)
>  {
>   struct workspace **pws = shell->workspaces.array.data;
> + assert(index < shell->workspaces.num);
>   pws += index;
>   return *pws;
>  }
> @@ -849,6 +850,9 @@ move_surface_to_workspace(struct desktop_shell *shell,
>   if (workspace == shell->workspaces.current)
>   return;
>  
> + if (workspace >= shell->workspaces.num)
> + workspace = shell->workspaces.num - 1;
> +
>   from = get_current_workspace(shell);
>   to = get_workspace(shell, workspace);
>  
> -- 
> 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] toytoolkit: supply correct widget in motion_handler callback

2012-09-04 Thread Kristian Høgsberg 
On Sat, Sep 01, 2012 at 04:21:40PM +0200, Philipp Brüschweiler wrote:
> ---
>  clients/window.c | 2 +-
>  1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)

Ah yes, nice catch.  Committed.

Kristian

> diff --git a/clients/window.c b/clients/window.c
> index 4ddbd2f..330d96f 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -2013,7 +2013,7 @@ pointer_handle_motion(void *data, struct wl_pointer 
> *pointer,
>   else
>   widget = input->focus_widget;
>   if (widget && widget->motion_handler)
> - cursor = widget->motion_handler(input->focus_widget,
> + cursor = widget->motion_handler(widget,
>   input, time, sx, sy,
>   widget->user_data);
>  
> -- 
> 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 1/3] xwayland: replace opaque_rect, fix an alpha problem

2012-09-04 Thread Kristian Høgsberg 
On Mon, Sep 03, 2012 at 04:48:41PM +0300, Pekka Paalanen wrote:
> Remove weston_surface::opaque_rect completely.
> 
> Instead, set the opaque region in xwayland.
> 
> Before this patch, black text in xterm was transparent. Now it is not.
> 
> However, this patch fixes only a part of the alpha problem. If you apply
> full-surface alpha with super+alt+wheel, the problem reappears. This
> problem is still due to bad alpha channel contents on xwayland windows.

Very nice, that's a better solution.  Series applied.

Kristian

> Signed-off-by: Pekka Paalanen 
> ---
>  src/compositor.c  |4 
>  src/compositor.h  |1 -
>  src/xwayland/window-manager.c |   28 
>  3 files changed, 16 insertions(+), 17 deletions(-)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index 9ce44d4..5e9a0c2 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -243,10 +243,6 @@ weston_surface_create(struct weston_compositor 
> *compositor)
>  
>   surface->compositor = compositor;
>   surface->alpha = 1.0;
> - surface->opaque_rect[0] = 0.0;
> - surface->opaque_rect[1] = 0.0;
> - surface->opaque_rect[2] = 0.0;
> - surface->opaque_rect[3] = 0.0;
>   surface->pitch = 1;
>  
>   surface->num_textures = 0;
> diff --git a/src/compositor.h b/src/compositor.h
> index 96a0477..38c2657 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -399,7 +399,6 @@ struct weston_surface {
>   struct wl_list layer_link;
>   struct weston_shader *shader;
>   GLfloat color[4];
> - GLfloat opaque_rect[4];
>   GLfloat alpha;
>   struct weston_plane *plane;
>  
> diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c
> index e705fec..65eb11a 100644
> --- a/src/xwayland/window-manager.c
> +++ b/src/xwayland/window-manager.c
> @@ -717,17 +717,19 @@ weston_wm_window_draw_decoration(void *data)
>   cairo_destroy(cr);
>  
>   if (window->surface) {
> + pixman_region32_fini(&window->surface->opaque);
> + pixman_region32_init_rect(&window->surface->opaque, 0, 0,
> +   width, height);
> +
>   /* We leave an extra pixel around the X window area to
>* make sure we don't sample from the undefined alpha
>* channel when filtering. */
> - window->surface->opaque_rect[0] =
> - (double) (x - 1) / width;
> - window->surface->opaque_rect[1] =
> - (double) (x + window->width + 1) / width;
> - window->surface->opaque_rect[2] =
> - (double) (y - 1) / height;
> - window->surface->opaque_rect[3] =
> - (double) (y + window->height + 1) / height;
> + pixman_region32_intersect_rect(&window->surface->opaque,
> +&window->surface->opaque,
> +x - 1, y - 1,
> +window->width + 2,
> +window->height + 2);
> + window->surface->geometry.dirty = 1;
>  
>   pixman_region32_init_rect(&window->surface->input,
> t->margin, t->margin,
> @@ -740,13 +742,15 @@ static void
>  weston_wm_window_schedule_repaint(struct weston_wm_window *window)
>  {
>   struct weston_wm *wm = window->wm;
> + int width, height;
>  
>   if (window->frame_id == XCB_WINDOW_NONE) {
>   if (window->surface != NULL) {
> - window->surface->opaque_rect[0] = 0.0;
> - window->surface->opaque_rect[1] = 1.0;
> - window->surface->opaque_rect[2] = 0.0;
> - window->surface->opaque_rect[3] = 1.0;
> + weston_wm_window_get_frame_size(window, &width, 
> &height);
> + pixman_region32_fini(&window->surface->opaque);
> + pixman_region32_init_rect(&window->surface->opaque, 0, 
> 0,
> +   width, height);
> + window->surface->geometry.dirty = 1;
>   }
>   return;
>   }
> -- 
> 1.7.8.6
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 3/3] compositor: do not round a zero area to non-zero

2012-09-04 Thread Kristian Høgsberg 
On Tue, Sep 04, 2012 at 01:55:44PM +0300, Pekka Paalanen wrote:
> surface_accumulate_damage() will call surface_compute_bbox() with the
> extents of the surface damage region, for transformed surfaces only. If
> there is no damage, surface_compute_bbox() will round up the empty
> rectangle to a 1x1 rectangle. Triangles are produced for this 1x1
> rectangle intersected with the surface.
> 
> The problem showed up with the triangle fan debug, where some seemingly
> garbage pixels showed up relative to rotated surfaces.
> 
> Fix this by explicitly checking, that the area, for which a bounding box
> is being computed for, is not zero.
> 
> Note, that the bbox will also be empty if only one of width and height
> is zero. We do not paint things with zero thickness.

All three patches look good, applied.

Kristian

> Signed-off-by: Pekka Paalanen 
> Cc: Rob Clark 
> ---
>  src/compositor.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/src/compositor.c b/src/compositor.c
> index 868afe9..2b963f5 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -347,6 +347,12 @@ surface_compute_bbox(struct weston_surface *surface, 
> int32_t sx, int32_t sy,
>   GLfloat int_x, int_y;
>   int i;
>  
> + if (width == 0 || height == 0) {
> + /* avoid rounding empty bbox to 1x1 */
> + pixman_region32_init(bbox);
> + return;
> + }
> +
>   for (i = 0; i < 4; ++i) {
>   GLfloat x, y;
>   weston_surface_to_global_float(surface,
> -- 
> 1.7.8.6
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] test-text-client: fix compile error

2012-09-04 Thread Kristian Høgsberg 
On Tue, Sep 04, 2012 at 10:53:07AM -0700, U. Artie Eoff wrote:
> From: "U. Artie Eoff" 
> 
> Pass surface to text_model_factory_create_text_model.
> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=54502

Thanks, applied.

Kristian

> Signed-off-by: U. Artie Eoff 
> ---
>  tests/test-text-client.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/test-text-client.c b/tests/test-text-client.c
> index 877fbc6..828f3a0 100644
> --- a/tests/test-text-client.c
> +++ b/tests/test-text-client.c
> @@ -160,7 +160,7 @@ create_text_model(int fd, struct display *display)
>   char buf[64];
>   int len;
>  
> - display->text_model = 
> text_model_factory_create_text_model(display->factory);
> + display->text_model = 
> text_model_factory_create_text_model(display->factory, display->surface);
>   text_model_add_listener(display->text_model, &text_model_listener, 
> display);
>   wl_display_flush(display->display);
>  
> -- 
> 1.7.11.2
> 
> ___
> 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

[PATCH] test-client: initialize input instance.

2012-09-04 Thread U. Artie Eoff 
From: "U. Artie Eoff" 

In seat_handle_capabilities, if input->pointer is not properly
initialized, then it will contain an arbitrary value and results
in the wl_pointer listener not getting registered if that value
is not 0/null.  Thus, use calloc to initialize the "input" instance.

This fixes https://bugs.freedesktop.org/show_bug.cgi?id=49937

Signed-off-by: U. Artie Eoff 
---
 tests/test-client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/test-client.c b/tests/test-client.c
index ba084d8..0009a8e 100644
--- a/tests/test-client.c
+++ b/tests/test-client.c
@@ -250,7 +250,7 @@ handle_global(struct wl_display *_display, uint32_t id,
wl_display_bind(display->display,
id, &wl_compositor_interface);
} else if (strcmp(interface, "wl_seat") == 0) {
-   input = malloc(sizeof *input);
+   input = calloc(1, sizeof *input);
input->seat = wl_display_bind(display->display, id,
  &wl_seat_interface);
input->pointer_focus = NULL;
-- 
1.7.11.2

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: xwayland + radeon = consistent filesystem corruption Re: I'm the only one getting hard drive errors, right?

2012-09-04 Thread darxus 
I reproduced the problem with chromium under X, not running wayland.  Woo.
Just by loading up chromium and playing back a youtube video for a while.

(After doing a long smartctl test and fsck of the partition.)

[ 4043.097706] EXT4-fs error (device sda1): ext4_ext_search_left:1275: inode 
#21374007: comm flush-8:0: ix (10742) != EXT_FIRST_INDEX (0) (depth 1)!
[ 4043.097711] Aborting journal on device sda1-8.
[ 4043.097873] EXT4-fs (sda1): Remounting filesystem read-only
[ 4043.097883] EXT4-fs error (device sda1) in ext4_da_writepages:3033: IO 
failure
[ 4043.098011] EXT4-fs (sda1): ext4_da_writepages: jbd2_start: 962 pages, ino 
21374007; err -30

Same inode again.  Which I guess I didn't mention on this list turned out
to be a file in chromium's cache:

$ sudo find . -inum 21374007 -print
./home/darxus/.cache/chromium/Default/Cache/data_3

Still curious... wtf... but at least it's not wayland.  I'll continue this
on the ext4 list.

On 09/03, dar...@chaosreigns.com wrote:
> [732715.730069] EXT4-fs error (device sda1): ext4_ext_search_left:1275: inode 
> #21374007: comm flush-8:0: ix (10742) != EXT_FIRST_INDEX (0) (depth 1)!
> [732715.730084] Aborting journal on device sda1-8.
> [732715.730269] EXT4-fs (sda1): Remounting filesystem read-only
> [732715.730278] EXT4-fs error (device sda1) in ext4_da_writepages:3033: IO 
> failure
> [732715.730440] EXT4-fs (sda1): ext4_da_writepages: jbd2_start: 589 pages, 
> ino 21374007; err -30
> 
> This hasn't happened in three months.  The last time I saw it was the
> last time I ran xwayland.  While correlation does not imply causation,
> and it *could* be a coincidence, I'm really not willing to entertain
> that possibility as realistic.
> 
> This time I used RAOF's X DDX (and updated the xwayland instructions
> for Radeon / ATI to use it).  Last time I was using timon37's DDX.  I don't
> know if they share code.  I don't know if they're at fault.
> 
> I was using the DRM backend.  I ran "make install" as a non-root user, and
> then set weston-launch as owned by root and +s, and ran weston-launch.  I
> did not have xserver set suid root.
> 
> I was playing a video on youtube in chromium vix xwayland when X crashed
> (taking firefox, the only other X client I was running, out with it.)
> And was chatting with folks in IRC about X's failure to respawn when I
> realized my filesystem had been remounted readonly.  Then dug the above
> output out of dmesg.
> 
> I was working on updating my "state of wayland" page to say that wayland
> was looking pretty usable now :/
> 
> fsck said lots of scary things after rebooting, I had to manually confirm
> it wanted to do many of them.  I have photos if anyone is interested
> in details.  Lots of "Free blocks count wrong for group... Fix(y)?" and
> "Free inodes count wrong for group... Fix(y)?"  A "Block bitmap
> differences..."
> 
> I don't know for sure if I lost anything, but have not yet
> seen evidence that I did.  I have pretty good backups.
> 
> 
> 12:15 < pq> either xwayland triggers some fs bug, or triggers a gfx driver
> bug, which then scribbles over kernel memory - or faulty hw. Can't know.
> 12:16 < soreau> either way, it's a fairly serious problem
> 
> I agree with this assessment.
> 
> 
> So far, I think it has only affected the filesystem I was using at the time
> (I basically only use one partition per linux install).  So I may be
> willing to do more testing on a dedicated testing partition.
> 
> This graphics card needed to go on ubuntu's grub gfxpayload blacklist,
> because for some reason retaining the graphics mode from grub to X breaks
> on some graphics cards, including this one.  Seems unlikely to be directly
> related, just trying to provide all possibly relevant info I have.  The bug
> for this was:  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971204
> 
> I was running an up to date ubuntu oneric install.  
> 
> lspci output:
> 
> 05:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Barts 
> XT [Radeon HD 6800 Series] (prog-if 00 [VGA controller])
> Subsystem: Hightech Information System Ltd. Device 2010
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 46
> Region 0: Memory at d000 (64-bit, prefetchable) [size=256M]
> Region 2: Memory at fbfc (64-bit, non-prefetchable) [size=128K]
> Region 4: I/O ports at e000 [size=256]
> Expansion ROM at fbfa [disabled] [size=128K]
> Capabilities: 
> Kernel driver in use: radeon
> Kernel modules: radeon
> 
> 
> I had the latest get masters of everything as of 2012-09-03 08:36 -0400.  
> weston commit 8538b22ff4ad8879b4e3288be053508167562859
> wayland commit 2be6e0ed142bac669398a9ad26d33fa53216
> raof's xf86-video-ati xwayland branch c

[PATCH] compositor: fix overflow issue when calculate msecs of vblank

2012-09-04 Thread Wang, Quanxian 
>From "Quanxian Wang" mailto:quanxian.w...@intel.com>>

commit f7b156cef1ed8081df6f25cc0e66c8d7fbf414fc
Author: Wang Quanxian 
Date:   Wed Sep 5 11:30:38 2012 +0800

Change int to long to avoid the overflow when calculation vblank msecs

secs and nsecs are from vblank event, the number of secs is very 
big(134xxx),
when turns secs to msecs(multiple 1000), it will exceed uint32
max value.

Signed-Off-By Quanxian Wang 

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index df81aba..8b6285c 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -447,7 +447,7 @@ vblank_handler(int fd, unsigned int frame, unsigned int 
sec, unsigned int usec,
struct drm_sprite *s = (struct drm_sprite *)data;
struct drm_compositor *c = s->compositor;
struct drm_output *output = s->output;
-   uint32_t msecs;
+   uint64_t msecs = 0;

output->vblank_pending = 0;

@@ -480,7 +480,7 @@ page_flip_handler(int fd, unsigned int frame,
  unsigned int sec, unsigned int usec, void *data)
 {
struct drm_output *output = (struct drm_output *) data;
-   uint32_t msecs;
+   uint64_t msecs=0;

output->page_flip_pending = 0;

@@ -496,7 +496,7 @@ page_flip_handler(int fd, unsigned int frame,
output->next = NULL;

if (!output->vblank_pending) {
-   msecs = sec * 1000 + usec / 1000;
+   msecs = (uint64_t)sec * 1000 + (uint64_t)usec / 1000;
weston_output_finish_frame(&output->base, msecs);
}
 }
diff --git a/src/compositor.c b/src/compositor.c
index f4263ac..37c52bc 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1026,7 +1026,7 @@ weston_output_damage(struct weston_output *output)

 static void
 fade_frame(struct weston_animation *animation,
-  struct weston_output *output, uint32_t msecs)
+  struct weston_output *output, uint64_t msecs)
 {
struct weston_compositor *compositor =
container_of(animation,
@@ -1129,7 +1129,7 @@ surface_accumulate_damage(struct weston_surface *surface,
 }

 static void
-weston_output_repaint(struct weston_output *output, uint32_t msecs)
+weston_output_repaint(struct weston_output *output, uint64_t msecs)
 {
struct weston_compositor *ec = output->compositor;
struct weston_surface *es;
@@ -1222,7 +1222,7 @@ weston_compositor_read_input(int fd, uint32_t mask, void 
*data)
 }

 WL_EXPORT void
-weston_output_finish_frame(struct weston_output *output, uint32_t msecs)
+weston_output_finish_frame(struct weston_output *output, uint64_t msecs)
 {
struct weston_compositor *compositor = output->compositor;
struct wl_event_loop *loop =
diff --git a/src/compositor.h b/src/compositor.h
index 7a8058e..f49da84 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -109,7 +109,7 @@ struct weston_spring {
double current;
double target;
double previous;
-   uint32_t timestamp;
+   uint64_t timestamp;
 };

 enum {
@@ -164,7 +164,7 @@ struct weston_output {
struct weston_output_zoom zoom;
int dirty;
struct wl_signal frame_signal;
-   uint32_t frame_time;
+   uint64_t frame_time;
int disable_planes;

char *make, *model;
@@ -493,7 +493,7 @@ void
 weston_spring_init(struct weston_spring *spring,
   double k, double current, double target);
 void
-weston_spring_update(struct weston_spring *spring, uint32_t msec);
+weston_spring_update(struct weston_spring *spring, uint64_t msec);
 int
 weston_spring_done(struct weston_spring *spring);

@@ -543,7 +543,7 @@ void
 weston_plane_release(struct weston_plane *plane);

 void
-weston_output_finish_frame(struct weston_output *output, uint32_t msecs);
+weston_output_finish_frame(struct weston_output *output, uint64_t msecs);
 void
 weston_output_schedule_repaint(struct weston_output *output);
 void
diff --git a/src/util.c b/src/util.c
index 4ff451a..34b140e 100644
--- a/src/util.c
+++ b/src/util.c
@@ -42,7 +42,7 @@ weston_spring_init(struct weston_spring *spring,
 }

 WL_EXPORT void
-weston_spring_update(struct weston_spring *spring, uint32_t msec)
+weston_spring_update(struct weston_spring *spring, uint64_t msec)
 {
double force, v, current, step;


___
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

2012-09-04 Thread Pekka Paalanen 
On Tue, 04 Sep 2012 12:00:09 -0700
Bill Spitzak  wrote:

> However I then realized that changing the search path would not fix any 
> xwayland because a "real" installation would not have a $PREFIX anyway, 
> so there had to be a different method to give wayland a different .conf 
> file. So at that point I switched to using a different name for the 
> .conf file.
> 
> I don't know if there are other conflicting files in xorg.conf.d. If so 
> they may need renaming for the wayland version too.

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.


Thanks,
pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] compositor: automatically set opaque region for color formats

2012-09-04 Thread Pekka Paalanen 
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?
---
 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