Re: pvfb: Absolute vs relative mouse tracking mystery

[John Haxby <john.haxby@oracle.com>]

  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.

jch