summaryrefslogtreecommitdiff
path: root/hw
diff options
context:
space:
mode:
authorOlivier Fourdan <ofourdan@redhat.com>2017-12-15 16:43:47 +0100
committerAdam Jackson <ajax@redhat.com>2018-01-22 14:06:44 -0500
commit16fd18479d2f617adf0e6de922586441be3808eb (patch)
tree6e36bea16f6e61f59f046bcf25eb8f54312c8e30 /hw
parenta13271f2feb6e480b2e698d4efa3b94150a6808b (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> (cherry picked from commit 170c95978530f6373bdf4488116902b273f3abf4)
Diffstat (limited to 'hw')
-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 f2564d5d3..d96e6f2a4 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -639,7 +639,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);