summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOlivier Fourdan <ofourdan@redhat.com>2017-12-15 16:43:47 +0100
committerPeter Hutterer <peter.hutterer@who-t.net>2017-12-19 10:30:42 +1000
commit170c95978530f6373bdf4488116902b273f3abf4 (patch)
treeab0833b30dd2fc11d7eab3dd993a56ef5477020e
parentc72049530503ebde493cfcd22156105557ea18d3 (diff)
xwayland: avoid race condition on new keymap
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@redhat.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-rw-r--r--hw/xwayland/xwayland-input.c2
1 files changed, 1 insertions, 1 deletions
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);