[PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

The last cursor frame we commited before the pointer left one of our surfaces might not have been shown. In that case we'll have a cursor surface frame callback pending which we need to clear so that we can continue submitting new cursor frames. Signed-off-by: Rui Matos Reviewed-by: Daniel

[PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

The last cursor frame we commited before the pointer left one of our surfaces might not have been shown. In that case we'll have a cursor surface frame callback pending which we need to clear so that we can continue submitting new cursor frames. Signed-off-by: Rui Matos --- On Wed, Feb 3,

[PATCH] xwayland: Throttle our cursor surface updates with a frame callback

In some extreme cases with animated cursors at a high frame rate we could end up filling the wl_display outgoing buffer and end up with wl_display_flush() failing. In any case, using the frame callback to throttle ourselves is the right thing to do. Signed-off-by: Rui Matos --- On Tue, May 26

[PATCH] xwayland: Throttle our cursor surface updates with a frame callback

In some extreme cases with animated cursors at a high frame rate we could end up filling the wl_display outgoing buffer and end up with wl_display_flush() failing. In any case, using the frame callback to throttle ourselves is the right thing to do. Signed-off-by: Rui Matos --- v2: ensure that

[PATCH xwayland] xwayland: Throttle our cursor surface updates with a frame callback

In some extreme cases with animated cursors at a high frame rate we could end up filling the wl_display outgoing buffer and end up with wl_display_flush() failing. In any case, using the frame callback to throttle ourselves is the right thing to do. Signed-off-by: Rui Matos --- hw/xwayland

[PATCH] touchpad: Make sure we don't underflow tap_finger_count

If a touch begins before tap gets enabled we underflow tap_finger_count when the touch ends. This happens in practice when enabling tapping on a GUI with a touchpad click. Signed-off-by: Rui Matos --- This patch seems enough to fix the issue in my testing but I'm not familiar with the

[PATCH] doc/publican/Makefile.am: Add a missing order-only prerequisite

Otherwise a parallel make invocation could fail due to the directory not existing. Signed-off-by: Rui Matos --- doc/publican/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am index 278da12..50a6188 100644 --- a

[PATCH] protocol: Document how clients are supposed to get the xkb keycode

This encodes what everyone is doing and avoids other implementers having to guess. --- Jasper suggested that it would be nice if the compositor sent keycodes that clients could use directly as an index in the keymap. I suppose we can't do that at this point so we should at least document it clearl

[PATCH] xwayland: Destroy wl_buffers only after they are released

Destroying a wl_buffer that is still attached to a wl_surface is undefined behavior according to the wayland protocol. We should delay the destruction until we get the release event. To achieve this we need to track ownership of wl_buffers, both our own and the compositor's which occurs from eithe

[PATCH] xwayland: Destroy wl_buffers only after they are released

Destroying a wl_buffer that is still attached to a wl_surface is undefined behavior according to the wayland protocol. We should delay the destruction until we get the release event. --- So, I'm not sure why there was this comment saying that it was safe to do this, perhaps it was in an old protoc

[PATCH] input: Don't leak the initial keymap

weston_xkb_info_create() takes ownership of the xkb_keymap instance so we should drop our reference or we would leak it later if the keymap was changed. --- src/input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/input.c b/src/input.c index 2fed718..da89b47 100644 --- a/src/input.c +++

[PATCH] xwayland: Handle the wl_keyboard modifiers event

This allows us to keep track of latched and locked modifiers as well as the XKB group while the keyboard focus is on another wayland client. Note that we don't need to track depressed modifiers since wayland guarantees that we'll get them as key press events whenever we get the keyboard focus. ---

[PATCH v2 1/3] xkb: Repurpose XkbCopyDeviceKeymap to apply a given keymap to a device

This will also make it useful for cases when we have a new keymap to apply to a device but don't have a source device. --- On 21 October 2013 19:04, Daniel Stone wrote: > CopyKeyClass is only called when device->key is set. True, amended. > But for the rest: > Reviewed-by: Daniel Stone Thanks

[PATCH 3/3] xwayland: Handle keymap changes

--- hw/xfree86/xwayland/xwayland-input.c | 39 +--- include/input.h | 2 +- 2 files changed, 37 insertions(+), 4 deletions(-) diff --git a/hw/xfree86/xwayland/xwayland-input.c b/hw/xfree86/xwayland/xwayland-input.c index d031b34..ebf1af1 1006

[PATCH 2/3] xkb: Factor out a function to copy a keymap's controls unto another

--- include/xkbsrv.h | 3 +++ xkb/xkb.c| 14 +- xkb/xkbUtils.c | 23 +++ 3 files changed, 27 insertions(+), 13 deletions(-) diff --git a/include/xkbsrv.h b/include/xkbsrv.h index 83ee1d0..6a2e96e 100644 --- a/include/xkbsrv.h +++ b/include/xkbsrv.h @@ -8

[PATCH 1/3] xkb: Repurpose XkbCopyDeviceKeymap to apply a given keymap to a device

This will also make it useful for cases when we have a new keymap to apply to a device but don't have a source device. --- Xi/exevents.c| 2 +- include/xkbsrv.h | 4 ++-- xkb/xkb.c| 2 +- xkb/xkbUtils.c | 14 +++--- 4 files changed, 11 insertions(+), 11 deletions(-) diff

[PATCH xwayland] Handle wayland keymap events

These patches add support for changing the X keymap on wayland keymap events. I wonder what we should do for X client requests to change the keymap though. We could: a) somehow try to change the wayland keymap accordingly, possibly through some private compositor protocol; b) ignore such requ

