[RFC PATCH xserver] xwayland: avoid race condition on new keymap
Olivier Fourdan
ofourdan at redhat.com
Fri Dec 15 15:43:47 UTC 2017
When the Wayland compositor notifies of a new keymap, for the first X11
client using the keyboard, the last slave keyboard used might still not
be set (i.e. “lastSlave” is still NULL).
As a result, the new keymap is not applied, and the first X11 window
will have the wrong keymap set initially.
Apply the new keymap to the master keyboard as long as there's one.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=791383
Signed-off-by: Olivier Fourdan <ofourdan at redhat.com>
---
Note: screencast of the problem here:
https://bugzilla.gnome.org/attachment.cgi?id=365231
“RFC” because that fixes the issue but there might be better ways to
avoid the problem?
hw/xwayland/xwayland-input.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 439903032..c613690cd 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -710,7 +710,7 @@ keyboard_handle_keymap(void *data, struct wl_keyboard *keyboard,
XkbDeviceApplyKeymap(xwl_seat->keyboard, xkb);
master = GetMaster(xwl_seat->keyboard, MASTER_KEYBOARD);
- if (master && master->lastSlave == xwl_seat->keyboard)
+ if (master)
XkbDeviceApplyKeymap(master, xkb);
XkbFreeKeyboard(xkb, XkbAllComponentsMask, TRUE);
--
2.14.3
More information about the wayland-devel
mailing list