Bug 471000
| Summary: | QEMU processes input from arrow keys incorrectly | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Joachim Frieben <jfrieben> | ||||||
| Component: | qemu | Assignee: | Glauber Costa <gcosta> | ||||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 10 | CC: | berrange, dwmw2, fatkasuvayu, gcosta, james, jnovy, jp, jrincayc, kai, knoel, ma, markmc, mcepl, mhlavink, nerijus, peter.hutterer, petersen, ralphs, samuel-rhbugs, sara.c, virt-maint, wtogami, xgl-maint | ||||||
| Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 74-11.fc10 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2009-12-01 13:43:08 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping this is an issue with "evdev" and is not only related to qemu but also to vmware-console, dosbox (see Bug #473875) or properitary NoMachine Software (nxclient). Local desktop applications will work fine, but remote desktop apps (like a gnome-session over nxclient) or virtualized apps (gnome-session in VM or VM's bios over vmware-console) have this issue that arrow-keys generate wrong events. For example in a remote or virtualized gnome-session, arrow-up will show the "take screenshot" popup. when i remove "evdev" and use old "kbd" input driver, everthing works fine. BTW, Ubuntu 8.10 (which uses "evdev") has the same problem: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/199923/comments/9 (In reply to comment #2) > this is an issue with "evdev" Using driver "kbd" actually allows to work around this issue even though this does not mean for sure that the true culprit is the "evedev" driver albeit this appears to the most likely cause. Switching component to xorg-x11-drv-evdev. please run xev in both the host and the client and hit the up key. What keycode do you see? Created attachment 326280 [details]
Output of 'xev' in F7 live session run my QEMU
:::: Host side ::::
xorg-x11-drv-keyboard-1.3.0-3.fc9.x86_64:
KeyRelease event, serial 30, synthetic NO, window 0x4400001,
root 0x85, subw 0x0, time 9403019, (129,108), root:(134,157),
state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
xorg-x11-drv-evdev-2.1.0-1.fc11.x86_64:
KeyRelease event, serial 30, synthetic NO, window 0x2000001,
root 0x85, subw 0x0, time 203431, (594,577), root:(637,682),
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
:::: Guest side ::::
Upon pressing the <arrow up> key in an F7 live session run by QEMU, 'xev' returns a KeymapNotify event in contrast with the KeyRelease event returned in a normal GNOME session on the host system. The keycode appears to be 68. It triggers the GNOME screenshot utility inside the F7 live session.
Now that you mention F7, it's a bit more obvious to me: keycodes in X have no meaning other than they can be assigned to keysyms. in evdev driver, keycode 111 is the up key, whereas the same keycode is print screen in the old keyboard driver (this is because the kernel abstracts the hw keycodes for evdev as defined in <linux/input.h>) so what I assume happens is that qemu forwards the keycode as-is, but F7 has a different keycode-keysym mapping than the host. The only way to fix this is to either force the host and the client to have the same mapping (i.e. the host uses kbd instead of evdev, or the client uses evdev instead of kbd) or to have qemu perform on-the-fly mapping from evdev codes to hw scancodes. If you have a running OS inside qemu (or vmware) this can easily fixed in GNOME Session keyboard properties by selecting "Evdev-managed Keyboard" as keyboard model in both, Host and Guest. But if you don't have a running OS, e.g. when selecting boot order via arrow-up/down in vmware's VM-Bios, this still does not work. For vmware, there is a workaround: http://kb.vmware.com/kb/1007439 Don't know, if other virtualization/emulation products are also affected. Just being curious, why have evdev and old kbd different keycodes? (In reply to comment #7) > so what I assume happens is that qemu forwards the keycode as-is, but F7 has a > different keycode-keysym mapping than the host. Yet the issue persists for an F10 (Beta) live session guest already at the boot loader level. Likewise for guests such as Open Solaris 2008.11, ReactOS 0.3.7, or a current snaphot of Ubuntu 9.04 "Jaunty Jackalope". According to comment #6, keysym codes are identical whereas keycodes differ, so using the former, there would be no problem at all. Umm, it is broken for me with text VT with no X involved at all. Older versions of kvm do not have this issue. Are you sure this is not kvm's fault? (In reply to comment #10) > Are you sure this is not kvm's fault? Yes, because I am not using KVM at all. (In reply to comment #8) > Just being curious, why have evdev and old kbd different keycodes? kbd uses the hardware scancodes and thus has a lot of hw-specific code in the driver. evdev leaves all these quirks up to the kernel which exports a unified range of keycodes for all keyboards (see linux/input.h). Some keycodes happen to overlap to you don't notice it until you hit a key that has two different ones. (In reply to comment #9) > Yet the issue persists for an F10 (Beta) live session guest already at the boot > loader level. Likewise for guests such as Open Solaris 2008.11, ReactOS 0.3.7, > or a current snaphot of Ubuntu 9.04 "Jaunty Jackalope". AIUI, the qemu window gets the keycodes through xlib - and thus the evdev scancode. This code is forwarded unmodified through whatever looks like the kbd hw device in qemu. the driver at the other end thinks it's a keyboard and interprets the scancode wrong. If this is correct (and I'm not sure it is) then qemu needs a mapping table that maps the keysyms back to the keyboard scancodes. (In reply to comment #12) > If this is correct (and I'm not sure it is) then qemu needs a mapping table > that maps the keysyms back to the keyboard scancodes. Again: according to comment #6, the **keysym** reported by by drivers "kbd" and "evdev" is identical namely (0xff52, Up) for the <arrow up> key. However, even grub or the Ubuntu boot loader menu (Ubuntu 9.04) behave differently in both cases respectively. How does qemu forward key events to the client? Maybe it is useful to know that with OpenSuSE 11.1 it works fine for me. I do not know if they use evdev, though, but maybe they use some patch. Not useful, unless you tell us for sure if they use evdev. Please grep /var/log/Xorg.0.log for kbd and evdev and you'll see which one is used. I found out that they still use kbd... For what it's worth, if you use qemu -vnc 0:0 ... the arrow keys will work, but not if you use the straight x version. Using the VNC console limits the display resolution. Rock, meet hard place. Isn't this a duplicate of bug 478976? This is *NOT* a bug in the Xorg driver. The problem is that QEMU has hardcoded assumptions about the scancode <-> keycode mappings which simply don't hold true for evdev. There are patches available to fix this QEMU brokeness in bug 478976. I recommend this one be closed NOTABUG As far as I remember I haven't claimed it to be an evdev driver bug. It was originally reported against QEMU. Reverting to component QEMU. Okay, AFAICT this is fixed in rawhide - marking as a dup of bug #478976. Please re-open if I'm confused *** This bug has been marked as a duplicate of bug 478976 *** (In reply to comment #23) > *** This bug has been marked as a duplicate of 478976 *** This bug has been reported against F10, bug 478976 against "rawhide". At present, the former features qemu-0.9.1-12.fc10 which is affected by this issue. Fixing the "rawhide" package is nice, but it does not help much when running F10. I don't think there are any plans to re-base qemu in F10, so people may well have to wait until F11 If someone would like to investigate back-porting the fixes, that would be fine ... otherwise we should just close this. FYI, backporting the changes should be really pretty simple - it was a fairly well contained to support evdev. kvm-74-11.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/kvm-74-11.fc10 glommer just built a kvm-74 update for F10 with the fix: http://cvs.fedoraproject.org/viewvc/rpms/kvm/F-10/kvm-evdev.patch?view=markup * Mon Mar 30 2009 Glauber Costa <glommer> - 74-11 - Fixed #471000 (Processing arrow keys incorrectly), with kvm-evdev.patch Note, though, the bug is still present in F-10's 0.9.1 vintage qemu. kvm-74-11.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update kvm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-3139 This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. (In reply to comment #25) > I don't think there are any plans to re-base qemu in F10, so people may well > have to wait until F11 I ran into the same problem, using current F10 qemu-0.9.1-12.fc10.i386, and was able to work-around the cursor key issue by simply specifying a keymap when starting qemu, for example: qemu -k en-us filename.iso YMMV. kvm-74-11.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. This bug has been reported against qemu not kvm, and the issue does persist for the former. This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I've upgraded to F12 and no longer see this issue. Thank you for letting us know. |
Created attachment 323166 [details] Custom xorg.xonf Description of problem: After booting into a recent "rawhide" boot.iso or the ReactOS 0.3.7 live CD, input from arrow keys is wrong, whereas other keys including TAB etc. do actually work. Version-Release number of selected component (if applicable): qemu-0.9.1-10.fc10.x86_64 How reproducible: Aways. Steps to Reproduce: 1. Boot "rawhide" boot.iso in QEMU. 2. Try using arrow keys to choose install parameters. Actual results: No or wrong input. Expected results: Input from arrow keys is processed correctly. Additional info: - ReactOS: "arrow up" key leads to the output of "*". - Compaq Spacesaver model P/N 166516-046 with 105 keys and German layout.