Red Hat Bugzilla – Full Text Bug Listing
|Summary:||qemu-kvm not working with evdev giving wrong key mappings|
|Product:||[Fedora] Fedora||Reporter:||Zdenek Kabelac <zkabelac>|
|Component:||qemu||Assignee:||Glauber Costa <gcosta>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||berrange, clalance, dwmw2, gcosta, james, jfrieben, knoel, markmc, mclasen, mhlavink, mishu, nerijus, petersen, quintela, ryanryan52, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-03-11 09:06:38 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Zdenek Kabelac 2009-01-06 05:38:07 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 How reproducible: always 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 3. Actual results: Expected results: Additional info:
Comment 1 Daniel Berrange 2009-01-06 06:04:13 EST
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.
Comment 2 Ryan Niebur 2009-01-12 11:20:13 EST
Created attachment 328752 [details] Ubuntu's patch to fix this
Comment 3 Daniel Berrange 2009-01-12 11:24:22 EST
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.
Comment 4 Ryan Niebur 2009-01-12 20:17:25 EST
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.
Comment 5 Ryan Niebur 2009-01-13 02:01:37 EST
Created attachment 328839 [details] revised patch to only check for evdev once tested, fixes my problem with evdev, doesn't break using normal driver.
Comment 6 Glauber Costa 2009-01-22 11:06:37 EST
Is this patch submitted to upstream qemu ?
Comment 7 Mark McLoughlin 2009-01-22 11:07:28 EST
Ryan: thanks for the patch! you'd probably get a much quicker response if you post it to upstream firstname.lastname@example.org
Comment 8 Avi Kivity 2009-01-22 11:29:57 EST
Shouldn't we populate the codes using whatever method xmodmap -pke uses? That will insulate us against further changes in this area.
Comment 9 Ryan Niebur 2009-01-26 14:50:09 EST
yes, I'll try to make a better patch that doesn't hard code the X driver's keycodes.
Comment 10 Jens Petersen 2009-02-13 00:12:05 EST
*** Bug 463765 has been marked as a duplicate of this bug. ***
Comment 12 Joachim Frieben 2009-02-13 07:39:49 EST
.. 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.
Comment 13 Daniel Berrange 2009-02-13 08:12:48 EST
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.
Comment 14 Joachim Frieben 2009-02-13 08:58:55 EST
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.
Comment 15 Mark McLoughlin 2009-02-13 09:23:30 EST
(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.
Comment 16 Daniel Berrange 2009-03-11 08:39:25 EDT
Reassigning: The kvm package no longer exists in rawhide/F11, since it is now part of 'qemu'.
Comment 17 Daniel Berrange 2009-03-11 09:06:38 EDT
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.