Mouse position repeatedly reset to top and/or left of screen -> X.Org bug

[Sam Morris]

The position of the mouse pointer, according to mouse integration, regularly warps to 0 on the X and/or Y axis.

To reproduce, drag a window in circles. After a few seconds the window position will warp to the top and/or left of the screen. The position of the mouse pointer on screen is not affected. Continuing to move the mouse after this has happened will result in the window returning to its correct position.

If I reproduce this bug and then do not move the mouse, xinput query-state 'VirtualBox mouse integration' prints the following:

2 classes :
ButtonClass
	button[1]=up
	button[2]=up
	button[3]=up
	button[4]=up
	button[5]=up
ValuatorClass Mode=Absolute Proximity=In
	valuator[0]=0
	valuator[1]=2449

Note the value for valuator[0]. Running xinput test 'VirtualBox mouse integration and then moving the mouse also reveals that the pointer warps to the corner of the screen:

motion a[0]=35390 
motion a[1]=29287 
motion a[1]=29225 
motion a[0]=0 a[1]=0 
motion a[0]=35468 
motion a[1]=29163 
motion a[1]=29100 

If I run xev and watch the output while moving the mouse in circles over the test area, I see the following sequence of events: you can see that Xorg thinks the mouse cursor momentarily moves to the top left corner of the screen:

MotionNotify event, serial 38, synthetic NO, window 0x4e00001,
    root 0x138, subw 0x0, time 1086667511, (68,100), root:(69,175),
    state 0x0, is_hint 0, same_screen YES

LeaveNotify event, serial 38, synthetic NO, window 0x4e00001,
    root 0x138, subw 0x0, time 1086667543, (-1,-75), root:(0,0),
    mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
    focus YES, state 0

EnterNotify event, serial 38, synthetic NO, window 0x4e00001,
    root 0x138, subw 0x0, time 1086667655, (70,99), root:(71,174),
    mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
    focus YES, state 0

These motion events do not appear when I monitor the mouse devices directly. During the above pointer warp, evtest /dev/input/event2 displayed the following:

Event: time 1345562934.153848, type 3 (EV_ABS), code 1 (ABS_Y), value 48074
Event: time 1345562934.153858, -------------- SYN_REPORT ------------
Event: time 1345562934.281761, type 3 (EV_ABS), code 1 (ABS_Y), value 48137
Event: time 1345562934.281770, -------------- SYN_REPORT ------------
Event: time 1345562934.321750, type 3 (EV_ABS), code 1 (ABS_Y), value 48199
Event: time 1345562934.321769, -------------- SYN_REPORT ------------
Event: time 1345562934.345782, type 3 (EV_ABS), code 1 (ABS_Y), value 48261
Event: time 1345562934.345788, -------------- SYN_REPORT ------------
Event: time 1345562934.521721, type 3 (EV_ABS), code 1 (ABS_Y), value 48324
Event: time 1345562934.521726, -------------- SYN_REPORT ------------
Event: time 1345562943.345890, type 3 (EV_ABS), code 0 (ABS_X), value 49824
Event: time 1345562943.345900, -------------- SYN_REPORT ------------
Event: time 1345562943.369481, type 3 (EV_ABS), code 0 (ABS_X), value 49863
Event: time 1345562943.369491, -------------- SYN_REPORT ------------

Note that the X/Y values adjust smoothly. I also ran evtest on event6 (ImExPS/2 Generic Explorer Mouse) and event1 (VirtualBox USB Tablet) but there were no motion events logged at all while the mouse moved, so this is not caused by a spurious event on the other event devices.

This happens to me on two systems, both of which are Windows 7 64-bit hosts with Linux 3.2 and Xorg 1.12.3. I see this with both VirtualBox 4.1.18 and 4.1.20 on the host side. The guests both use the 4.1.18 additions. I also downgraded to the 4.1.16 additions but that didn't help.

There is nothing out of the ordinary in the VM's log file, and the kernel doesn't log anything when this occurs either.

It seems others have this problem too:

