Created attachment 337795 [details] A patch to add xkb support xorg-x11-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: Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "evdev" Option "XkbLayout" "gb" EndSection Section "InputDevice" Identifier "xeninput" Driver "evdev" Option "Device" "/dev/input/event0" Option "SendCoreEvents" "True" Option "XkbModel" "evdev" Option "XkbLayout" "gb" EndSection (This can be automated: with patches to rhpl and rhpxl one can use system-config-display the user does not need to be concerned with actually getting this lot right.) 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. Version-Release number of selected component (if applicable): xorg-x11-drv-evdev-1.0.0.5-3.el5 How reproducible: Always Steps to Reproduce: 1. Attempt to configure the Xen virtual keyboard/mouse combination device as above 2. 3. Actual results: 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.
Related bugs: bug 493618, bug 493623, bug 493627, bug 493630, bug 493634 and bug 493642
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 solution. 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 already put much less invasive changes into 5.4 to improve pointer tracking (bug 492866). 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 opinion. 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-5 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-5'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 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 pointer.
By the way, RHEL-6 pointer tracking will be fine out of the box using absolute coordinates, just like upstream.