Red Hat Bugzilla – Bug 434807
vmmouse cursor position doesn't match screen coordinates
Last modified: 2018-04-11 04:34:49 EDT
Description of problem:
Recent (22-Feb-08) rawhide update breaks vmmouse. Cursor appears and is mobile,
but screen coordinates are wrong; can't click on anything. If you happen to see
a button or menu item highlight from mouseover, click will work, but cursor is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. update a vmware image using vmmouse driver to at least 22-Feb-08
2.Observe disconnected cursor position
Cursor pos'n doesn't match screen coordinates
Cursor reflects correct coordinates.
May be related to vmmouse-coord-hack.patch, added 2-Jan to work around an
upstream bug. Both Fedora (https://bugs.freedesktop.org/show_bug.cgi?id=13552)
and Debian added the workaround
Upstream bug: (https://bugs.freedesktop.org/show_bug.cgi?id=10324).
This upstream bug seems to be fixed in xorg-x11-server 02-05-08, so I would
guess that the vmmouse-coord-hack.patch can be backed out.
I will downgrade to xorg-x11-drv-vmmouse-12.4.3-2.fc9, before the coord-hack
patch was applied, to see if it fixes the issue, and add that info later
tonight. (I first tried downgrading to just 12.14.3-3.fc9 before I looked into
any details, and of course it didn't fix anything).
Let us know, how the downgrading went.
Created attachment 295874 [details]
xorg.0.log when vmmouse is specified in xorg.conf
xorg.0.log when vmmouse is specified in xorg.conf
Well, reverting to xorg-x11-drv-vmmouse-12.4.3-2.fc9 does not help; exact same
Let me know what other info can help diagnose the problem.
(Sorry, I attached the first file before sending these comments).
Next attchment will be Xorg.0.log with no xorg.conf.
Created attachment 295875 [details]
log file with no xorg.conf
Everything is autodetected here. Mouse works OK in this case, but is captured
by the vmware window.
Found a work-around: add 'Option "AutoAddDevices" "no"' to xorg.conf
ServerLayout section. This prevents "Macintosh mouse button emulation" and
ImPS/2 from loading (presumably from hal), and hence evdev is not loaded
either. vmmouse then works OK when specified in xorg.conf.
Is that expected behaviour?
Denying AutoAddDevices also fixes this mouse location weirdness for me with VMware Fusion 1.1. The
input devices are manually configured instead and it works for logging in via startx. Having this
configuration and the latest gdm is still an unworkable situation for me (gdm respawning with any input)
but the accurate location of the mouse click is fixed.
It seems like creating the multiple input pointers is causing them to fight over where the mouse currently
One of the recent updates appears to have fixed this. I tried with updates of
7-Mar, and vmmouse driver works without denying "AutoAddDevices". evdev is
loaded. xorg-x11-drv-vmmouse version has not changed though, some other
update fixed it.
(Now vmware screen driver can't find any valid screens though, so today's test
is with the VESA driver, FWIW)
Sorry, I spoke too soon: there's still a problem when evdev is loaded, but the
symptoms are different. Now the cursor location in the virtual machine window
is as expected, but the cursor jumps out of the window at strange locations.
For example, moving toward the left side of the virtual screen, the pointer
may jump into the host window way before reaching the left border of the
virtual screen. Additionally, this discrepancy is variable, so sometimes it
jumps out too early, sometimes it's about right, and sometimes it's too late
(stopping at the VMs window momentarily before popping onto the host screen).
The vertical locations do not match either, differing by 1/4 to 1/2 of the
This can make it difficult to reach menus at the top and/or bottom of the
These issues go away again if evdev is prevented from loading using the
I'm using VMware Fusion 1.1.1 and have the same problem. I just added
Option "AutoAddDevices" "no"
to my xorg.conf and the mouse works correctly now.
Since many folks (like myself) tend to use virtual machines for testing alpha
and beta releases, I've increased the priority and severity on this bug.
Now, after recent vmmouse & x11server updates, behaviour is back to original:
Still have a disconnect between the 'hotspot' and the pointer position. But no
more pointer jumps when passing between vm window and host window; behaviour
described in comment #10 is gone.
As before, works fine if evdev is suppressed by Option "AutoAddDevices" "No"
Should this be reclassed against evdev?
I can verify it returned (comment #13), using both the Rawhide snapshot Live disks of 20080327 I see the
same problem on vmware fusion (osx 10.5 host).
I think a bug I reported (bug# 439336) is a duplicate of this one. Some
suggestions there helped by turning off mouse acceleration (xset m 0). It works
as long as the cursor stays in the main window. Once it leaves and returns it
has the same problem.
Have a a read of the bug to see for yourself if any of the problems and proposed
solutions there are applicable.
Created attachment 300370 [details]
xorg.conf with no auto added devices, typical laptop screen setup (may need adjusted)
Austin, after reading your bug it is nearly identical to the situation
described here. I would suggest trying this xorg.conf and if it works fine for
your setup then the auto added devices are partly to blame, not just
It is interesting however that the acceleration set to 0 does help. I noticed
the same behavior you're describing where the mouse location is somewhat
predictable if you move extremely slowly and smoothly. It really has a
predictable offset in x/y until you move fast again, so each time the mouse
accelerates it ends up with a recalc of its location offset from where you see
the cursor. With NoAutoAddDevices this doesn't happen.
I'm going to guess that there's more than one "mouse" being picked up (somehow).
Disabling auto-add stops the additional "mice", and the acceleration problems is
because both "mice" are being accelerated resulting in twice the distance being
reported back. Or something like that.
If the mouse is moved slowly, there's no problem, because it doesn't enter the
These are just guesses based on observations. I'll try the "no auto add devices"
trick to see if that helps some more.
Any word from a developer?
I thought that evdev was gone for mice (or is that just keyboards?). I do most
of my testing in VMWare, however, I just let it autoconfigure stuff for me in X
(I do most of my X work on an HP laptop that I use for testing). I've not
noticed a problem with the mouse. I'll make sure that it really is using
vmmouse and test again hopefully this evening or tomorrow
OK, sorry that took awhile. I'm not an X guy and had to figure some things out
:). Being that this config is not the default, that it is difficult and
requires manual intervention to get into a non-working configuration (and I have
verified that the config is bustificated), it doesn't take much more to get to a
working config, as mentioned in comment #16 - I'm going to remove this from the
F9 blocker and put it on F9Target.
Adding a "me too" to this bug.
This seems to a problem across VMware products. I've duplicated it with the F9
Beta Live CD on both VMware Fusion (1.1, OS X 10.4.10 [I think - dont have my
MBP with me at work]) and VMware Server (1.0.5, Fedora 8 host).
Let me know if you want me to test or attach anything.
I restently installed Fedora9Pre on KVM. Using vmmouse, all mouse actions
(moving, pressing) result in horizontal movement of the mouse pointer to the
right. I'm wondering if this is releated to this bug?
Also, using the default mouse (which was using evdev I guess) I was unable to
get the mouse wheel working.
Anyway, after adding the suggested workaround I can use the wheel with the
"mouse" driver (the ZAxisMapping setting is now picked up). But, if I use
vmmouse I still see the same bad movement :(
FYI, this bug no longer seems to be present in the F9-Preview-LiveCD when
running on VMware Server 1.0.5 on a F8 host. Will check on Fusion this weekend
My problem still exists (running Preview+updates on KVM). If this turns out to
not be the same problem, I'll file another bug.
As of rawhide 20080417 this problem existed for me, using VMWare Server 1.0.4.
There have been no updates to the vmmouse driver since that time (however, there
have been core X updates).
I'll test again this weekend as well.
Still exists for me (rawhide updated to 25-Apr-08)
Summary, just retested:
* No xorg.conf: pointer works normally, but captured by VM window
* vmmouse in xorg.conf: pointer problem is as described above
* vmmouse in xorg.conf, with AutoAddDevices set to false: pointer works
normally, and seamlessly across host & VM windows.
Although Jon is right in comment #19 about it needing work to get it to a
broken state, adding vmmouse for seamless pointers is the first thing most
people do when setting up a VM.
Maybe the workaround should be listed in the release notes?
I already put the release note in at the same time I yanked this from the blocker.
(In reply to comment #26)
> I already put the release note in at the same time I yanked this from
> the blocker.
Uhm... first, this does not fix things for me. Second, isn't xorg using the
"mouse" driver when "NoAutoAddDevices" is used, so all this "workaround" does is
enabling the mouse section (which then can contain vmmouse, which does not work
(In reply to comment #26)
> I already put the release note in at the same time I yanked this from the
Sorry Jon, I should have re-checked.
Michael, it sounds like the problem you described in comment #21 (horizontal
pointer movement on button presses) is something different than this bug,
especially if the workaround doesn't fix it. Probably worth a new bugzilla
(In reply to comment #28)
> Probably worth a new bugzilla entry.
I filed a new bug: #444395.
Just after filing it I realized what is wrong: my xorg never actually uses the
vmmouse driver! it seems to load it just fine but loads evdev after it. After
renaming the evdev driver, vmmouse works correctly.
Nobody else here seeing such a problem? Do you all have evdev installed?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Here's what happens:
VMMouse attaches to /dev/input/mice and communicates with the VM to get absolute data. If we're not running inside a VM, then the driver actually instantiates the mouse driver.
Now with F9 we use input hotplugging with the evdev driver. This driver grabs each device, stopping it from sending to /dev/input/mice. The vmmouse driver becomes essentially ineffective as it'll never receive any events.
The only way to stop evdev from grabbing the event device is by disabling it - AutoAddDevices off. I'm afraid there's no better solution to this.
To resolve this issue, the upstream driver needs to be updated to work on the event devices instead.
A long description of evdev's interaction with devices can be found here:
*** Bug 461466 has been marked as a duplicate of this bug. ***
*** Bug 444395 has been marked as a duplicate of this bug. ***
xorg-x11-drv-vmmouse-12.5.2-1.fc9 has been submitted as an update for Fedora 9.
*** Bug 439336 has been marked as a duplicate of this bug. ***
Created attachment 321276 [details]
Log file with signal 11 & backtrace when using new vmmouse driver
(In reply to comment #34)
> xorg-x11-drv-vmmouse-12.5.2-1.fc9 has been submitted as an update for Fedora 9.
Sorry, but I get X backtraces whenever this new vmmouse is used.
I tested in sequence, with the following results:
* Freshly installed F9 system, new vmmouse: would not load vmmouse driver (wrong version), no mouse movement.
* Same, but now add up-to-date evdev: same result (wrong version) and no mouse.
* Same, but now add 'yum update xorg*': signal 11 & backtrace.
* finally, a fully updated F9: same signal 11 & backtrace.
Log file is attached. I did verify that there were no backtraces and X came up normally if vmmouse was commented out.
Forgot to mention that current F10 rawhide seems to be fixed. When I remove the workaround I had been carrying (comment #6), the mouse still works properly: no offsets.
xorg-x11-drv-vmmouse-12.5.2-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update xorg-x11-drv-vmmouse'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9035
(In reply to comment #37)
> Forgot to mention that current F10 rawhide seems to be fixed. When I remove
> the workaround I had been carrying (comment #6), the mouse still works
> properly: no offsets.
Well now rawhide X server generates backtraces too, since xorg-x11-drv-12.5.2-1.fc10 has been installed.
Reverting it gets X working again, and as before, the workaround is not needed.
Pulled it from F9 again. can you please attach your log with the backtrace. Thx.
Created attachment 321369 [details]
F10 Rawhide Xorg.0.log w/ backtrace
(In reply to comment #40)
> Pulled it from F9 again. can you please attach your log with the backtrace.
Sure. F9 (up-to-date) log is https://bugzilla.redhat.com/attachment.cgi?id=321276
and I'm just attaching F10 Rawhide log now.
I got it narrowed down to two issues that could trigger that:
Here's a vmmouse update that should merely avoid it: http://koji.fedoraproject.org/scratch/whot/task_900206/
And that's a xserver with additional sanity checks that should not fail even if the driver misbehaves: http://koji.fedoraproject.org/scratch/whot/task_900222/
Can you please give them a try? Thanks.
Philip just released vmmouse 12.6.0 which fully supports HAL etc. Can you give the package a try too please? I fail at getting vmware to run.
(In reply to comment #42)
> I got it narrowed down to two issues that could trigger that:
> Here's a vmmouse update that should merely avoid it:
> And that's a xserver with additional sanity checks that should not fail even if
> the driver misbehaves: http://koji.fedoraproject.org/scratch/whot/task_900222/
> Can you please give them a try? Thanks.
All tests below are under F10 rawhide, up to date 23-Oct-08:
First updated xerver: new xserver keeps xorg-x11-drv-vmmouse-12.5.2-1 from segfaulting, mouse seems to track properly. But under gnome I need to hold down LMB to keep menu panels up. Selection is made when LMB is released. It's worse under KDE, as menus flash then disappear, even if LMB is held down. A single click & hold LMB on Konsole titlebar will maximize the window. Not sure if this is related to the new xserver, bad vmmouse, or general rawhide dementia. Note that this is fixed if I set AutoAddDevices to "No" in xorg.conf: clicks are back to normal
Next I updated vmmouse to 12.5.2-2: Works just like description above. No segfaults, but weird click events. Seems to send two click events, turning everything into double clicks. As above, click dementia can be fixed by suppressing AutoAddDevices.
Finally I updated to vmmouse 12.6.0-1: Same as above: no segfaults, proper tracking, good behavior when passing between host & guest window, but still has click dementia. Again, fixed by suppressing AutoAddDevices.
Created attachment 321483 [details]
"xinput -list" with AutoAddDevices=true
xinput list when devices are auto added. vmmouse-12.6.0, xserver-1.5.2-9
This configuration has 'unintentional double-click dementia'
Created attachment 321484 [details]
"xinput -list" when AutoAddDevices=False
xinput list when devices are *not* auto added. vmmouse-12.6.0, xserver-1.5.2-9
This configuration works no problem.
Let me know if you need any Xorg.0.log files
Further update: things look fixed under rawhide :)
I updated to today's (24-Oct) rawhide, rebooted, and mouse is working! No workaround needed! Not sure what fixed it. Testing in comments 44 to 46 was done without rebooting, only 'telinit 3' and 'telinit 5' or startx. Should I have rebooted?
So AFAICT, this can be closed under Rawhide. I'll test vmmouse-12.6.0 under F9 shortly.
(In reply to comment #47)
> So AFAICT, this can be closed under Rawhide. I'll test vmmouse-12.6.0 under F9
F9 is still not working.
On a fully up-dated F9, I tried to update to vmmouse-12.6.0, and got the same segfaults & backtrace as before.
Then I updated to xserver-1.5.2-9 (with the sanity checks), and backtraces stopped. Mouse works OK as long as workaround (AutoAddDevice=false) is still in place. Without workaround, the clicking is OK, but the original problem is still there: the pointer location does not correspond to the 'hot-spot'.
xorg-x11-drv-vmmouse-12.6.1-1.fc9 has been submitted as an update for Fedora 9.
xorg-x11-server-1.5.2-2.fc9 has been submitted as an update for Fedora 9.
Applying updates in comment #49 and comment #50 fixed this for me! On a test F9 system, fully up to date, I get no segfaults and good tracking / release with no workaround needed.
Great job, thanks!
I'm curious how you work around bug 461465. Do you use a custom xorg.conf file ?
(In reply to comment #52)
> I'm curious how you work around bug 461465. Do you use a custom xorg.conf file
Yes, I've generated a default one using 'Xorg -configure', and modified it by hand to add vmmouse. Newest vmware-tools should be able to do that for you; I haven't tried recently.
Reading through your bug, it seems that the way is clear to add autodetect for vmmouse, now that the evdev situation is fixed. Perhaps re-open it for an F11 feature? That would be *great* for virtual clients. (Do other VM systems use the vmmouse driver too? I only have experience with VMware).
Actually, after retesting without xorg.conf, autodetect now works! So vmmouse is back to 100% support.
xorg-x11-server-1.5.2-3.fc9 has been submitted as an update for Fedora 9.
xorg-x11-drv-vmmouse-12.6.1-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
xorg-x11-server-1.5.2-3.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.