|
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 sm8ax1@xxxxxxxxxxx:
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-users@xxxxxxxxx.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!
|
