Red Hat Bugzilla – Bug 492610
The evdev driver needs to understand xkb.
Last modified: 2009-07-31 10:44:49 EDT
Created attachment 337044 [details]
This is identical to a patch needed for xkb support in the RHEL4 xorg-x11-drv-evdev
Description of problem:
If you try to configure the Xen virtual mouse/keyboard combination device you discover that you need stanzas like this in the xorg.conf config file:
Option "XkbModel" "evdev"
Option "XkbLayout" "gb"
Option "Device" "/dev/input/event0"
Option "SendCoreEvents" "True"
Option "XkbModel" "evdev"
Option "XkbLayout" "gb"
(See the rhpl bug I'll be entering shortly for how this is done with system-config-display and why it's needed) The problem here is that while the "xeninput" device that uses evdev is only actually needed to get pointer tracking correctly (so that you get absolute coordinates instead of relative ones).
Ideally you'd just have the one InputDevice which is both a pointer and a keyboard, but the X server gets confused and spits out a _lot_ of warning messages (one for every mouse and/or keyboard event) if you try to combine these. Even worse, although the Xkb settings are on a per-device setting you can't actually have different xkb settings for different devices if you want things to work.
If the Xen virtual keyboard and mouse are separate devices (see 492606)
Version-Release number of selected component (if applicable): 6.8.2-1.EL.52 (RHEL4.7), 6.8.2-1.EL.62 (RHEL4.8) -- in both cases the evdev in question is the same as the xorg-x11-drv-evdev in RHEL5.3.
How reproducible: Always
Steps to Reproduce:
1. Attempt to configure the Xen virtual keyboard/mouse combination device as above
You can't do it. Or if you can xkb doesn't work. Or the mouse doesn't work. Or the keyboard doesn't work. Or both. Or you get a _lot_ of warning messages from the X server.
It should work.
Additional info: See bug 492606 for a kernel patch to separate the virtual keyboard and pointer devices that makes this whole thing a lot easier.
I've added three patches: one which can also be applied to the RHEL5 xorg-x11-drv-evdev to provide the same xkb support; one that fixes this up for xorg-x11-6.8.2 and one that adds in the missing keycodes and rules. (xorg.xml needs some translations added, I haven't done that I'm afraid.
Created attachment 337045 [details]
This patch makes some small necessary changes from the RHEL5 patch to support RHEL4
Created attachment 337046 [details]
Add the necessary model and rules definitions for the evdev xkb keyboard
Although the changes in bug 492606 render the immediate need for xkb support redundant, it is still useful to include this. Some input devices work well with evdev and for those, this is a valuable addition.
See bug 492621 for details of how the configuration is automated so that just running "system-config-display" deals with the awkward configuration problems and how those same problems are fixed so that you can just install a patched DVD image and not have to worry about anything.
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.