• ​https://bbs.archlinux.org/viewtopic.php?id=145960
• ​https://bbs.archlinux.org/viewtopic.php?id=147035

[blueyy]

I can confirm this bug too: ​https://bbs.archlinux.org/viewtopic.php?pid=1148180#p1148180

I have:

• Host: Windows 7 32b
• Guest: Archlinux (Linux 3.5.3 32b)
• VirtualBox: 4.1.20
• Guest additions: 4.1.20
• Xorg: 1.12.4

[gusnan]

And I can confirm it also on a Linux host:

Host: Debian Squeeze (Linux 2.6.32-5-amd64)
Guest: Debian Unstable (Linux 3.2.0-3-amd64)
Host X.Org X Server 1.7.7
Virtualbox 4.1.20
Guest additions 4.1.20

[PFudd2]

I can confirm it on a MacOS host:

• Host: MacOS 10.6.8
• Guest: Fedora17-KDE spin (Linux 3.5.3-1.fc17.x86_64)
• VirtualBox: 4.1.22
• Guest additions: 4.1.22
• Guest Xorg: xorg-x11-server-Xorg-1.12.3-1.fc17.x86_64.rpm

Just grab a window, move it around in a circle, and you'll see it flicker as the mouse and window jump to the 0,0 origin and back. Other mouse operations are affected too; if I have a window in the top left corner, and try clicking on something in any other window, there's a significant probability that the corner window will be selected as if I had clicked on it. Highlighting text is also an adventure: if the mouse jumps to 0,0 while you're highlighting one word, you'll accidentally highlight the first half of your document.

When I tried the default Fedora17 image with Gnome, the top left corner was a hotspot of some kind, and it was being triggered constantly, which is why I'm on KDE now, and don't put any windows into the top-left corner.

I will not let my users use VirtualBox on any platform until this is fixed.

[vkiwi]

I can confirm on an openSUSE 12.1 Linux host with all of several Linux guests I tried.

Additionally, the mouse scroll wheel is ignored.

This bug makes VB practically unusable with mouse integration turned on. Turning mouse integration off prevents the pointer being active at (0,0) and the scroll wheel works.

Using VirtualBox-4.1-4.1.22_80657_openSUSE114-1.x86_64 rpm from Oracle, with matching guest addition version (also obviously from Oracle).

[vkiwi]

​https://bugzilla.novell.com/show_bug.cgi?id=779421

[Tsso]

Can confirm this on Ubuntu 12.04 host with all updates.

Just get ​Debian Wheezy Beta 2.

amd64: Mouse bug. i386: No mouse bug.

[gusnan]

As I havn't previously tried reproducing this bug using i386 guests - seeing Tsso's post above I just did - and similar to him/her, cannot reproduce on i386. So I confirm that the bug seems to be amd64-specific. (Virtualbox 4.1.22 r80657)

[Sam Morris]

Still present with 4.2.0.

[p0x8]

Linked this ticket to a bug in xf86-input-evdev 2.7 with a proposed workaround: ​https://bugs.freedesktop.org/show_bug.cgi?id=54353

The issue does not seem to be exclusive to VirtualBox. Those in need of a quick fix can try using an earlier version of xf86-input-evdev.

[Sam Morris]

p0x8, you're a legend. The workaround in comment 4 of the fdo bug works for me.

[Michael Thayer]

I take it I can close this then.

[_ioio_]

Using vbox 4.2.4r81684

Confirming bug in :

• Debian squeeze 64 and wheezy 64, tested with Mate desktop and Gnome.
• Linux Mint 14 Nadia 32bits, tested with Cinnamon desktop ( = ubuntu 12.10 )

Distros where bug doesn't appear for me :

• Ubuntu 12.04 64 or 32, tested with unity, gnome3, gnome classic, Mate desktop.
• Linux Mint Debian 64, tested with mate desktop ( which is a debian testing, don't know why bug doestn't appear there ).
• Linux Mint 13 64bit, tested with Mate Desktop.