1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
virtual: 0.954
semantic: 0.950
x86: 0.940
hypervisor: 0.936
graphic: 0.930
assembly: 0.930
debug: 0.929
vnc: 0.927
performance: 0.923
mistranslation: 0.923
arm: 0.922
architecture: 0.916
user-level: 0.915
ppc: 0.913
permissions: 0.908
KVM: 0.908
PID: 0.904
TCG: 0.898
device: 0.893
register: 0.886
risc-v: 0.884
kernel: 0.882
boot: 0.882
peripherals: 0.876
network: 0.857
VMM: 0.854
socket: 0.847
files: 0.826
i386: 0.727
GTK+ interface doesn't translate keycodes properly with Wayland backend
I already posted this on the mailing list (https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00119.html) but I decided to do a formal bug report so it can be tracked and doesn't get lost.
... I'm no expert, but it looks like GTK+ key events come in at the ui/gtk.c:gd_key_event callback function, which calls ui/gtk.c:gd_map_keycode to translate the GTK+ keycode into the Qemu keycode before sending it on using qemu_input_event_send_key_number. The problem is that gd_map_keycode is incomplete when GTK+ is running on a backend other than X11.
static int gd_map_keycode(GtkDisplayState *s, GdkDisplay *dpy, int gdk_keycode)
{
int qemu_keycode;
#ifdef GDK_WINDOWING_WIN32
if (GDK_IS_WIN32_DISPLAY(dpy)) {
qemu_keycode = MapVirtualKey(gdk_keycode, MAPVK_VK_TO_VSC);
switch (qemu_keycode) {
case 103: /* alt gr */
qemu_keycode = 56 | SCANCODE_GREY;
break;
}
return qemu_keycode;
}
#endif
if (gdk_keycode < 9) {
qemu_keycode = 0;
} else if (gdk_keycode < 97) {
qemu_keycode = gdk_keycode - 8;
#ifdef GDK_WINDOWING_X11
} else if (GDK_IS_X11_DISPLAY(dpy) && gdk_keycode < 158) {
if (s->has_evdev) {
qemu_keycode = translate_evdev_keycode(gdk_keycode - 97);
} else {
qemu_keycode = translate_xfree86_keycode(gdk_keycode - 97);
}
#endif
} else if (gdk_keycode == 208) { /* Hiragana_Katakana */
qemu_keycode = 0x70;
} else if (gdk_keycode == 211) { /* backslash */
qemu_keycode = 0x73;
} else {
qemu_keycode = 0;
}
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_{evdev,xfree86}_keycode that is compatable with Wayland/libinput, but I don't know exactly which API would provide this functionality, much less do I have a patch. Intuition tells me that translate_evdev_keycode would probably work under Wayland because Weston uses libinput which uses evdev as its backend, but I don't know this for a fact, and I don't know if it would be the Right Way (i.e. Wayland or libinput might provide an API for this purpose, but I don't know).
I may try to do some testing with translate_evdev_keycode on Wayland and also look into any possible APIs for keycode translation, but I just wanted to put it out there and get some feedback awhile.
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
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:
ui/gtk.c:gd_set_keycode_type
ui/gtk.c:gd_map_keycode
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.
thanks wyzu for the patch, I can confirm it also affecting my system.
qemu 2.8.0
gnome-shell 3.22.2
gtk3 3.22
wayland 1.12
libinput 1.5.3
I attached an updated patch based on wyzu's one that seems to work for me.
This issue was fixed already in git master with:
commit a8ffb372a2202c65f42fdb69891ea68a2f274b55
Author: Daniel P. Berrange <email address hidden>
Date: Thu Dec 1 09:41:17 2016 +0000
ui: use evdev keymap when running under wayland
Wayland always uses evdev as its input source, so QEMU
can use the existing evdev keymap data
Signed-off-by: Daniel P. Berrange <email address hidden>
Tested-by: Stefan Hajnoczi <email address hidden>
Message-id: <email address hidden>
Signed-off-by: Gerd Hoffmann <email address hidden>
|