Mouse wheel stops working after a while -> fixed as of 25 Apr 2013, 4.2 and later

[Sam Morris]

The wheel of my USB mouse can be used inside my guest (Linux 2.6.32) after I boot the VM, but after a while it stops working.

On examining the mouse events with xev, when I scroll the wheel, mouse events _are_ being generated, but they are for buttons 6/7 (sideways scrolling)!

If I run xev before the wheel stops working, the events are generated for the correct buttons (4/5).

Disabling mouse integration does not help.

evtest also reports that buttons 6/7 are being pressed, so this does not appear to be a configuration issue: $ sudo evtest event4 Input driver version is 1.0.0 Input device ID: bus 0x11 vendor 0x2 product 0x6 version 0x0 Input device name: "ImExPS/2 Generic Explorer Mouse" Supported events:

Event type 0 (Sync) Event type 1 (Key)

Event code 272 (LeftBtn) Event code 273 (RightBtn) Event code 274 (MiddleBtn) Event code 275 (SideBtn) Event code 276 (ExtraBtn)

Event type 2 (Relative)

Event code 0 (X) Event code 1 (Y) Event code 6 (HWheel) Event code 8 (Wheel)

Testing ... (interrupt to exit) Event: time 1265938318.197278, type 2 (Relative), code 6 (HWheel), value -1 Event: time 1265938318.197291, -------------- Report Sync ------------ Event: time 1265938318.709651, type 2 (Relative), code 6 (HWheel), value 1 Event: time 1265938318.709664, -------------- Report Sync ------------

Interestingly, if I actually trigger my mouse's horizontal scrolling feature, no events are passed into the VM. The mouse works fine in the host OS however (Vista Home Basic SP1).

[Sam Morris]

That evtest output but formatted better:

Input driver version is 1.0.0
Input device ID: bus 0x11 vendor 0x2 product 0x6 version 0x0
Input device name: "ImExPS/2 Generic Explorer Mouse"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
    Event code 273 (RightBtn)
    Event code 274 (MiddleBtn)
    Event code 275 (SideBtn)
    Event code 276 (ExtraBtn)
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
    Event code 6 (HWheel)
    Event code 8 (Wheel)
Testing ... (interrupt to exit)
Event: time 1265938318.197278, type 2 (Relative), code 6 (HWheel), value -1
Event: time 1265938318.197291, -------------- Report Sync ------------
Event: time 1265938318.709651, type 2 (Relative), code 6 (HWheel), value 1
Event: time 1265938318.709664, -------------- Report Sync ------------

[Sam Morris]

This seems to be caused by VirtualBox grabbing the Alt key in the host. If it happens then I can fix it by switching out of VB to the host, and pressing and then releasing the Alt key.

[Sam Morris]

I can now reproduce this at will with the following sequence of operations:

1. Switch out of VirtualBox to another program
2. Hold down Alt key
3. Click of VirtualBox window
4. Observe that the scroll wheel has stopped working

[ratius]

Confirmed here too, exact same problem. I use the Super key as the Host key, the alt key for desktop switching in Win7 (using dexpot). I am on Windows 7 as host, did that to me on Ubuntu 9.10 and now 10.04 LTS. The alt key modifier seems to be the problem. Vertical scrolling becomes horizontal. When this happens, the host key must be pressed then the alt key pressed again and the vbox window must be manually clicked again. Using the alt button for desktop switching to drop onto a full screen vbox window will screw up the scrolling.

[TBS]

I have experienced the same issue "mouse wheel stops working in virtualbox guest but still works in host. I read about what you described "the alt button is stuck". So I went into the host and clicked alt button a couple of times.

Clicking the alt button a couple of times seems to "unstick" the button for the guest. And now my guest VM mousewheel works again! Thank you for the very skilled debugging! You get lots of props from me.

(FYI, this same bug affects my host b/c i couldn't press the windows key.)

[TBS]

A possible related bug, sometimes my CTRL button gets stuck in the host. The solution is that I have to enter the host and tap the CTRL button a couple times. And then I can do things again in the host properly.

[hamelg]

I encounter this issue when using a virtual desktop manager like ​http://virtuawin.sourceforge.net/ or ​http://www.dexpot.de/

When I start my VM, the buttons 4 and 5 are mapped at the correct place. If I switch the current viewport to another desktop, then switch back to my VM, the buttons 4 and 5 become 6 and 7. Then, I see this kernel message :

atkbd serio0: Spurious NAK on isa0060/serio0. Some program might be trying access hardware directly.

To rebind mouse buttons at the right place, I must minimize the guest VM window, switch to another desktop, switch back to the desktop, and de-iconify the VM window.

A workaround is to map the button 6 and 7 to 4 and 5 with this parameter in xorg.conf : Option "ButtonMapping" "1 2 3 4 5 4 5"

[Dmitry L.]

Reproduced with VirtualBox 4.1.10 r76836, Guest: Ubuntu 10.04 x64, Host: Windows 7 x64

Workaround from comment:4 works for me

[Michael Thayer]

Ticket #11737 has been marked a duplicate of this one.

I have uploaded a test build which contains a fix which may possibly fix this issue.

​http://www.virtualbox.org/download/testcase/VirtualBox-4.2.13-85236-Win.exe

[Sam Morris]

Replying to michael:

I have uploaded a test build which contains a fix which may possibly fix this issue.

Fix confirmed--for both the mouse scroll wheel and keyboard modifier keys. Many thanks!

(BTW, I'm the submitter--I never got round to asking to have my bug tracker accounts merged)

[Michael Thayer]

Thanks for the feedback, I will close this ticket.

[Sam Morris]

FYI, I noticed that my caps lock and num lock keyboard lights stopped responding to changes in caps lock/num lock status while running your test build. With 4.2.12 they worked as normal.

[Frank Mehnert]

Fix is part of VBox 4.2.14.