Bug 493630

Created attachment 337803 [details]
Patch to recognise and configure a xen virtual keyboard/pointer when present

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 493618) 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 493623).  There are also problems with correctly activating the keyboard in rhpl (bug on its way) and the evdev xkb rules (bug 493627) but these are relatively minor compared to getting the configuration right.

The configuration complexities are mostly taken care of by rhpxl.  With these changes in place you need only run "system-config-display --reconfig" and you'll get a working X server configuration.

If the fixes the rhpxl, rhpl, xkeyboard-config and xorg-x11-drv-evdev 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): 0.41.1


How reproducible: Always


Steps to Reproduce:
1. Install a Xen PV guest.   Use a "standard" vnc viewer rather than the gtk vncviewer that masks some, but not all of the problems.  You want to experience the full horror of the problem.
2. Attempt to move the cursor in a useful fashion
3.
  
Actual results: Mouse cursor varies between merely annoying and downright impossible


Expected results: The local and remote cursors should track perfectly


Additional info: It's amazing how much easier a Xen PV graphical installation is once you've fixed this, not even the gtk vnc viewer comes close to getting a properly tracking mouse.

Note that you can't use kudzu to discover the xen virtual keyboard/pointer; probably because it's a virtual device, not a real one.