GTK+ interface doesn't translate keycodes properly with Wayland backend
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
I already posted this on the mailing list (https:/
... I'm no expert, but it looks like GTK+ key events come in at the ui/gtk.
static int gd_map_
{
int qemu_keycode;
#ifdef GDK_WINDOWING_WIN32
if (GDK_IS_
switch (qemu_keycode) {
case 103: /* alt gr */
break;
}
return qemu_keycode;
}
#endif
if (gdk_keycode < 9) {
} else if (gdk_keycode < 97) {
#ifdef GDK_WINDOWING_X11
} else if (GDK_IS_
if (s->has_evdev) {
} else {
}
#endif
} else if (gdk_keycode == 208) { /* Hiragana_Katakana */
} else if (gdk_keycode == 211) { /* backslash */
} else {
}
return qemu_keycode;
}
In my case, I'm using GTK+'s Wayland backend, so keycodes 97 through 157 (this includes KEY_HOME(102), KEY_PAGEUP(104), KEY_PAGEDOWN(109), KEY_END(107), etc.) are never translated into a qemu_keycode, and the final 'else' block is hit, causing gd_map_keycode to return 0, which is an invalid keycode and thus cannot be handled by xen-kbdfront. At least that's my best guess as to what is happening.
The solution that comes to mind is provide an alternative to translate_
I may try to do some testing with translate_
Qemu 2.2.1 from Xen 4.6.1 (relevant code appears unchanged in Qemu master)
GTK+ 3.18.7
Wayland 1.9.0
Weston 1.9.0
libinput 1.2.3
Changed in qemu: | |
status: | Fix Committed → Fix Released |
So here's my admittedly quick and dirty solution. This patch adds support for evdev keycodes using translate_ evdev_keycode when GDK_WINDOWING_ WAYLAND is defined.
Affected functions: c:gd_set_ keycode_ type c:gd_map_ keycode
ui/gtk.
ui/gtk.
The caveat with this patch is that I don't see any good way to query Wayland/libinput to find out if evdev is actually the backend. As of now, evdev is the only backend supported, but others could be added in the future. Since XFree86 is the only other keycode type Qemu supports (and it is not supported by Wayland), I don't see any reason to check for evdev on Wayland at this time.
One possibility might be libinput_ device_ get_udev_ device and udev_device_ get_subsystem, but even then, GTK+ doesn't (yet) provide any (documented) way to go from a GdkDevice to a struct libinput_device like it does with gdk_x11_ display_ get_xdisplay and XkbGetKeyboard. See https:/ /developer. gnome.org/ gdk3/unstable/ gdk3-Wayland- Interaction. html. We would also have to modify the configure script to link against libinput in that case.