Bug 439336
Summary: | Cursor isn't where mouse "is" | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Austin <aa_sb_0> | ||||
Component: | xorg-x11-server | Assignee: | Kristian Høgsberg <krh> | ||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 9 | CC: | 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
Austin
2008-03-28 03:41:17 UTC
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 released. 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: * 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... 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. 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 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping 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 *** |