Bug 487559 - RFE: Xen QEMU VNC server needs to support relative mouse VNC extension
RFE: Xen QEMU VNC server needs to support relative mouse VNC extension
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Michal Novotny
Virtualization Bugs
Depends On:
Blocks: 223805 477162
  Show dependency treegraph
Reported: 2009-02-26 13:08 EST by Daniel Berrange
Modified: 2014-02-02 17:36 EST (History)
7 users (show)

See Also:
Fixed In Version: xen-3.0.3-85.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 06:06:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

External Trackers
Tracker 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 06:32:30 EDT

  None (edit)
Description Daniel Berrange 2009-02-26 13:08:23 EST
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


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 2 Michal Novotny 2009-03-20 05:29:29 EDT
Created attachment 336005 [details]
Relative mouse motion VNC extension

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.

Comment 3 Jiri Denemark 2009-05-11 09:40:45 EDT
Fix built into xen-3.0.3-85.el5
Comment 6 David Egts 2009-06-05 10:52:23 EDT
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 05:59:28 EDT
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 09:46:11 EDT
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:

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 Berrange 2009-07-22 14:18:30 EDT
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-22 22:00:31 EDT
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-22 23:18:49 EDT
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 01:05:54 EDT
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 02:56:59 EDT
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 06:06:37 EDT
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.


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