Re: [Xen-devel] [Xen-users] [QEMU #1578192] Re: xen_kbdfront: unhandled keycode 0x0

[George Dunlap <george.dunlap@xxxxxxxxxx>]

[BCC'ing xen-users, and cc'ing Anthony]

On Mon, May 9, 2016 at 3:25 PM,  <sm8ax1@xxxxxxxxxxx> wrote:
> Just in case anyone was following this thread, I traced the bug back to
> Qemu, so it is in fact not a Xen bug. Here's my qemu-devel post:
>
> https://lists.nongnu.org/archive/html/qemu-devel/2016-05/msg00119.html
>
> and here's my formal bug report and patch
>
> https://bugs.launchpad.net/qemu/+bug/1578192
>
> I haven't received so much as an acknowledgement from qemu-devel or the bug
> tracker, so I expect this issue to remain open for quite a while. If you run
> into this bug, apply gtk.c.patch for a good-enough fix, and notify the Qemu
> developers that you reproduced it. Since it's not a Xen bug, I'm only
> following up here for completeness.

Anthony / Stefano,

Do you know who the right person in the qemu community might be to
chase with this question?

Thanks,
 -George

>
> ----- Forwarded message from sm8ax1@xxxxxxxxxxx -----
>    Date: Mon, 02 May 2016 11:27:22 -0500
>    From: sm8ax1@xxxxxxxxxxx
> Subject: GTK+ interface doesn't translate keycodes properly with Wayland
> backend (Fwd: [Xen-users] xen_kbdfront: unhandled keycode 0x0)
>      To: qemu-devel@xxxxxxxxxx
>
> 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!
>
> Quoting sm8ax1@xxxxxxxxxxx:
>
> 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!
>
>
>
>
>
>
> -------------------------------------------------
> 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!
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> http://lists.xen.org/xen-users

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel