Bug 439336

Summary: Cursor isn't where mouse "is"
Product: [Fedora] Fedora Reporter: Austin <aa_sb_0>
Component: xorg-x11-serverAssignee: Kristian Høgsberg <krh>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 9CC: mcepl, peter.hutterer, rstrode, tiagomatos, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-22 05:12:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
All messages from an invocation of startx. none

Description Austin 2008-03-28 03:41:17 UTC
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-28 03:41:18 UTC
Created attachment 299431 [details]
All messages from an invocation of startx.

Comment 2 Austin 2008-04-01 04:07:53 UTC
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 05:08:22 UTC
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 17:26:06 UTC
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 20:25:58 UTC
if you run

xset m 0

does it workaround the issue?

Comment 6 Austin 2008-04-02 01:49:03 UTC
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 22:53:15 UTC
OK, let us know.

Comment 8 Austin 2008-04-02 23:51:50 UTC
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-03 00:06:40 UTC
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-03 02:15:50 UTC
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 14:07:59 UTC
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 22:25:30 UTC
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 08:21:46 UTC
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 05:12:06 UTC
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 ***