Bug 439336 - Cursor isn't where mouse "is"
Cursor isn't where mouse "is"
Status: CLOSED DUPLICATE of bug 434807
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
9
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-27 23:41 EDT by Austin
Modified: 2008-10-22 01:12 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-22 01:12:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
All messages from an invocation of startx. (2.73 KB, text/plain)
2008-03-27 23:41 EDT, Austin
no flags Details

  None (edit)
Description Austin 2008-03-27 23:41:17 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?)

How reproducible:
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.


Additional info:
See attached log file. Anything else available on request.
Oh, I'm running this inside a VMWare (v1.04) VM with VMWare-Tools installed.
Comment 1 Austin 2008-03-27 23:41:18 EDT
Created attachment 299431 [details]
All messages from an invocation of startx.
Comment 2 Austin 2008-04-01 00:07:53 EDT
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.
Comment 3 Austin 2008-04-01 01:08:22 EDT
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.
Comment 4 Matthias Clasen 2008-04-01 13:26:06 EDT
Definitively sounds more like an X problem than gdm's fault. Reassigning to a
better component for further triage.
Comment 5 Ray Strode [halfline] 2008-04-01 16:25:58 EDT
if you run

xset m 0

does it workaround the issue?
Comment 6 Austin 2008-04-01 21:49:03 EDT
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
released.
Comment 7 Matěj Cepl 2008-04-02 18:53:15 EDT
OK, let us know.
Comment 8 Austin 2008-04-02 19:51:50 EDT
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. :-/
Comment 9 Austin 2008-04-02 20:06:40 EDT
Current work around (when I return to the VM and realise the mouse isn't where
the cursor is) extends to:
* ALT+F2
* 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.
* ALT+F2
* xset m 0

Not brilliant, but at least I can use X in the VM now...
Comment 10 Ray Strode [halfline] 2008-04-02 22:15:50 EDT
On a sort of side note, there's a long standing virt-manager bug with the exact
same behavior.

I don't know if it's related somehow.
Comment 11 Jeff Bastian 2008-04-03 10:07:59 EDT
If you're running under VMware, this sounds like a duplicate of bug 434807.  Try
the workaround in
https://bugzilla.redhat.com/show_bug.cgi?sourceid=Mozilla-search&id=434807#c6

Comment 12 Austin 2008-04-03 18:25:30 EDT
Quite possible. I just had a read and it does sound very similar. Is it an X
server problem, or vmware mouse driver problem?
Comment 13 Bug Zapper 2008-05-14 04:21:46 EDT
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
Comment 14 Peter Hutterer 2008-10-22 01:12:06 EDT
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.

https://admin.fedoraproject.org/updates/xorg-x11-drv-vmmouse-12.5.2-1.fc9

*** This bug has been marked as a duplicate of bug 434807 ***

Note You need to log in before you can comment on or make changes to this bug.