Problems With Mouse Scroll Wheel When Using Guest Additions

[mongorian]

Here is some backgroud -- skip to the next paragraph for the meat of the problem. I have been fighting an issue with the mouse scroll wheel in (KDE based) Linux guests for quite some time now. It seemed to surface for me with the Fedora 22 release (possibly due to the KDE version included there). This issue does not occur in prior versions of the OS (such as Fedora 21), but does occur consistently in every version since (up through the current, Fedora 24). I had written this off to be solely an OS or desktop (KDE) issue, which is why I had not brought it here for help yet. However, I did some additional testing recently which has convinced me that this at least partially lies on the VirtualBox side. I took some time recently to to install a VirtualBox guest OpenSUSE KDE system and it encountered the exact same symptoms as the Fedora system. Then I took the (extensive) time to setup and configure an ArchLinux KDE system, and it too experienced the same symptoms. The final test that led me to post here was to load up a clean Fedora 24 KDE guest system and leave Guest Additions uninstalled temporarily -- this eliminated the symptoms entirely.

Let me explain the problem and how to replicate...

Issue:
On a (KDE) Linux guest system with VirtualBox Guest Additions installed the mouse wheel scroll works erratically in certain applications. Whether scrolling up or down, in an OS based window (such as Konsole or the KDE "start" menus), the scrolling is inconsistent and erratic. It will seem to work correctly for a moment and then will begin to miss input (or misinterpret it), going partially unresponsive and/or scrolling tiny amounts at a time (less than a line worth). The mouse scroll settings are at their OS default of 3 lines per scroll - nothing changed from a default installation. However, when leaving the Guest Additions pacakge uninstalled, the mouse wheel scrolling works perfectly normal across all KDE apps.

Workaround:
The one "workaround" I've found that seems to temporarily cause the scrolling to work correctly is to hover the mouse pointer directly over the scroll bar itself for an affected window (instead of the inner window area) and then scroll while holding the mouse pointer there. When hovering the mouse pointer directly over the window's scroll bar AND simultaneously rolling the mouse wheel, it scrolls the correct amount consistently. Any time the mouse pointer is moved anywhere else in that window the scroll wheel action turns erratic again.

Replication:
This issue is easily reproducible, 100% of the time for me, on two separate host systems (one Windows 7 corporate laptop, and one Windows 10 desktop), using all latest versions of VirtualBox with Guest Additions installed. Here are the steps to replicate:

- Load and update a current copy of Fedora or OpenSUSE with the KDE desktop.
- Perform installation of most current VritualBox Guest Additions and recycle guest system.
- Launch Konsole and run the following command: ls -l /dev
- Within that Konsole window attempt to use the mouse wheel to scroll up through the resulting list of /dev files and observe erratic scrolling activity.

The erratic mouse wheel scrolling can also be observed in the KDE "start" menu, under categories like "Internet" that have enough items to enable a scroll bar. It also seems to occur within apps like Dolphin and the KDE System Settings window. This erratic behavior does not occur in apps like Firefox though.


Again, leaving the Guest Additions package uninstalled completely eliminates this undesired erratic behavior, but obviously leaves important functions like auto-resize guest completely unavailable. These features are critical to my use-case scenario for VirtualBox, so this really is a show stopper for me.

As stated above, this has been tested against every public release of VirtualBox since the behavior initially presented, up through 5.1.2. The log files do not seem to have any relevant information in them, but I have attached the most recent copies anyway for reference. Let me know if anything there's anything else helpful I can provide here.

EDIT: Ok, I'm not seeing any activity on this. These forums are usually very quick to respond. Has anyone tried to replicate this issue at least? I would love it if somebody could at least confirm what I am seeing, so I know I'm not going crazy. Should I have posted this in the "VirtualBox on Windows Hosts" sub instead of in "Linux Guests" maybe? Any help or ideas is greatly appreciated.

[mongorian]

Anything? Anyone?

[TopTom]

I have the exact issue you have described. I have moved from 5.0.26 to 5.1.4 with the same issue. The only thing I would note is that my scroll wheel works fine if I disable the "Mouse Integration". Besides just being a bit of a hassle, this creates a 2nd issue, at least in full-screen mode, where the desktop mouse moves invisibly with the virtualbox mouse, occasionally reaching the top of the screen causing the VB dropdown menu to appear and temporarily disabling the VB mouse pointer. I have to move the mouse around to get the dropdown to go away and regain control of the virtual mouse.

I have been trying everything I can think of to leave the mouse integration enabled and use the scroll wheel, but it's just too erratic.

