| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
jch
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home