5

I have been searching awhile before asking my question here, but still cannot find any answer.

I have noticed that mouse scrolling is generally poorly handled on Linux (maybe just Gnome tho).

I am running my Fedora 28 on a VirtualBox VM, under a Windows 10 host. I noticed that scrolling using mouse wheel works perfectly when mouse is immobile, but whenever I start moving it, scroll doesn't work at all until mouse gets immobile again.

Does any of you know how to make it work even while moving the mouse ? Am I missing some configuration or something ?

I must confess I am not a solid Linux user and I don't know much about peripherals configuration.

5
  • 1
    I don't seem to have that problem in fedora. – pro neon May 27 '18 at 13:43
  • Hi, thanks for your answer. I obviously forgot to mention I am under a VM on a Win10 host. – Vincent C. Jun 26 '18 at 14:08
  • I also run some Fedora VMs under W10 and do not have this problem, but I also do not use Gnome 3, so you can try another DE if you do not have to use Gnome 3. – ajeh Jun 26 '18 at 14:52
  • Thanks @ajeh, I'll try another one and report if it works better. – Vincent C. Jul 4 '18 at 8:09
  • I noticed this the first time back in the days of the free VMware Server 2.0 with some Gnome 2 Linux. It happens to me now on many Windows computers, both with VMware and VirtualBox, also with Mate, Unity or KDE. – foxx1337 Feb 4 '19 at 9:28
1

I discovered this thread https://bbs.archlinux.org/viewtopic.php?id=223470

Basically if I run xev | grep -e "ButtonPress" -e "ButtonRelease" and move the mouse over the window while scrolling I can clearly see the events, which means it's a desktop environment / window manager problem.

People discussing more about the issue here https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/issues/9

If I simply launch firefox from a terminal, I experience scroll events being ignored while moving the mouse, but if I do instead a GDK_CORE_DEVICE_EVENTS=1 firefox then everything works as expected.

The thread at https://forums.virtualbox.org/viewtopic.php?f=3&t=79002&start=15 contains a more interesting reply from a bugmenot user:

Running xinput should show the devices X believes are sending events:

$ xinput 
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VirtualBox mouse integration              id=9    [slave  pointer  (2)]
⎜   ↳ VirtualBox USB Tablet                     id=10   [slave  pointer  (2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse           id=12   [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)]
    ↳ Sleep Button                              id=7    [slave  keyboard (3)]
    ↳ Video Bus                                 id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]

Apparently mouse events are divided between the VirtualBox mouse integration and the VirtualBox USB Tablet device. One of them receives the movement events while the other the scroll events. In some applications once a source of events becomes active, the other one is ignored.

The solution is to disable VirtualBox mouse integration (id=9 in my listing above) either temporarily with

xinput disable 9

or completely by adding a file, for example /usr/share/X11/xorg.conf.d/50-vbox-mouse-fix.conf:

Section "InputClass"
        Identifier "Fix VBox scroll wheel"
        MatchProduct "VirtualBox mouse integration"
        Option "Ignore" "on"
EndSection

(the MatchProduct directive is exactly the string output from xinput).

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.