Bug 216926 - Keyboard repeat does not work correctly with vnc paravirt frame buffer
Summary: Keyboard repeat does not work correctly with vnc paravirt frame buffer
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager
Version: 5.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Daniel Berrangé
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-22 19:01 UTC by Chris Lalancette
Modified: 2008-05-21 17:27 UTC (History)
1 user (show)

Fixed In Version: RHBA-2008-0480
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-21 17:27:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Patch to repeat keystrokes (1.32 KB, patch)
2007-09-18 14:48 UTC, Chris Lalancette
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0480 0 normal SHIPPED_LIVE virt-manager bug fix and enhancement update 2008-05-20 13:36:50 UTC

Description Chris Lalancette 2006-11-22 19:01:33 UTC
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

Comment 1 Daniel Berrangé 2007-01-04 21:54:10 UTC
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 ?


Comment 2 Chris Lalancette 2007-01-04 22:58:09 UTC
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

Comment 3 Chris Lalancette 2007-08-27 17:27:50 UTC
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

Comment 4 Chris Lalancette 2007-08-28 13:28:22 UTC
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

Comment 5 Chris Lalancette 2007-09-18 14:48:39 UTC
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

Comment 6 Markus Armbruster 2007-10-09 16:25:45 UTC
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.


Comment 8 Chris Lalancette 2007-10-09 18:03:11 UTC
(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

Comment 9 RHEL Program Management 2007-10-16 04:08:14 UTC
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.

Comment 10 Brian Stein 2007-10-16 15:15:35 UTC
Dan - Are you in agreement with Comment #8?

Comment 11 Daniel Berrangé 2007-10-16 15:21:40 UTC
Yes, we need to hack around GTK stupidity in virt-manager.

Comment 13 Daniel Berrangé 2008-01-17 20:30:46 UTC
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.


Comment 16 errata-xmlrpc 2008-05-21 17:27:56 UTC
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



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