[PATCH] weston: Allow r5g6b5 visuals for X11 backend SHM

From: MoD The support is already present in the pixman renderer, so we can just check and use it. --- src/compositor-x11.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/src/compositor-x11.c b/src/compositor-x11.c index 1d1b6a4..d98e48d 100644 --- a/src/compositor-x11.c +++ b/src

[PATCH 3/3 v2] xwm: Use empty opaque region for windows with alpha

Window contents cannot be assumed to be fully opaque for windows drawn with a RGBA visual. The optimization of setting a full opaque region is limited to windows with a color depth != 32. --- src/xwayland/window-manager.c | 38 +- 1 file changed, 29 insertions(+

[PATCH 3/3] xwm: Don't set opaque region to cover window contents from X

Window contents cannot be assumed to be fully opaque for windows drawn with a RGBA visual. Later the optimization of setting a full opaque region can be reimplemented after checking that the windows involved aren't using RGBA visuals. The comment mentioning sampling of undefined alpha channel was

[PATCH 2/3] xwm: Check result of xcb_get_atom_name_reply

When printing debug information about atoms, the XWM would crash if the X server failed to respond to a request about atom names. In practice this occurred when the server itself crashed, e.g. when starting mplayer with the "xv" vo. --- src/xwayland/window-manager.c | 12 +--- 1 file chang

[PATCH 1/3] xwm: Define SEND_EVENT_MASK and EVENT_TYPE macros to clarify xcb event type checks

--- src/xwayland/window-manager.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/xwayland/window-manager.c b/src/xwayland/window-manager.c index 366f2e0..a021c76 100644 --- a/src/xwayland/window-manager.c +++ b/src/xwayland/window-manager.c @@ -89,6 +89,9 @@ struct

Re: [PATCH weston 17/18] xwayland: Fix the race condition when mapping a surface

I've been poking at XWayland+Weston's XWM recently and wanted to find this behavior and check that this patch is effective so I could vouch for it, but I haven't seen something that looks like windows being mapped with the wrong coordinates or size. Louis-Francis, could you explain how to reproduce

Re: Midori browser should now work on Wayland

For testing Midori against Wayland, I use "./configure --enable-gtk3 --disable-unique". But at present there hasn't been a WebkitGTK+ release that has proper wayland support. I've been using GTK3 master and the webkit patch from , rebased against W

[PATCH weston v3] toytoolkit: avoid redrawing a window between maximize and configure

Resolve a bad frame visible when maximizing toytoolkit programs with the the maximize button in decorations. Windows now use wl_display.sync requests to wait for a maximize to finish before drawing again, following suggestions from http://lists.freedesktop.org/archives/wayland-devel/2013-February/0

[PATCH weston v2] toytoolkit: avoid redrawing a window between maximize and configure

Resolve a bad frame visible when maximizing toytoolkit programs with the the maximize button in decorations. Windows now use wl_display.sync requests to wait for a maximize to finish before drawing again, following suggestions from http://lists.freedesktop.org/archives/wayland-devel/2013-February/0

Re: [PATCH weston] toytoolkit: avoid redrawing a window between when it asks to be maximized and when it gets the configure

d be done by making the widget actually >draw in >a down position, not by blocking updates like this is doing. >Otherwise >animation in the window will stop until the maximize happens, >which >makes the software look a bit dated... > >MoD wrote: >> This patch i

[PATCH weston] toytoolkit: avoid redrawing a window between when it asks to be maximized and when it gets the configure

uest a maximize. Comments would be appreciated. MoD --- clients/window.c | 49 +++-- 1 file changed, 27 insertions(+), 22 deletions(-) diff --git a/clients/window.c b/clients/window.c index 249ba6f..e8d2561 100644 --- a/clients/window.c +++ b/clients/win

[PATCH] toytoolkit: Use default cursor size

After wayland-cursor changes, this allows users to configure cursor size for toytoolkit with the XCURSOR_SIZE environment variable as documented in weston's man page. --- clients/window.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/clients/window.c b/clients/window.c inde

[PATCH] wayland-cursor: Respect XCURSOR_SIZE and accept default cursor size

Presently every toolkit using wayland-cursor hard-codes or has its own configuration for cursor size, and there is no scheme for coordination. Weston documents the XCURSOR_SIZE environment variable as affecting Wayland programs. This change brings that functionality into wayland-cursor so consum

Cursor configuration

(read from XCURSOR_SIZE with 32 as a fallback)? The latter seems preferable since it centralizes code that should perform the same behavior, but I'm not sure if the libwayland-cursor API is set in stone. If/when these two environment variables are (or should be) universally supported, they s

[PATCH] fbdev: Add an fbdev compositor backend using pixman and evdev

The fbdev backend is a welcome sight here and I've been trying it out on a Nokia N900; in the minimal testing I've done so far (some input issues on the touchpad and keyboard mean I couldn't test too much interactive usage) it works well, so thanks. However one issue I've found is that no input