From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Haxby Subject: Re: pvfb: Absolute vs relative mouse tracking mystery Date: Fri, 23 Jul 2010 12:33:21 +0100 Message-ID: <4C497E01.5010003@oracle.com> References: <4BE49501.6000408@goop.org> <4BE86945.9050408@goop.org> <20100619154145.GM17817@reaktio.net> <4C1CE6DE.8000602@goop.org> <20100619162213.GO17817@reaktio.net> <4C1D00FA.2060907@goop.org> <20100619175040.GQ17817@reaktio.net> <4C479868.1030806@goop.org> <20100722085238.GP17817@reaktio.net> <05C8BE12-9F8C-4B4B-85E3-9563ACD21805@oracle.com> <4C489867.1030301@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C489867.1030301@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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