Red Hat Bugzilla – Bug 444395
VMMouse mouse movement broken
Last modified: 2008-09-10 10:55:25 EDT
Originally reported on bug #434807, but looks like this is unrelated after all:
"I recently installed Fedora9Pre on KVM. After setting the mouse to use the
vmmouse driver, all mouse actions (moving, pressing) only result in horizontal
movement of the mouse pointer to the right."
Created attachment 303944 [details]
I have to add NoAutoAddDevice to xorg.conf in order to set my own mouse
section. This works as shown here when using the "mouse" driver, but I get the
problem as described above when switching to "vmmouse".
Created attachment 303945 [details]
This is the bottom part of the xorg log. Interestingly, the vmmouse module is
loaded, but the evdev driver is loaded after it as well and it sets some
strange macintosh mouse options...
Heh... I renamed the evdev input driver .so file to .so-bak, and now vmmouse
works fine. Shouldn't NoAutoAddDevice prevent the default driver from being used?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
(In reply to comment #3)
> Heh... I renamed the evdev input driver .so file to .so-bak, and now vmmouse
> works fine. Shouldn't NoAutoAddDevice prevent the default driver from being used?
NoAutoAddDevices (mind the plural)
(In reply to comment #2)
> Created an attachment (id=303945) [details]
> xorg log
> This is the bottom part of the xorg log. Interestingly, the vmmouse module is
> loaded, but the evdev driver is loaded after it as well and it sets some
> strange macintosh mouse options...
For the future, please submit logs as text files and don't cut them. For example, the typo here would have been easily spotted in the first 30 lines of the log (if you know what you have to look for).
I'm closing this as a duplicate to 434807, as the basic problem is the same - vmmouse doesn't scale properly and there's a conflict with the evdev driver.
Once we fix the scaling issues (and others) this bug will be gone as well.
*** This bug has been marked as a duplicate of bug 434807 ***