Bug 487559

Summary: RFE: Xen QEMU VNC server needs to support relative mouse VNC extension
Product: Red Hat Enterprise Linux 5 Reporter: Daniel Berrangé <berrange>
Component: xenAssignee: Michal Novotny <minovotn>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 5.4CC: alanm, areis, degts, llim, mshao, xen-maint, yuzhang
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: xen-3.0.3-85.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 10:06:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 223805, 477162    
Attachments:
Description Flags
Relative mouse motion VNC extension none

Description Daniel Berrangé 2009-02-26 18:08:23 UTC 
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:
Comment 2 Michal Novotny 2009-03-20 09:29:29 UTC 
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
Comment 3 Jiri Denemark 2009-05-11 13:40:45 UTC 
Fix built into xen-3.0.3-85.el5
Comment 6 David Egts 2009-06-05 14:52:23 UTC 
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.
Comment 7 Michal Novotny 2009-06-30 09:59:28 UTC 
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.
Comment 8 Yufang Zhang 2009-07-22 13:46:11 UTC 
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?
Comment 9 Daniel Berrangé 2009-07-22 18:18:30 UTC 
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.
Comment 10 Yufang Zhang 2009-07-23 02:00:31 UTC 
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?
Comment 11 Yufang Zhang 2009-07-23 03:18:49 UTC 
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?
Comment 12 Yufang Zhang 2009-07-28 05:05:54 UTC 
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.
Comment 14 Yewei Shao 2009-07-29 06:56:59 UTC 
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.
Comment 16 errata-xmlrpc 2009-09-02 10:06:37 UTC 
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