Bug 487559 - RFE: Xen QEMU VNC server needs to support relative mouse VNC extension
Summary: RFE: Xen QEMU VNC server needs to support relative mouse VNC extension
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen
Version: 5.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Michal Novotny
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 223805 477162
TreeView+ depends on / blocked
 
Reported: 2009-02-26 18:08 UTC by Daniel Berrangé
Modified: 2014-02-02 22:36 UTC (History)
7 users (show)

Fixed In Version: xen-3.0.3-85.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-02 10:06:37 UTC
Target Upstream Version:


Attachments (Terms of Use)
Relative mouse motion VNC extension (2.59 KB, patch)
2009-03-20 09:29 UTC, Michal Novotny
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1328 normal SHIPPED_LIVE xen bug fix and enhancement update 2009-09-01 10:32:30 UTC

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


Note You need to log in before you can comment on or make changes to this bug.