Scrolling jumps after scrolling in another application -> Qt issue

[Benjamin ROBIN]

This bug is reproducible very easily with a Linux or Windows host. The application must be written in Qt5 running on a Linux guest.

• Just open a Qt5 application with a scroll bar.
• Scroll to the bottom, the scroll bar may jump randomly to the top.
• When the scroll bar is at the bottom, lose the focus on the window, (select another application...).
• Get the focus back, try the scroll to the bottom by one step, the scroll bar jump to the top, the scroll bar should stay at the bottom.

I initially reported the bug on the Qt side : ​https://bugreports.qt-project.org/browse/QTBUG-42415#comment-263554 But this is a bug on VirtualBox side. VirtualBox does not emulate properly the mouse scroll (XINPUT21).

[Michael Hansen]

It is enough to move the mouse within the widget to reproduce this bug -- you do not even have to switch focus to another application or widget. Only when the mouse is kept perfectly still is scrolling reliable.

[Michael Hansen]

I've also noticed that it affects some GTK3 apps (e.g. gnome-terminal) in a similar but slightly different way: Using the scroll wheel while moving the mouse causes the scrollbar to stay stationary instead of scrolling or jumping around. If the mouse is held still, the scrolling works fine (just as with Qt5 apps).

[Michael Thayer]

Since you and the Qt people seem to have taken a bit of a look at this it would help us greatly if you could tell us exactly what behaviour you expect from VirtualBox which differs from the current behaviour. This could be related to the way in which we report mouse events - the scroll wheel and button events are sent to the guest using the emulated PS/2 device, while position events are sent using a special device - but then again it might not be.

[Hugo Ideler]

I'm experiencing the same thing but in xfce4 (gtk) rather than (only) Qt.

The guest is running Arch Linux with xorg-server 1.17.1-5 and gtk3 3.16.3-2. Guest extensions are enabled.

The host is running VirtualBox 4.3.28. Other (older) guests are not affected.

