This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] pvfb: Absolute vs relative mouse tracking mystery

 On 22/07/10 20:13, Jeremy Fitzhardinge wrote:
On 07/22/2010 12:04 PM, John Haxby wrote:
CentOS 5.5 (and RHEL5.5) deliberately turns off request-abs-pointer in
favour of relative pointers.

The excuse given is that the RHEL5 X server isn't up to the job of
dealing with absolute pointers.  The claim is that you get better
responsiveness with relative pointers and a gtk-vnc-based viewers.
Er, what?  How do they get it to work properly then?  Is there any way
to make it use abs?

The bug for this is https://bugzilla.redhat.com/show_bug.cgi?id=492866

That doesn't explain much, but the corresponding patch to the RHEL kernel has this to say:

    The Xen para-virtual frame buffer protocol supports absolute and
relative pointer events. The backend sends absolute pointer events only
    if the frontend has agreed to that feature.

For reasons that seemed sensible at the time, the RHEL-5 frontend always
    agrees, even though RHEL-5 user-space is incapable of actually running
the mouse in absolute mode without manual configuration. So, out of the
    box, the guest kernel is doing abs -> rel coordinate conversion.  This
in turn causes problems for anyone connecting to the guest using the VNC
    server in the host, because their mouse pointer is prone to hit an
    "invisible wall".

    The out-of-the-box experience is much better with relative pointer
    events.  It is better still with user-space correctly set up for
    absolute pointer events.

This patch makes the xenkbd driver reject absolute pointers, unless they This patch makes the xenkbd driver reject absolute pointers, unless they
    are enabled with kernel parameter xenkbd.abs_pointer=1.  Improves the
    out-of-the box user experience, and still allows those who care for an
    even better experience to manually set that up.

The "out-of-the-box experience" relies on you using a gtk-vnc-based VNC viewer that grabs the mouse and turns off the visible local mouse pointer so it can work properly. When I tried it it didn't seem that great and, of course, it doesn't work at all when you're using a java-plugin VNC viewer from Windows where you can't turn off the local mouse pointer.

It is possible to fix RHEL5 so that you can configure the Xen mouse properly -- I did it. However, the way I did it involved fixing the X11 evdev driver since evdev interface provides both mouse and keyboard but the evdev driver doesn't do XKB. Configuring all that took some doing, but it can be done automatically and I even retrofitted the changes into anaconda so that it all worked properly at installation time as well.

Is there a better way to talk to the xen mouse? One that means that we can get the absolute events and give them to the X server? A new mouse driver is likely to be less painful than the far-reaching attempt I tried before.


Xen-devel mailing list