Mouse hangs in lower-right corner

Bug #92354 reported by Stephen Touset
8
Affects Status Importance Assigned to Milestone
qemu (Fedora)
Won't Fix
Medium
qemu (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: qemu

When I launch qemu with Windows running inside it, the mouse cursor is by default in the middle. The second I touch the mouse, it immediately goes to the far-left corner of the screen. Losing and regaining focus repeatedly (sometimes 100+ times) eventually brings the mouse back to a working state. If I lose and regain focus again, though, the mouse again returns to the bottom-right corner and stays.

Revision history for this message
Stephen Touset (stephen-touset) wrote :

This might be related to me using 2.6.20-9, rather than 2.6.20-10. I've been using -9 due to a kernel bug (turned out to be a severe issue in the kvm module, which I was autoloading at boot), and having booted into -10, this problem seems to have disappeared.

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Description of problem:
I setup an Xorg config under a Xen guest to use the evdev driver for input
instead of /dev/input/mice, since the former honours absolute pointer events &
thus avoids the insane 'double mouse' issues.

There appears to be a bug in the evdev driver though. If moving the cursor in
the X-axis only, or in the Y-axis only it works fine. If I move the cursor in
the X & Y axis at the same time (eg bottom-left -> top-right of screen), the
position of the cursor on screen seems to 'loose' the X co-ordinate updates
until I finish moving the mouse.

eg, move from bottom-left -> top-right of screen, while the mouse it moving the
cursor will only update the Y co-ordinate. When I stop moving the mouse, it
finally updates the X co-ordinate

Version-Release number of selected component (if applicable):
xorg-x11-drv-evdev-1.1.2-3.fc7

How reproducible:
Always

Steps to Reproduce:
1. Boot a Fedora 7 paravirt Xen guest
2. Configure it to use attached Xorg config file
3. Start X
4. Move mouse at a medium speed from bottom-left to top-right corner of screen

Actual results:
Mouse moves up left-hand side of screen, and then at last movement flips over to
top-right corner

Expected results:
Mouse moves smoothly diagonally across the screen from bottom-left to top-right.

Additional info:

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Created attachment 156818
Sample Xorg config to use evdev with Xen guest framebuffer

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Looking at the way the evdev events are fed from kernel upto X, the data stream
has 3 core types of event

 - X axis update
 - Y axis update
 - Sync event

The kernel normally sends a sequence of

 - X axis update + Y axis update + sync event
 - X axis update + sync event
 - Y axis update + sync event

There is some extra code in the evdev driver, however, which does an explicit
sync after every individual X or Y axis event. This seems to be causing the X
axis update to be lost - resulting in the cursor travelling up the left-hand
side of the screen when moved diagonally. This manual sync looks unneccessary
since the kernel sends an explicit sync event whenever one ie needed.

So I wrote the attached patch which removed the two redundant calls to sync
pointer position. This resulted in smooth mouse movement expected.

I'm a little puzzelled why these explicit sync calls are in the driver at all -
not clear they could ever have worked correctly ?!?!

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Created attachment 156820
Remove redundant pointer sync calls

Revision history for this message
In , Daniel (daniel-redhat-bugs) wrote :

Created attachment 172417
Remove redundant pointer sync calls

The xorg-x11-drv-evdev code currently in F7/rawhide doesn't compile. This
updated patch includes a fix to also remove use of
SendCoreEvents/DontSendCoreEvents flags which allows the driver to be rebuilt
with the pointer sync fix.

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Revision history for this message
In , Bug (bug-redhat-bugs) wrote :

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008.
Fedora 7 is no longer maintained, which means that it will not
receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

We are seeing nearly the same problem with intrepid alpha 3 installs. The mouse gets stuck in the lower right corner so every click opens the waste basket.

I've reported this as bug 251473 to get apport data attached, though it can probably be duped to this one.

Changed in qemu:
status: New → Confirmed
Revision history for this message
Simon Ruggier (simon80) wrote :

I'm seeing this bug on two different boxes running Hardy i386 and amd64, using both qemu and kvm. The only thing that works properly is to add -usb -usbdevice tablet and use that device instead, which works fine for windows, but not so fine in Ubuntu 6.06, for example, where it doesn't work by default, the evtouch driver isn't present, and the evdev driver doesn't work properly (though there is a patch at [1] that partially helps). The problem wasn't present in Gutsy.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=243920

Changed in qemu:
status: Unknown → Won't Fix
Revision history for this message
Eric (emehes) wrote :

i installed xubuntu 8.10 via wubi and i encountered the very same problem (save the mouse had a tendency to get stuck in the upper right corner). The same happened linux mint (felicia).

Revision history for this message
Jim (jwyllie83) wrote :

For anyone who runs across this problem: I had the same issue. It turns out that it was because I was using Synergy (the keyboard / mouse sync app) and this machine wasn't the computer with the devices connected to it. It was screwing up the update events.

If you're using Synergy, turn it off.

Changed in qemu (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
Simon Ruggier (simon80) wrote :

This doesn't relate to synergy, I've never used it on either of the two machines.

Revision history for this message
Riot777 (riot777) wrote :
Changed in qemu (Fedora):
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.