Bug 492621 - Provide support for configuring a working mouse pointer for the Xen VNC console.
Provide support for configuring a working mouse pointer for the Xen VNC console.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rhpl (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
Depends On:
  Show dependency treegraph
Reported: 2009-03-27 14:41 EDT by john.haxby@oracle.com
Modified: 2009-07-31 10:44 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-31 10:34:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A patch to modify rhpl so that system-config-display and the installation correctly find and use the Xen virtual pointer. (4.88 KB, patch)
2009-03-27 14:41 EDT, john.haxby@oracle.com
no flags Details | Diff
Patch to correctly configure the keyboard during installation. (1.24 KB, patch)
2009-04-01 05:56 EDT, john.haxby@oracle.com
no flags Details | Diff

  None (edit)
Description john.haxby@oracle.com 2009-03-27 14:41:03 EDT
Created attachment 337052 [details]
A patch to modify rhpl so that system-config-display and the installation correctly find and use the Xen virtual pointer.

Description of problem:

There is a long-standing problem of mouse pointer tracking with the Xen VNC console.  This typically shows up as the local VNC cursor (for the local application) and the remote cursor being out of sync -- in some cases the local and remote cursors are identical and this makes driving the Xen VNC console very difficult.

The problem can be partially solved by using a custom VNC client: the gtk vncviewer widget does just that and by completely hiding the local cursor masks the problem quite effectively.  However, there are still problems because the remote cursor does not move at the speed the user is expecting (mostly it's too slow, but when it's too fast it's unusable) and, without some careful trickery, the remote cursor can be seen to bump into a "wall" when the local cursor hits the edge of the screen.  Of course, this solution does not work at all unless you're using that particular VNC client -- which you can't on Windows.

Fortunately, there is a way out of this.  The Xen virtual pointer device allows you to use absolute addressing (like a tablet) and if you do this then you don't have mismatched cursors, speed or invisible wall problems.   It works so well that within a couple of seconds you're left wondering how you ever managed before.

There are a couple of problems to get around.  First, because of the combination pointer/keyboard virtual device (see bug 492606) the configuration is, to say the least, complex and difficult.  Second, again because of the combo pointer/keyboard device you need to add xkb support to the evdev driver (bug 492610).

The configuration complexities are taken care of by rhpl.  With these changes in place you need only run "system-config-display --reconfig" and you'll get a working X server configuration.  (Buried in there, though, is a patch for a different, minor bug: previously the existing keyboard settings were discarded when you ran s-c-d --config, now the settings are read in if necessary.)

If rhpl and xorg-x11 are retrofitted into a distribution DVD then you also get a properly tracking mouse during installation.  Several of the people I've spoken to are driven potty by the poor mouse tracking during installation and are glad to be able to forget the graphical environment once they've done -- yes I know that you and I would get around this with using "vnc" on the installation boot command, but not enough people know that.  With this fix, it just, finally, and blissfully works.

Version-Release number of selected component (if applicable): rhpl-0.148.6

How reproducible: Absolutely every time.

Steps to Reproduce:
1. Install RHEL4 in a Xen PV machine
Actual results:  Mouse tracking is difficult, if not downright unusable

Expected results:  Mouse tracking should just work.

Additional info:  See also bug 492606 and bug 492610.  There'll also be similar bugs for RHEL5 before long.

The attached patch works both for kernels that have a combination pointer/keyboard virtual device and for kernels patched according to 492606.

Go on, apply the patch in 492610 to xorg-x11 and this one to rhpl and run system-config-display --recconfig in your Xen PV guest and be delighted!
Comment 1 john.haxby@oracle.com 2009-04-01 05:56:35 EDT
Created attachment 337476 [details]
Patch to correctly configure the keyboard during installation.

During installation, the rhpl.keyboard.Keyboard activate() method is used to activate the keyboard configuration.  When using the Xen Virtual Keyboard/Mouse combo device we need to ensure that we have the evdev keyboard model to match what the X configuration is using (see other patch).

This patch forces the keyboard model to be "evdev" when needed.

In addition, we need to set the "lv3:switch" xkb option for reasons that aren't entirely clear to me.  There's a bug somewhere that means that the AltGr key (which is normally ISO_Level3_Shift) should, by default, switch to the alternate characters and this option is implicit.   It does no harm to set this option anyway: if the keyboard layout maps the right Alt key to Alt_R (as it does for US keyboards) then this option has no effect.
Comment 2 Markus Armbruster 2009-07-31 10:34:25 EDT
The bug as reported is about the difficulties to manually configure X
in a certain way, to get proper pointer tracking.  It is certainly
valid.  However, the real problem users care about is that pointer
tracking works very poorly (mouse hits invisible wall).

Upstram, we solved the problem by fixing numerous issues in various
places to make it work out of the box, from Fedora 11 on.

The patches proposed by the reporter solve the problem by making
manual configuration work.  They are unrelated to the upstream

Like the upstream solution, they're fairly invasive: they touch the
kernel and several user space packages.  This is a significant risk.
Moreover, splitting the device is an ABI change.  The question is
whether there are benefits to justify that.

We intend to put much less invasive changes into 4.9 to improve
pointer tracking (bug 492868).  They fix the "mouse hits invisible
wall" problem.  They still require a pointer grab, which virt-viewer
makes relatively painless.

So, the benefit of the proposed patches over what we've got already is
to enable manual configuration so that the mouse grab can be avoided.
While that's certainly nice, it doesn't justify the risk, in my

If you disagree, please reopen the bug.

Some technical background:

There are 3 pieces in the stack: VNC client, QEMU VNC server and the
guest's X.  The old, misbehaving setup has VNC client sending absolute
coordinates, which the VNC server sends through xenkbd to X.  X in
RHEL-4 doesn't have any auto-configuration of input devices, so it
just opens /dev/input/mice, and thus the guest kernel converts from
absolute to relative.  Because the VNC client has no knowledge of this
conversion, you get into situation where you hit an invisible wall in
the client when it thinks it has got to the virtual desktop boundary.

Now, if you had absolute coordinates being passed and used all the way
to X then it would trivially work, but this requires X configuration.
Recent X's do that automatically.  RHEL-4's X simply isn't capable of
that.  The patches proposed by the reporter add manual configuration
steps across a wide range of RPMs.

The fix we did for RHEL-5.4 and plan to backport to 4.9 is to make
xenkbd *not* use absolute coordinates, so the VNC server now sends
relative coordinates.  This removes the broken absolute -> relative
conversion in the guest kernel.  On its own this isn't sufficient,
because you then get broken absolute to relative conversion in the VNC
server instead.  So we also added the VNC relative mouse extension to
QEMU and GTK-VNC.  Now the VNC client is in charge of doing the
absolute -> relative conversion.  This is good, as this is the only
point in the stack capable of doing the conversion correctly, to avoid
hitting an invisible wall.  The only restriction is that you must grab
the host mouse pointer and hide it, so you only see the guest drawn
Comment 3 Markus Armbruster 2009-07-31 10:44:50 EDT
By the way, RHEL-6 pointer tracking will be fine out of the box using absolute coordinates, just like upstream.

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