Here's my original thread forwarded from the xen-users mailing list, but I
think I've traced the problem to Qemu. 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
PS: I'm not subscribed to qemu-devel so please reply to sender also. Thank
you!
----- Forwarded message from sm8...@vfemail.net -----
Date: Thu, 28 Apr 2016 09:33:00 -0500
From: sm8...@vfemail.net
Subject: Re: [Xen-users] xen_kbdfront: unhandled keycode 0x0
To: xen-us...@lists.xen.org
For what it's worth, I found the offending code at
drivers/input/misc/xen-kbdfront.c:87. It looks like test_bit() is being
called with a 'keycode' of 0 as the bit number to be queried against
'keybit', and returns 0 presumably because 0x0 is not a valid keycode (and
why would multiple keys have the same keycode in the first place?).
According to struct xenkbd_key, the keycode is a KEY_* from
include/linux/input.h, so this sounds like it's being used as the bit
number that we're testing for. The bit mask being tested is "struct
input_dev.keybit", which is documented as "@keybit: bitmap of keys/buttons
this device has". test_bit() is called twice, on info->kbd.keybit and
info->ptr.keybit, both struct input_dev, and so far I don't understand the
difference. But it fails both tests (read: neither kbd nor ptr "has" the
key that was supposedly pressed), and we are left with no device and thus
no handler.
But if 0x0 is an invalid keycode, then it sounds like the problem is
somewhere further up the chain. I assume that scancodes are translated into
keycodes by qemu (since qemu takes a keymap) and thus is not xen-kbdfront's
bug. But I'll need some guidance on looking into qemu to find out where it
interacts with xen-kbdfront and attempting to find a problem with the
translation of scancodes to keycodes (why qemu is passing an invalid
keycode).
As far as I can tell, I seem to be the first person to run into this
problem, so it could be user error, but any assistance in further debugging
this problem is appreciated.
Quoting sm8...@vfemail.net:
Hi,
I'm using Xen 4.6.1 with the xenfbfront and xenkbdfront PV drivers and
the bundled qemu-xen with the GTK+ interface, and certain keypresses
cause the following message to appear on the kernel console:
xen_kbdfront: unhandled keycode 0x0
and the key does not do what it is supposed to. So far it appears that
all of the printable keys, control, alt, and shift, and even sequences
like ^C work, but Home, End, PgUp, PgDn, Pause/Break, etc cause the
error above to be printed.
I tried adding
vfb = ["vnc=1,keymap=en-us"]
and I see the "-k en-us" argument being added to qemu, but the problem
persists. (Note: I'm using GTK+, not VNC, but I believe I have to set
"vfb=" to something in order for Xen to setup xenfbfront.)
As an aside, press-and-hold doesn't work either (keys are pressed but
not repeated in the framebuffer console).
Advice on how to fix this is appreciated.
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of
the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No
bandwidth quotas!
Commercial and Bulk Mail
Options!_______________________________________________
Xen-users mailing list
xen-us...@lists.xen.orghttp://lists.xen.org/xen-users
-------------------------------------------------
ONLY AT VFEMAIL! - Use our METADATA MITIGATOR™ to keep your email out of
the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
No Bandwidth Quotas! 15GB disk space!
Commercial and Bulk Mail Options!
----- End forwarded message -----
-------------------------------------------------
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
