Hide Forgot
Description of problem: When connecting to the paravirt frame buffer using virt-manager (click on domain -> Open), holding down a key does not seem to send repeat events to the console. If I attach to the console directly using vncviewer, keyboard repeat seems to work fine. Version-Release number of selected component (if applicable): virt-manager 0.2.6
I cannot reproduce this problem. Using virt-manager-0.2.6-4.el5 the keyboard repeat operates as expected for paravirt guests. Can you verify with latest RHEL-5 tree that keyboard repeat is still broken for you ?
Dan, I'm still seeing this problem with the latest stuff (on i686, at least; I haven't test x86_64). My dom0 has: kernel-xen: 2.6.18-1.2943.el5 libvirt: 0.1.8-11.el5 virt-manager: 0.2.6-6.el5 xen-3.0.3-18.el5 I just did a fresh install of a domU from a nightly RHEL-5 tree, with kernel-xen 2.6.18-1.2961.el5 The configuration file for the domU looks like this: # Automatically generated xen config file name = "rhel5test" memory = "299" disk = [ 'tap:aio:/var/lib/xen/images/rhel5test.dsk,xvda,w', ] vif = [ 'mac=00:16:3e:7a:af:8e, bridge=xenbr0', ] vfb = ["type=vnc,vncunused=1"] uuid = "b2d5a446-b269-476e-91c6-1191649fccfc" bootloader="/usr/bin/pygrub" vcpus=1 on_reboot = 'restart' on_crash = 'restart' To be a little more clear than my initial description, keyboard repeat *does* work fine in X in the domU. It's only when I drop to a virtual console that keyboard repeat isn't working. And just for the record, keyboard repeat also works fine in X and in virtual consoles on the dom0. Chris Lalancette
OK, I think I've narrowed this one down quite a bit, although I am still missing a little bit of information. Here's what happens: When you hold down a key while typing in the VNC viewer in virt-manager, it correctly generates a series of events (verified by placing a print in src/vnc.py:key_press()), which are sent to the VNC server (xen-vncfb). In turn, xen-vncfb is generating a series of events (verified by placing a print in tools/xenfb/vncfb.c:on_kbd_event()). These events are then placed on the ring buffer for the domain, and the event channel for that domain is signalled. In turn, the kernel inside the domain is woken up by the events, and generates a series of repeating events (verified by placing a printk in drivers/input/input.c:input_event()). However, this is where we run into our issue; because "value" (a number passed into input_event) is 1, we hit a test condition where we just return without doing any work. On a properly working system (i.e. bare-metal), when you hold down a key for repeat, value ends up being 1 for a keypress, 0 for a key release, and 2 for a key repeat. I've not yet determined whether this should be determined in the kernel or in xen-vncfb, but I will look at it the next time I have time for this issue. Chris Lalancette
Note that this problem only seems to occur on the text console in the guest (i.e. you are running the guest at runlevel 3); when running X, keyboard repeat seems to work. Chris Lalancette
Created attachment 198421 [details] Patch to repeat keystrokes This is a patch against the RHEL-4 kernel (but the same idea, and maybe even the same patch, apply to RHEL-5 kernel). This patch basically detects whether the last key was the same as this one, and if so, passes a 2 for the value, which causes the key repeat to work properly. I'm not entirely sure this is safe from race conditions, given the static variables, but it is a first cut, and I at least understand the problem completely now. Chris Lalancette
X sends typematic key repeats as down and up events, but GTK swallows the up event. In other words, we get down up down up down up with vncviewer (not using GTK), but down down down up with virt-manager (using GTK). The PVFB backend doesn't care, it just passes events to the frontend. Which doesn't care either, it just passes them to the input layer. Which silently collapses sequences of downs into one. Fixing the bug in the PVFB frontend as comment#5 suggests leaves older guests in the rain. We better fix virt-manager. If we additionally want the frontend to cope with missing ups as in comment#5, this bug needs to be cloned for component kernel-xen.
(In reply to comment #6) > If we additionally want the frontend to cope with missing ups as in comment#5, > this bug needs to be cloned for component kernel-xen. The only impetus to change the kernel is to allow newer versions of the guest kernel to work properly with older versions of virt-manager. Given that I don't think this bug is that important, and the fact that it is much more likely for people to upgrade the tool rather than the guest kernels, I think if we have a fix for virt-manager, we should just go with that. Chris Lalancette
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Dan - Are you in agreement with Comment #8?
Yes, we need to hack around GTK stupidity in virt-manager.
virt-manager-0.5.3-1.el5 in RHEL-5.2 now uses gtk-vnc-0.3.2-1.el5 which contains a fix to address this problem.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0480.html