Bug 242676 - Mouse pointer in VM moves at incorrect speed
Mouse pointer in VM moves at incorrect speed
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
7
All Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Berrange
Martin Jenner
:
: 437027 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-05 08:42 EDT by Alex Hudson (Fedora Address)
Modified: 2008-05-15 08:24 EDT (History)
7 users (show)

See Also:
Fixed In Version: virt-manager-0.5.3-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-15 08:24:24 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alex Hudson (Fedora Address) 2007-06-05 08:42:22 EDT
Description of problem:

The mouse pointer within the VM does not move at the same speed as my desktop
mouse pointer. 

It seems like the host mouse DPI and the guest mouse DPI are set differently. If
the host moves more slowly, there aren't any major problems - if it moves more
quickly, even when the pointer is captured you but against the extents of the
console window - parts of the guest screen therefore become inaccessible.

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


How reproducible:


Steps to Reproduce:
1. Setup new virtual machine in virt-manager, e.g., install RHEL4
2. Reach first graphical screen (Welcome to RHEL_ServerCD)...
3.
  
Actual results:

On first graphical screen in install, note that mouse pointer moves more quickly
than desktop pointer.

Expected results:

The pointers ought to move together, in the same position and with the same speed.


Additional info:

This is as plain an install as possible; I haven't configured much. The VM is
setup as a QEMU machine with full virtualisation but on the same architecture as
the host.
Comment 1 Edmond Hui 2007-06-20 23:08:15 EDT
I am seeing the same problem as well, the guest OS is Win XP in QEMU.
Comment 2 Josh Cogliati 2007-06-26 14:20:22 EDT
I see the same problem with QEMU.  If I manually run qemu without -vnc the mouse
works fine in the SDL display.  
Comment 3 Josh Cogliati 2007-06-27 12:19:59 EDT
Here is a description of the problem and how to solve it (though I have no idea
where to put the config flag in fedora):
http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html#SECTION04343000000000000000
Comment 4 Josh Cogliati 2007-06-27 13:20:20 EDT
Question: 
Where do I put the (usbdevice tablet) string to get the usbdevice mentioned in
the xen user manual?
If I put it in /var/lib/xend/domains/88fe...53/config.sxp it will get removed
the next time I run the domain.

I don't see any hvm section anywhere else on the system.
Comment 5 Josh Cogliati 2007-06-28 10:46:05 EDT
Based on the email
https://www.redhat.com/archives/fedora-xen/2007-June/msg00043.html
and the webpage 
http://libvirt.org/format.html
I think it is near impossible to get usbdevice tablet working in Fedora.  I did
try changing <graphics type='vnc' port='-1'/> to  <graphics type='sdl'/>
foo is the domain:
virsh dumpxml foo > /tmp/foo.xml
edit /tmp/foo.xml and change line <graphics type='vnc' port='-1'/> to  <graphics
type='sdl'/>
virsh define /tmp/foo.xml
but xen still seems to uses vnc. (Despite the creation of   (device (vfb (type
sdl) (uuid 54..86))) in the config.sxp file.  

So probably the easiest solution to this is probably to add the gui required for
sdl versus vnc in virt-manager and make graphics type='sdl' work.  
Based on:
http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/user/user.html#SECTION04343000000000000000
I don't think it will be quick to get vnc to properly do the mouse handling.
Comment 6 Daniel Berrange 2007-06-28 10:54:25 EDT
Virt manager cannot & will not support SDL graphics. SDL merely pops up a
standalone window on the X server - if you kill that window the VM dies. Clearly
this is useless because you can't keep the window open all the time. SDL is also
useless for remote management of VMs.

The solution is to make the mouse work correctly under VNC which is being
attacked on a number of angles. For fullyvirt VMs we will be enabling a graphics
table suitable for the guest OS, while paravirt VMs will 'just work' with a few
tweaks to X org config.
Comment 7 Josh Cogliati 2007-06-28 11:14:52 EDT
So, until this patch is added, is there any way to enable the appropriate
graphics table in the meantime?
Comment 8 Daniel Berrange 2007-06-29 06:57:20 EDT
There's no easy option until we add support for it in libvirt I'm afraid. We
have a design for making it work - its just a question fo developer time.....
Comment 9 Red Hat Bugzilla 2007-07-24 22:12:50 EDT
change QA contact
Comment 10 Jonathan Underwood 2007-08-05 15:54:59 EDT
I see a very similar issue using virt-manager with qemu-kvm guests - the
mouseperiodically can't move past a particular horizontal or vertical line - it
feels like the mouse pointer is bumping up against the edge of the window, but
it clearly isn't. This doesn't occur with qemu-kvm running in its own Xwindow,
only within virt-manager. This makes the guest unusable. This is on F7

libvirt-0.3.1-2.fc7
libvirt-python-0.3.1-2.fc7
python-virtinst-0.200.0-2.fc7
virt-manager-0.4.0-2.fc7

Bumping priority of this, as I think this is a massive usability issue.
Comment 11 Jonathan Underwood 2007-12-04 19:33:16 EST
Happy to report that I don't see this anymore in F-8 with
virt-manager-0.5.2-2.fc8
libvirt-0.3.3-2.fc8

I see that VMs are now created with a tablet device. The downside of this is
that even with the VM doing nothing, top shows virt-manager using 30 % CPU. Not
sure if this is related or not to having atablet virtual device.
Comment 12 Daniel Berrange 2007-12-04 19:54:50 EST
Do you really mean virt-manager is using 30% CPU, or do you mean that the
virtual machine is using 30% CPU ?

And, yes, it is the USB tablet device that enables the cursor to move accurately.
Comment 13 Jonathan Underwood 2007-12-04 20:04:08 EST
Yes, sorry, what I said was misleading.

The process that consumes 30 percent CPU is the qemu instance.

Comment 14 Cole Robinson 2008-05-08 11:02:17 EDT
*** Bug 437027 has been marked as a duplicate of this bug. ***
Comment 15 Bug Zapper 2008-05-14 08:49:34 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 David Juran 2008-05-15 08:24:24 EDT
As Jonathan pointed out in comment 11, this seems to work fine in F8.

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