Red Hat Bugzilla – Bug 439336
Cursor isn't where mouse "is"
Last modified: 2008-10-22 01:12:06 EDT
Description of problem:
Mouse clicks and mouse overs are observed to be anywhere up to 100 pixels from
where the cursor is. (rough guess)
Version-Release number of selected component (if applicable):
(see attached log file?)
Every time I start X
Steps to Reproduce:
1. I don't know if these first steps are necessary but I can't log in from the
provided login manager. It just resets the X server and brings the login screen
again. So, I switch to run level 3.
2. Login as normal user.
3. run startx >& /tmp/startx_errors.log
4. Try to click on ANYthing - logging out via the menus is particularly
amusing... the first few times.
5. Observe the inability to use the GUI.
See attached log file. Anything else available on request.
Oh, I'm running this inside a VMWare (v1.04) VM with VMWare-Tools installed.
Created attachment 299431 [details]
All messages from an invocation of startx.
It does make the GUI next to unusable.
I've tried with the v1.05 VMWare Server update including the any-any-115 patch,
and the problem still exists.
It would appear to be related to mouse acceleration, as if I move the mouse
slowly, it follows a menu 3 inches away linearly. BUT, if I move the mouse
quickly, the shadow in the menus moves faster than the cursor does.
Using this mapping, and "click dragging" on the desktop to find out where it
thinks the cursor really is, I can once again navigate the menu system. Painful,
but I can do it.
Definitively sounds more like an X problem than gdm's fault. Reassigning to a
better component for further triage.
if you run
xset m 0
does it workaround the issue?
Yes, I think so. But after setting 'm' to zero, the mouse cursor is
_permanently_ offset from where the mouse believes it is.
I received the notification of some updates available, but when trying to move
the mouse over the pop up, the cursor "jumps" to approximately where the
underlying mouse is and back again over certain areas.
Will tinker with this command to find a suitable work around until the fix is
OK, let us know.
After disabling mouse acceleration with 'xset m 0', the mouse and cursor offset
are stable - BUT, when the mouse leaves the VM and returns, the offset can be
anywhere. Related to the exit and entrance points of the VM's 'screen' I think.
Not brilliant. :-/
Current work around (when I return to the VM and realise the mouse isn't where
the cursor is) extends to:
* xset m
( Resets Mouse acceleration back to "default" )
* Minimise all
* Use the desktop to draw a selection rectangle to find out where the mouse is
and using the acceleration mis-match, align the two within an acceptable tolerance.
* xset m 0
Not brilliant, but at least I can use X in the VM now...
On a sort of side note, there's a long standing virt-manager bug with the exact
I don't know if it's related somehow.
If you're running under VMware, this sounds like a duplicate of bug 434807. Try
the workaround in
Quite possible. I just had a read and it does sound very similar. Is it an X
server problem, or vmware mouse driver problem?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Marking as duplicate of 434807. The vmmouse driver does not cooperate well with the evdev driver which is now the standard mouse driver.
An updated xorg-x11-drv-vmmouse package has been posted and it may address these issues.
*** This bug has been marked as a duplicate of bug 434807 ***