Bug 242676 - Mouse pointer in VM moves at incorrect speed
Summary: Mouse pointer in VM moves at incorrect speed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: 7
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Daniel Berrangé
QA Contact: Martin Jenner
URL:
Whiteboard:
: 437027 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-05 12:42 UTC by Alex Hudson (Fedora Address)
Modified: 2008-05-15 12:24 UTC (History)
7 users (show)

Fixed In Version: virt-manager-0.5.3-2.fc8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-15 12:24:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alex Hudson (Fedora Address) 2007-06-05 12:42:22 UTC
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 2007-06-21 03:08:15 UTC
I am seeing the same problem as well, the guest OS is Win XP in QEMU.

Comment 2 Josh Cogliati 2007-06-26 18:20:22 UTC
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 16:19:59 UTC
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 17:20:20 UTC
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 14:46:05 UTC
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 Berrangé 2007-06-28 14:54:25 UTC
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 15:14:52 UTC
So, until this patch is added, is there any way to enable the appropriate
graphics table in the meantime?

Comment 8 Daniel Berrangé 2007-06-29 10:57:20 UTC
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-25 02:12:50 UTC
change QA contact

Comment 10 Jonathan Underwood 2007-08-05 19:54:59 UTC
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-05 00:33:16 UTC
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 Berrangé 2007-12-05 00:54:50 UTC
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-05 01:04:08 UTC
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 15:02:17 UTC
*** Bug 437027 has been marked as a duplicate of this bug. ***

Comment 15 Bug Zapper 2008-05-14 12:49:34 UTC
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 12:24:24 UTC
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.