Bug 478976 - qemu-kvm not working with evdev giving wrong key mappings
Summary: qemu-kvm not working with evdev giving wrong key mappings
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Glauber Costa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 463765 (view as bug list)
Depends On:
Blocks: F11VirtTarget
TreeView+ depends on / blocked
 
Reported: 2009-01-06 10:38 UTC by Zdenek Kabelac
Modified: 2013-01-09 11:26 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-11 13:06:38 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Ubuntu's patch to fix this (7.59 KB, patch)
2009-01-12 16:20 UTC, Ryan Niebur
no flags Details | Diff
revised patch to only check for evdev once (8.84 KB, patch)
2009-01-13 07:01 UTC, Ryan Niebur
no flags Details | Diff

Description Zdenek Kabelac 2009-01-06 10:38:07 UTC
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 Berrangé 2009-01-06 11:04:13 UTC
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 16:20:13 UTC
Created attachment 328752 [details]
Ubuntu's patch to fix this

Comment 3 Daniel Berrangé 2009-01-12 16:24:22 UTC
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-13 01:17:25 UTC
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 07:01:37 UTC
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 16:06:37 UTC
Is this patch submitted to upstream qemu ?

Comment 7 Mark McLoughlin 2009-01-22 16:07:28 UTC
Ryan: thanks for the patch!

you'd probably get a much quicker response if you post it to upstream qemu-devel

Comment 8 Avi Kivity 2009-01-22 16:29:57 UTC
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 19:50:09 UTC
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 05:12:05 UTC
*** Bug 463765 has been marked as a duplicate of this bug. ***

Comment 11 Joachim Frieben 2009-02-13 12:36:31 UTC
Bug 478976 is a duplicate of bug 471000.

Comment 12 Joachim Frieben 2009-02-13 12:39:49 UTC
.. 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 Berrangé 2009-02-13 13:12:48 UTC
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 13:58:55 UTC
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 14:23:30 UTC
(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 Berrangé 2009-03-11 12:39:25 UTC
Reassigning: The kvm package no longer exists in rawhide/F11, since it is now part of 'qemu'.

Comment 17 Daniel Berrangé 2009-03-11 13:06:38 UTC
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.

Comment 18 Mark McLoughlin 2009-03-25 11:09:00 UTC
*** Bug 471000 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.