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 far away. Version-Release number of selected component (if applicable): xorg-x11-drv-vmmouse-12.4.3-4.fc9. How reproducible: Always. Steps to Reproduce: 1. update a vmware image using vmmouse driver to at least 22-Feb-08 2.Observe disconnected cursor position 3. Actual results: Cursor pos'n doesn't match screen coordinates Expected results: Cursor reflects correct coordinates. Additional info: 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 (http://groups.google.com/group/linux.debian.maint.x/browse_thread/thread/9c2ecc22fba0f03a) 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 symptoms. 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 is?
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 screen height. This can make it difficult to reach menus at the top and/or bottom of the screen. These issues go away again if evdev is prevented from loading using the work-around above.
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 acceleration. 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 "acceleration stage". 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. http://fedoraproject.org/wiki/Docs/Beats/Desktop
(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 correctly)?
(In reply to comment #26) > I already put the release note in at the same time I yanked this from the blocker. > > http://fedoraproject.org/wiki/Docs/Beats/Desktop 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 entry.
(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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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: http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html
*** 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. http://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.5.2-1.fc9
*** 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. > http://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.5.2-1.fc9 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. > Thx. 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. http://koji.fedoraproject.org/scratch/whot/task_900326/
(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: > 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. 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 > shortly. 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. http://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.6.1-1.fc9
xorg-x11-server-1.5.2-2.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-2.fc9
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. http://admin.fedoraproject.org/updates/xorg-x11-server-1.5.2-3.fc9
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.