In order to make the horizontal scrolling work, I had to remap the mouse buttons. Check the mapping using xmodmap -pp:
[sly@SlyLap ~]$ xmodmap -pp
There are 24 pointer buttons defined.
Physical Button
Button Code
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8
9 9
10 10
11 11
12 12
13 13
14 14
15 15
16 16
17 17
18 18
19 19
20 20
21 21
22 22
23 23
24 24
Use xev to find out the button codes for horizontal scrolling:
[sly@SlyLap ~]$ xev
...
ButtonPress event, serial 29, synthetic NO, window 0x5400001,
root 0xad, subw 0x5400002, time 173143560, (21,37), root:(25,493),
state 0x0, button 8, same_screen YES
...
ButtonPress event, serial 29, synthetic NO, window 0x5400001,
root 0xad, subw 0x5400002, time 173126732, (21,37), root:(25,493),
state 0x0, button 9, same_screen YES
From here I can see the left/right button codes are 8/9. Since the synaptics driver uses the buttons 6/7 for left/right scrolling, I simply needed to swap the order of how the buttons are declared. To change the mapping:
xmodmap -e "pointer = 1 2 3 4 5 8 9 6 7 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"
This will swap 8/9 6/7 which will make the horizontal scrolling work.
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).
Best Answer
This answer is specific to Logitech devices with Unifying receiver, but you're mentioning one explicitely in your question.
Install
solaar, a tool which can be used to pair devices with the unifying receiver, but also provides basic device configuration (and status information like battery level). Select the mouse, disable "Smooth Scrolling".