Red Hat Bugzilla – Bug 493634
Force the model of the evdev hosted Xen Virtual Keyboard/Pointer to be "evdev"
Last modified: 2009-07-31 10:45:02 EDT
Created attachment 337804 [details]
Patch to force the model for evdev-driven keyboards to evdev
Description of problem: In thr activate() method of rhpl.keyboard.Keyboard the setxkbmap invocation needs to use the right keyboard model when we're using the evdev driver. At the moment, the only device that uses this is the Xen Virtual Keyboard/Pointer combo device. The attached patch forces the use of the evdev driver in this case.
Version-Release number of selected component (if applicable):0.194.1
How reproducible: Always in a Xen PV installation with the evdev driver in use.
Steps to Reproduce:
1. Create an installation image with a fixed xorg-x11-evdev-drv (bug 493623), rhpxl (bug 493630) and anaconda (coming real soon now)
2. Start a Xen PV installation
3. Attempt to use, for example, the arrow when appropriate
Actual results: The arrow keys (among others) send the wrong events
Expected results: The arrow keys should send arrow key events
Additional info: The problem is that rhpl does something like "setxkbmap -model pc105 -layout gb" and if you're using the evdev driver that means that scan codes for some keys -- including the arrow keys -- are mapped to the wrong keycodes. If you switch to virtual console 2 (always exciting, but just about possible with the standard vnc viewer) and run "DISPLAY=:1 setxkbmap -model evdev -layout gb" (assuming you have a UK keyboard) and switch back to vt6 then you should find the arrow keys and everything else working as expected.
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
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
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-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.