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
Version-Release number of selected component (if applicable):
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 ?
I'm still seeing this problem with the latest stuff (on i686, at least; I
haven't test x86_64). My dom0 has:
I just did a fresh install of a domU from a nightly RHEL-5 tree, with kernel-xen
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"
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.
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.
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.
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.
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.
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
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.