[PATCH v2 4/4] clients/window: Dispose of previous keymap and state on keymap change

--- clients/window.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/clients/window.c b/clients/window.c index 5b20da5..1f32c73 100644 --- a/clients/window.c +++ b/clients/window.c @@ -3037,6 +3037,8 @@ keyboard_handle_keymap(void *data, struct wl_keyb

[PATCH v2 3/4] compositor-wayland: Handle keymap changes

--- src/compositor-wayland.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c index 77b2a2c..0fd7267 100644 --- a/src/compositor-wayland.c +++ b/src/compositor-wayland.c @@ -515,7 +515,11 @@ input_handle_keymap(void *data,

[PATCH v2 2/4] compositor-x11: Update keymap when XKB keymap changes

--- v2: - improved error handling a bit; src/compositor-x11.c | 38 -- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/src/compositor-x11.c b/src/compositor-x11.c index 704e751..6530bde 100644 --- a/src/compositor-x11.c +++ b/src/compositor-x11.

[PATCH v2 1/4] input: Add core API to update the keymap

How and when to update the keymap is left to each backend. The new keymap only becomes effective when no keys are pressed and we keep latched and locked modifiers from the previous state. --- v2: - defer updating the keymap until no keys are pressed; - keep latched and locked modifiers state;

[PATCH 4/4] clients/window: Dispose of previous keymap and state on keymap change

--- clients/window.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/clients/window.c b/clients/window.c index 5b20da5..1f32c73 100644 --- a/clients/window.c +++ b/clients/window.c @@ -3037,6 +3037,8 @@ keyboard_handle_keymap(void *data, struct wl_keyb

[PATCH 3/4] compositor-wayland: Handle keymap changes

--- src/compositor-wayland.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c index 77b2a2c..95545bc 100644 --- a/src/compositor-wayland.c +++ b/src/compositor-wayland.c @@ -515,7 +515,11 @@ input_handle_keymap(void *data,

[PATCH 2/4] compositor-x11: Update keymap when XKB keymap changes

--- src/compositor-x11.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) diff --git a/src/compositor-x11.c b/src/compositor-x11.c index 704e751..bdff323 100644 --- a/src/compositor-x11.c +++ b/src/compositor-x11.c @@ -201,6 +201,7 @@ x11_compositor_setup

[PATCH 1/4] input: Add core API to update the keymap

How and when to update the keymap is left to each backend. --- src/compositor.h | 2 ++ src/input.c | 38 ++ 2 files changed, 40 insertions(+) diff --git a/src/compositor.h b/src/compositor.h index a19d966..041758a 100644 --- a/src/compositor.h +++ b/src/

[PATCH weston] Add a way to update the keymap

We'll need something like this in mutter-wayland to allow people to add/change their keyboard layouts with gnome-control-center so I figured I'd start by implementing the basics in weston first. There's an implementation for a couple of backends and a fix for the client side which would leak on ke