[mongorian]

Thanks for the reply! I had not tried disabling mouse integration yet, but that seems to correct this specific issue as well. I use my virtual machines in Seamless mode though, and disabling mouse integration with seamless mode causes a bunch of other strange mouse behavior, and requires frequent (if not constant) use of the "host key" to break the focus of the mouse away from the guest windows. Even then, it makes using the two systems together extremely difficult. I would say that, for my use case at least, usability suffers even more with mouse integration disabled than it does with the erratic mouse wheel scrolling present.

This is an interesting test though, and seems to prove even further that the issue here lies (somehow) with the guest additions module, since the mouse integration functions are a component of them. I am disappointed that nobody else seems interested in fixing this problem. I guess maybe it's time to cross-post this over to the Windows hosts forum to see if we get any more action over there. Thanks again for confirming this issue.

[mzt50]

I experience almost the same issue with different mice on the most recent versions of all major distribs, I've tried Ubuntu 16 and 17, Debian Stretch RC3, Fedora 25, Kubuntu, Netrunner and Manjaro 17.

The issue can be reproduced only if you move a mouse cursor while scrolling, then the scroll events just don't register in any DE windows.

It's obviously not VirtualBox problem tho, because I see the same behaviour in VMWare.

The only up-to-date distribution that doesn't have this problem is Mint 18.1, and that's interesting because it based on Ubuntu 16 which has this issue.

[Watter]

mzt50 - Holy cow, that's it! You finally figured out how to reproduce my issue. This has been driving me bonkers! Somehow the mouse controllers are not able to process simultaneous events and movement takes precedence over scrolling.

I don't know if this will be useful to others, but if I connect my USB mouse directly to the guest (i.e. it's disconnected from the host), then the issues go away. 'lsusb' shows a new device in addition to the VMware Virtual Mouse (yes, using VMware after VirtualBox had the same issue). At this point, everything works fine. I have no idea why Mint 18.1 would work. If the issue is in the Virtual Mouse driver, then one would think it would be everywhere.

This is a complete blocker for me. My company requires windows on our laptops but I need linux to do my work so my virtual machine is actually my primary workspace. I'm using my linux VM fullscreen 95% of the day and this mouse behavior is on the verge of making me throw my laptop out the window. I'm seriously considering having two mice on my desktop; one for the linux vm and one for Windows when I switch back, but the ridiculousness of that proposition is holding me back for the moment.

This should work, for goodness sake!

[Watter]

mzt50, your post had some nice clues. Do you know what "might" be different about Mint 18.1 compared to many of the other distro's you tried? Wayland. Mint made the decision, for better or worse, to have a VERY stable base and they haven't moved to Wayland. Fedora 25 definitely has, Manjaro (due to Arch base) has. I'm betting the others on your list have as well.

Unfortunately, I'm not a linux tech-capable enough to really investigate this theory, but perhaps someone else who runs across this will be.

[Martin]

With Fedora there should be an easy way to test. It let's you chose running with or without Wayland on the login screen.

[Watter]

So, I'm using this forum thread as a tracker for this issue as it's the only place I've found ANY information related to the issue. Some additional findings:

I'm using an Arch VM with Plasma 5 (KDE) as the DE. libinput appears to have 4 different devices installed for the mouse.

Code: Select all   Expand viewCollapse view