xinput listing:
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ VirtualBox USB Tablet                   	id=10	[slave  pointer  (2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse         	id=12	[slave  pointer  (2)]
⎜   ↳ VirtualBox mouse integration            	id=9	[slave  pointer  (2)]

[Michael Thayer]

I'm afraid that for now I will not have time to work on this unless someone is able to do the analysis for me. It may help to know though that our Guest Additions do not do anything and the XINPUT level, only at the kernel level. Furthermore, what we do at the kernel level only handles the X/Y position of the mouse pointer and everything related to button and scroll-wheel handling is done by code in the upstream Linux kernel (button and wheel events are sent through the emulated PS/2 device).

[Michael Hansen]

Based on your comment, I found a way to get more info from xinput. I did some debugging on the two emulated devices... I opened some terminals with the following:

# Terminal 1
while true; do xinput query-state 9; done

# Terminal 2
while true; do xinput query-state 12; done

What I observe is that when the position (valuator[0] and valuator[1] reported by device 9) remains constant, the scroll wheel value (valuator[3] reported by device 12) correctly increments or decrements based on scroll wheel events. When the mouse moves (the values in device 9 change), the next scroll wheel event on device 12 will occur as though the previous value were 0 (so the updated value will always either be 1 or -1). On real hardware, there is usually only one mouse device, and its scroll position is retained for the entire X session. So it seems that whatever is resetting this value is what's causing the scroll wheel issues for Qt5 and GTK3. I will try to test two mice on one system if I get a chance, to see which behavior is observed.

[Michael Hansen]

Update: Well, I tried with two USB mice (so both were ValuatorClass Mode=Relative) on real hardware, and both mice properly retained their scroll wheel position despite mouse movement and scrolling on both devices. I don't have any absolute device (i.e. USB tablet) to test this on. I don't know enough about where these values come from to know whether the VirtualBox device emulation or the Xorg drivers are at fault here...

[Michael Thayer]

Did a quick test with xinput and saw what you did. What about passing a USB mouse through to VirtualBox and seeing if you see the same thing with its scroll wheel in combination with the absolute Additions device? You could also try with a physical mouse passed through and the VirtualBox USB tablet emulation (you need to disable the Guest Additions for that to work though).

[Michael Thayer]

Thinking about it it looks to me as though xinput is treating the relative scroll wheel as an absolute value, and resetting it to zero when it gets an absolute event. And Qt is trying to convert the absolute scroll value back to a relative one, and getting a massive jump when it resets. I'm not sure if that is really our problem or not. I would appreciate it if you could get some input from the Qt people about this. In theory I could add a dummy scroll wheel to the pointer integration device to see if that makes a difference, but I am not happy about doing that as it would mean testing a massive number of guest systems to see if it causes any regressions.

[Michael Thayer]

Of course, that is supposing it makes a difference at all.

[Michael Hansen]

How would one go about passing a mouse through to the guest? It seems the UI and VBoxManage tool are (quite reasonably) filtering out things like input devices from their available device lists...

[Michael Hansen]

Ooh, here's something interesting: When disabling the Mouse Integration on the guest, the position starts getting reported by device 12 instead of device 9. Since 9 is no longer being modified, this means that the scroll axis correctly increments and decrements without resetting...

[Michael Thayer]

I don't think we are filtering anything out, it might be host-specific (i.e. Linux/Windows). Any results with the USB tablet emulation which kicks in when you remove the Additions?

[Michael Thayer]

Actually I and another developer were able to pass through a USB mouse on respectively a Linux 4.0rc2 and a Windows 7 host.

[Michael Hansen]

With the additions disabled, I observe that device 9 (still VirtualBox mouse integration) still reports the absolute position, and now device 11 (the new ID for ImExPS/2 Generic Explorer Mouse) reports the buttons and scroll position. Furthermore, like the case of using the GAs for mouse reporting, the scroll position gets reset whenever the mouse position changes. The behavior of disabling mouse integration with the GAs uninstalled is the same as with the GAs installed.

[Michael Hansen]

Ok, the USB device issue was a permission problem with my system (I had forgotten to add myself to the vboxusers group). I have fixed that and got a USB mouse passed through successfully.

I now observe both with and without GAs:

• The physical mouse accurately kept track of its own position across all 3 axes regardless of what the other devices were doing.
• The USB Tablet kept track of its absolute position, but also started reporting scroll position (!). This stayed accurate if the virtual mouse was moved, but would reset whenever the physical USB mouse moved or scrolled.
• The ImExPS/2 device was no longer reporting any scroll position. All 4 of its axes and all of its button values remained fixed.
• When disabling Mouse Integration, the physical mouse would remain accurate on all axes, and the ImExPS/2 device would take over all 3 axes as before. When moving the physical mouse, the scroll position on the PS/2 device would be reset, but moving the PS/2 device would not reset the physical mouse's scroll position.

[Michael Thayer]

I talked to upstream about this. It seems that Qt may be using XINPUT wrongly:

"the valuators are device-specific, so whenever the phys. device changes, the valuators are copied to the master device (so the master changes appearance based on what the current device is*). so when you scroll on one device, then on the other you'll get a device changed event and the client should adjust it's knowledge of the device based on that info. the two devices may have completely different interpretations on what "one scroll unit" means, so even without the reset the client would likely be doing something wrong anyway.

[...]

* big design mistake, but that's what we're stuck with now."

[Michael Thayer]

I will assume for now that this is a Qt bug and close this ticket. Please re-open if you have reason to believe that that is wrong (if possible with input from the Qt people).

[Michael Hansen]

Just because there is also a Qt bug does not mean that VirtualBox is behaving properly. Yes, I agree that Qt should also fix their issue, but as pointed out earlier in the thread, the scroll wheel value resetting affects more than just Qt5. It just happens that Qt5's defect makes the problem more obvious.

[Michael Thayer]

If you have a strong feeling that this is something specific to VirtualBox, would you be able to try the following: set up qemu/kvm on your Linux host with a similar guest, enable the emulated USB tablet device and pass through a USB mouse to the virtual maching (I gather you have at least two available from your comments above) and check that the results are different? That would be great.

[Michael Hansen]

It does appear that qemu's USB tablet also exhibits resetting of the scroll wheel axis, even without any other pointer devices attached, albeit not quite as frequently as it did with VirtualBox.

EDIT: The issue was also apparently seen with real touch devices, according to a related Qt bug report (QTBUG-40829). So I'm more comfortable that VirtualBox is at least consistent with real hardware, and that the bug lies elsewhere. Thanks for helping to investigate.