Bug 428122 - Broken scrolling behavior of KDE neon when installed in VirtualBox
Summary: Broken scrolling behavior of KDE neon when installed in VirtualBox
Status: RESOLVED UPSTREAM
Alias: None
Product: kwin
Classification: Plasma
Component: libinput (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://www.virtualbox.org/ticket/17270
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-23 07:50 UTC by goebbe
Modified: 2020-10-26 20:17 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description goebbe 2020-10-23 07:50:49 UTC
SUMMARY
When installed inside a VirtualBox, the scrolling behavior in the KDE-environment ist broken. 
Scrolling is interrupted as soon as the mouse pointer moves, which gives a very inconsistent an frustrating scrolling behavior. 

STEPS TO REPRODUCE
1. Install KDE-Neo inside a VirtualBox (e.g. on Ubuntu 20.04) 
2. Open e.g. Discover and try to scroll down the list of updates

OBSERVED RESULT
Scrolling does not work as it should. Actually it is pretty hard to scroll without moving the mouse at all. 


EXPECTED RESULT
Smooth scrolling - like an install outside of VirtualBox

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: KDE neon 5.20 installed in VirtualBox on Ubuntu 20.04
(available in About System)
KDE Plasma Version: 5.20.1
KDE Frameworks Version:  5.75.0
Qt Version: 5.15.0

Workaround: 
Disable the VirtualBox mouse integration via Xinput. 

The following worked for me: 

~$ 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)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse           id=11   [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=10   [slave  keyboard (3)]

~$ xinput disable 9

ADDITIONAL INFORMATION
I had the same experience with older versions of KDE neon, VirtualBox and Ubuntu - so it seems that the problem is not due to a recent regression.

Xfce offers a options in the mouse-setting that allows to disables VirtualBox mouse integration (permanently) - which offers an accessible way to fix the bad scrolling experience when installed inside a VirtualBox. 

The problem seems to be related to VirtualBox mouse integration, and should/could probably fixed there.  :-( 
It would be great is there would be an (GUI) option to disable it.

Please feel free to move the bug report to another component. I had a hard time to decide if this is the correct place (Kwin, libinput) to report the bug. 

Keep up the great work.
Comment 1 goebbe 2020-10-23 08:36:33 UTC
Collecting addidional information on the issue: 

https://forums.virtualbox.org/viewtopic.php?f=3&t=83614#p431647
It seems libinput *ignores* scroll button events from one device while another device sends movement events, which is the case for mouse integration: the virtual touchpad sends (tons of) movement updates, while the virtual ps/2 mouse scrollwheel sends button events. With mouse integration disabled, both events are sent by the same virtual ps/2 mouse. Most notably, both libinput-debug-events and xev receive events correctly in all cases.

This explains why the first workaround (disabling VirtualBox mouse integration) works.

The following points to another workaround: 
https://superuser.com/questions/1270811/inconsistent-and-erratic-mouse-wheel-in-linux-while-moving-the-mouse-pointer

Second workaround - as decribed on superuser.com: 
Replace libinput by xf86-input-evdev in combination with imwheel 

I hope this helps.
Comment 2 Nate Graham 2020-10-26 15:44:33 UTC
Seems like a libinput bug. Please report upstream at https://gitlab.freedesktop.org/libinput/libinput/-/issues/. Thanks!
Comment 3 goebbe 2020-10-26 19:57:53 UTC
This is a reference to the three year old bug report on Virtualbox: 
https://www.virtualbox.org/ticket/17270
Comment 4 goebbe 2020-10-26 20:17:28 UTC
... and a two year old bug report for xf86-input-libinput:
https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/9