mwelch@archvm ~ $ xinput --list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VirtualPS/2 VMware VMMouse                id=8    [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=11   [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=10   [slave  pointer  (2)]
⎜   ↳ VirtualPS/2 VMware VMMouse                id=9    [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=7    [slave  keyboard (3)]


Again, I apologize for throwing VMWare information into a VirtualBox forum, but I'm hopeful that this will be generally helpful and I can eventually go back to VirtualBox, my preferred VM Manager, however, the above 4 inputs is likely due to my adding the following lines to the .vmx file in an earlier attempt to fix this scrolling issue:

Code: Select all   Expand viewCollapse view

mouse.vusb.enable = "TRUE"
mouse.vusb.useBasicMouse = "FALSE"
usb.generic.allowHID = "TRUE"


In any case, I can safely disable the PS/2 devices. What's interesting, and perhaps irrelevant, is that the mouse functionality is apparently split between the two USB devices. One registers motion events and the other button (and the wheel is a button) events. I thought that perhaps this dual device with different event capturing might be relevant, but perhaps not. According to "xinput --test" on the device that registers button presses, the mousewheel events ARE coming through to the system while the mouse is moving. So where are they getting dropped?

[Watter]

Well, I'm dumb.

I could have sworn the rolling nature of Arch meant I was using Wayland, but no, it X11.

Back to square one.

[Watter]

So.... I installed Mint (KDE) 18.2 in a new VM. Guess what. The problem (losing mouse wheel scroll when the mouse is moving) DOESN't occur in Chrome (or Firefox, I think) but DOES occur in system applications like Dolphin and Kate. It's 100% reproducible. That said, this is still a much better place than the alternative in Arch or other distros I tried. 90% of the scrolling I do is in the browser so, I'll take it.

[mprowe]

I'm afraid I don't think that I can contribute much to a solution here.
Apart from reporting that I too am suffering from this problem.
I am using VirtualBox 5.2.26 (no problems before this) on openSuSE 42.2 & 42.3 hosts and openSuSE 4.2.3, 4.2.2 & Windows 10 guests.
All the above (no Guest Additions, turn off Mouse Integration or add a second mouse and attach via Devices | USB ) workarounds ameliorate the problem but are not a solution.

I look forward to a solution....

Regards, Martin

[WombatFromHell]

I registered an account on this forum just so I could share a solution that seems to work for both Virtualbox and VMware. Basically, the problem is related to a bug in libinput, and switching the pointer driver to evdev is seemingly the only solution.

To workaround this you'll need to install the evdev driver (it's named different things in different distro's, google the package name and double check that it's installed before continuing) and change the file /usr/share/X11/xorg.conf.d/40-libinput.conf (it may be named slightly different depending on your distro). There's a section that looks something like the following:

Code: Select all   Expand viewCollapse view

Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection


Just change

Code: Select all   Expand viewCollapse view

Driver "libinput"

to

Code: Select all   Expand viewCollapse view

Driver "evdev"

Save the file, and restart your DM (or reboot the guest). Your mousewheel should now work, and if you do an xinput list-props on the vmmouse devices you should see them report with evdev device options.

I hope this helps anyone else that might have issues with this bug.

(Edit: If you're running VMware (this shouldn't be necessary with VirtualBox) as your host you may also need to add the following to your guest's vmx config:)

Code: Select all   Expand viewCollapse view

mouse.vusb.enable = "TRUE"
mouse.vusb.useBasicMouse = "FALSE"
usb.generic.allowHID = "TRUE"


(Edit2: If you still have issues, you may want to double check that you're not running in a Wayland instance (Xorg generally works better for guests anyway). In addition, you may want to combine the evdev workaround with using imwheel to control the speed of scrolling in whatever arbitrary windows you prefer. Besides imwheel there's no other known way to control mouse scrolling speed inside a guest that I've found.)

[mprowe]

Basically, the problem is related to a bug in libinput, and switching the pointer driver to evdev is seemingly the only solution.

Hi WombatFromHell,
Thank you for the advice. May I check which "side of the silicone" you are referring too? Should I be changing the mouse driver from libinput to evdev on the host or guest side?

I made the assumption that it should be on the guest. So I have checked that I have evdev installed. For me (SuSE Leap 42.x), it is in the xf86-input-evdev package.
Then following suggestions from the awfully clever folk over at the openSuSE forum, I have overridden the libinput driver in /etc/X11/xorg.conf.d by renaming 10-evdev.conf to 80-evdev.conf.

I have verified that the driver is now evdev with this:

Code: Select all   Expand viewCollapse view

linux-a6cr:~ # grep "Using input" /var/log/Xorg.0.log
[    39.580] (II) Using input driver 'evdev' for 'Power Button'
[    39.614] (II) Using input driver 'evdev' for 'Sleep Button'
[    39.615] (II) Using input driver 'evdev' for 'Video Bus'
[    39.616] (II) Using input driver 'evdev' for 'VirtualBox mouse integration'
[    39.617] (II) Using input driver 'evdev' for 'AT Translated Set 2 keyboard'
[    39.618] (II) Using input driver 'evdev' for 'ImExPS/2 Generic Explorer Mouse'
linux-a6cr:~ #

However, you guessed it, it has not worked for me. Can you offer any pointers on what I may have missed.

Best regards, Martin

[WombatFromHell]

The 'secret sauce' so to speak is using imwheel along with the evdev driver (haven't tested against imwheel + libinput).

Essentially it should be added as a startup application with a command line like: imwheel -b 45 so it only intercepts the scrollwheel to avoid causing issues.

There's also a good writeup on the .imwheelrc and how to add WM_Class entries at: https://wiki.archlinux.org/index.php/Imwheel.

Note that some distributions require compiling imwheel (like Fedora 24+).