Re: [RFC weston] compositor: optimize/simplify shaders
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?
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?
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?
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?
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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?
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
>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
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
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