Red Hat Bugzilla – Bug 492606
The Xen virtual keyboard/mouse combination device confuses the X server
Last modified: 2009-07-31 10:44:45 EDT
Description of problem:
While its possible to configure the X server to use the Xen virtual keyboard and mouse combination device (see other bugs referenced in the next comment) it is fraught with problems because the X server only half-believes that you can have a device that is both a keyboard and a mouse. In particular you must have exactly one CorePointer and one CoreKeyboard and, although this is not stated explicitly, they cannot be the same device. It gets worse, though, because the Xen virtual keyboard (which is also a pointer) must have exactly the same Xkb configuration as the normal keyboard because which Xkb settings are on a per-device basis, this isn't reflected through utilities like setxkbmap. There's more detail in the bugs I'm about to enter and refer to later.
Later kernels, for example, Fedora 9's kernel, split the virtual keyboard and pointer into two separate devices. This makes configuration much easier and doesn't run into logical problems with the X server configuration.
Having said that, this is a "nice to have" because we can configure the Xen pointer and keyboard combo device in a way that is transparent to most users.
Version-Release number of selected component (if applicable):kernel-xenU-2.6.9-82 (and other, earlier kernels).
Steps to Reproduce:
1. Attempt to configure the Xen virtual pointer so that you get proper mouse tracking in a Xen guest VNC console.
Without fixing xorg-x11 and rhpl to understand more of this combo device you can't do this. Well, you can, so long as you don't mind losing either the keyboard or the mouse or sometimes both.
With the relatively new evdev driver in the xorg-x11 server this should be a piece of cake, but it's not because the evdev driver wants to be both a keyboard and a mouse and this confuses X.
I've attached a patch which does the trick. But see also the rhpl and xorg-x11 patches.
See bug 492610 for the xorg-x11 changes needed to add xkb support to the evdev driver. The changes in 492610 are useful for people who don't yet want to update their kernel and can be applied to older RHEL4 versions.
See bug 492621 for details of integrating this change (and coping when its not there) into rhpl and thence system-config-display and the installation image.
Created attachment 337794 [details]
Patch to split the combo xen virtual keyboard/pointer device into two virtual devices
Sorry, forgot to actually attach the patch before.
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
By the way, RHEL-6 pointer tracking will be fine out of the box using absolute coordinates, just like upstream.