Description of problem: Mice in virtual machines have two modes of operation, relative motion, or absolute motion. PS2 uses relative motion, while USB tablets do absolute motion. Unfortunately, the VNC protocol uses absolute motion for mice, meaning that QEMU has to convert back to relative motion for the guest. This causes a 'dual pointer' where the guest mouse diverges from the local client mouse. We've tried various hacks to address this in the VNC client, but cannot do so correctly with the way VNC works. To address this we need to implement the VNC relative mouse extension in Xen's QEMU VNC server. This code is already used in latest upstream Xen and QEMU codebases. In conjunction with a patch to GTK-VNC, this will let us get perfect mouse pointer in our guests without the 'invisible wall' problems exhibited by bug 223805 This requires backporting http://git.kernel.org/?p=virt/qemu/qemu.git;a=commit;h=564c337efd415df3ab58c5bd080139e9f997d265 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 336005 [details] Relative mouse motion VNC extension Hi, I have backported code at http://git.kernel.org/?p=virt/qemu/qemu.git;a=commitdiff;h=564c337efd415df3ab58c5bd080139e9f997d265;hp=2a2528266e6834aa1dc8280ca91e334f52267365 to create a VNC patch. I have it tested and it appears to be working fine with no 'dual pointer'. I was unable to get 'dual pointer' here. Basically it adds relative mouse motion support (extension) for Xen's QEMU VNC server. Michal
Fix built into xen-3.0.3-85.el5
If it helps as a work around in the mean time, I've been able to get RHEL guest mice to behave by running the following in the VNC session in the guest: xset m 1/1 To make it persistent, I just add the above line as a session startup program. I don't know off hand if there is an equivalent setting for Windows guests, but at least this should be helpful for RHEL guests.
It's been just a backport of above and in fact I didn't understood this one but it's been ACKed because it matches upstream and it's been tested.
There are still "two cursors" in xen-3.0.3-90.el5: (1)start a PV guest or HVM guest.(domain0 in xen-3.0.3-90.el5) (2)on domain0,connect the guest with vncviewer: #vncviewer 127.0.0.1:<domain_id> Then the VNC window pops up. But there are two pointers,a virtual mouse cursor and a small square.There is a varying distance between the small square which seems to be the real mouse cursor as it becomes the windows mouse as soon as it leaves the VNC window. The two 'cursors' aren't overlayed and change distance and relationship. Using virt-viewer,there is only one cursor.I don`t konw if it is because Xen QEMU VNC server has supported relative mouse VNC extension?
This is expected behaviour. The 'vncviewer' program does not understand the VNC extension, so will always show two cursors. Only 'virt-viewer' or 'virt-manager' will do the right thing.
So "support relative mouse VNC extension" means hacks both in client end and in server end?The client sends relative motion to the server so that the server do not have to convert it?
Using 'virt-viewer',no 'dual pointer' found in both xen-3.0.3-80.el5 and xen-3.0.3-90.el5. Has the issue been fixed since xen-3.0.3-80.el5?
There are still 'dual pointer' in xen-3.0.3-91.el5 on ia64 machine: I have started a PV guest and HVM guest on a ia64 host.In both guests,there are "two pointers" in the virt-manager window in either xen-3.0.3-80.el5 or xen-3.0.3-91.el5.It is OK in i386 or x84_64 machine in which we can see only one pointer in the virt-manager window in both xen-3.0.3-80.el5 and xen-3.0.3-91.el5.
This bug is verified in xen-3.0.0-91.el5, I test in ia64 system and can also be verified. The comment #13 failed reason is that yufang are using remote ia64 system, and the comment #9 has given the reason for this. So I will change the status of this bug to verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1328.html