Red Hat Bugzilla – Bug 478976
qemu-kvm not working with evdev giving wrong key mappings
Last modified: 2013-01-09 06:26:56 EST
Description of problem:
I'm not sure where is the problem exactly, but for now it looks like qemu-kvm is doing something wrong while decoding X key symbols.
When I'm using keyboard kbd driver on a host machine - arrow keys seems to work ok inside SDL window. When I switch to 'evdev' keyboard driver (i.e. hal autodiscovered) some keys are not properly decoded - so keys like arrows do not work.
The problem is only visible inside qemu-kvm - other SDL application seems to work normally - so to me it looks like X keycodes are hard-wired into binary which is not a good way to decode X key symbols.
Here is a short diff of problematic keys (xmodmap -pke)
-keycode 111 = Up NoSymbol Up NoSymbol Up
-keycode 112 = Prior NoSymbol Prior NoSymbol Prior
-keycode 113 = Left NoSymbol Left NoSymbol Left
-keycode 114 = Right NoSymbol Right NoSymbol Right
-keycode 115 = End NoSymbol End NoSymbol End
-keycode 116 = Down NoSymbol Down NoSymbol Down
-keycode 117 = Next NoSymbol Next NoSymbol Next
+keycode 98 = Up NoSymbol Up NoSymbol Up
+keycode 99 = Prior NoSymbol Prior NoSymbol Prior
+keycode 100 = Left NoSymbol Left NoSymbol Left
+keycode 101 =
+keycode 102 = Right NoSymbol Right NoSymbol Right
+keycode 103 = End NoSymbol End NoSymbol End
+keycode 104 = Down NoSymbol Down NoSymbol Down
+keycode 105 = Next NoSymbol Next NoSymbol Next
Difference is nicely visible with xev.
Version-Release number of selected component (if applicable):
The latest x86_64 version of kvm is missing some bios files
so I'm using version: kvm-74-10.fc10.x86_64
Steps to Reproduce:
1. start linux in qemu-kvm with SDL graphics and use evdev as keyboard driver in xorg.conf in a host machine
2. try to use arrows
This is probably caused by the switch from Xorg using 'kbd' to 'evdev' for keyboard input. This broke the 1-to-1 mapping of scancodes to keycodes that QEMU and others relied on. We had todo a patch for GTK-VNC to handle the new evdev mapping, and I believe Ubuntu has a patch todo the same for KVM - there was also one posted to upstream qemu-devel list last week IIRC.
Created attachment 328752 [details]
Ubuntu's patch to fix this
FYI, Ubuntu's patch is not suitable for application to QEMU as is - it is horrifically inefficient, checking for evdev by querying the server keymap on every single key press & release. It needs re-writing to only querying it once.
okay, sorry, I didn't actually look at the patch. I'll come up with a revised one later tonight or sometime later this week.
Created attachment 328839 [details]
revised patch to only check for evdev once
tested, fixes my problem with evdev, doesn't break using normal driver.
Is this patch submitted to upstream qemu ?
Ryan: thanks for the patch!
you'd probably get a much quicker response if you post it to upstream email@example.com
Shouldn't we populate the codes using whatever method xmodmap -pke uses? That will insulate us against further changes in this area.
yes, I'll try to make a better patch that doesn't hard code the X driver's keycodes.
*** Bug 463765 has been marked as a duplicate of this bug. ***
Bug 478976 is a duplicate of bug 471000.
.. and it is not a KVM bug, thus wrong component! Bug 471000 has been reported for a system with plain QEMU and no KVM. Enabling driver xorg-x11-drv-kbd instead of xorg-x11-drv-evdev allows to restore proper handling of keycodes.
Yes, this *IS* a QEMU/KVM bug. It has hardcoded the assumption that there is a 1-to-1 mapping of scancodes to keycodes. This just happens to be true of the 'kbd' X driver, this is not true in general, thus QEMU breaks with evdev. QEMU must be fixed.
This a plain QEMU bug, and thus, the appropriate component is QEMU. The bug appears regardless of whether KVM virtualization is used or not. For this reason, component KVM is misleading.
(In reply to comment #14)
> This a plain QEMU bug, and thus, the appropriate component is QEMU. The bug
> appears regardless of whether KVM virtualization is used or not. For this
> reason, component KVM is misleading.
The problem exists in both the qemu and kvm packages, it's fine to have both bugs open to track them. In F11, we hope to merge the two packages.
However, this bug does have information on the actual problem, proposed patches etc.
Reassigning: The kvm package no longer exists in rawhide/F11, since it is now part of 'qemu'.
The latest qemu package in rawhide (2:0.10-0.7.kvm20090310git) includes patches to detect & correctly handle evdev keyboard mappings with SDL graphics. For VNC issues, evdev handling is the responsiblity of the VNC client.
*** Bug 471000 has been marked as a duplicate of this bug. ***