FS#59091 - [linux] X intermittent input event handling (mostly mouse) inside virtualbox
Attached to Project:
Arch Linux
Opened by Radu Pralea (rpralea) - Wednesday, 20 June 2018, 20:26 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 04 July 2018, 01:30 GMT
Opened by Radu Pralea (rpralea) - Wednesday, 20 June 2018, 20:26 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 04 July 2018, 01:30 GMT
|
Details
Description:
Upgrading Arch guests (VirtualBox) to xorg-server 1.20.0-8 (both Windows and MacOS hosts) intermittent input event handling (mostly mouse clicks, but also pointer position and icon update and sometimes keyboard) Several reports of this issue were already reported on a dedicated mail thread: [arch-general] Upgrade to Linux 4.17.2 & xorg-server 1.20.0-8 breaks left-mouse in remote Linux desktops Doesn't seem to be from libinput (which also received a concomitant update to version 1.11.1-1): despite the windowing system not reacting all mouse events are displayed by libinput debug-events. Using xev for logging X events, the results corresponds to the windowing system erratic behavior: there are no events generated in X by many (most of the) libinput mouse (and sometimes keyboard) events. Additional info: * package version(s): xorg-server 1.20.0-8, libinput 1.11.1-1, linux 4.17.2 Steps to reproduce: Upgrade to latest xorg, libinput, kernel, start an X session in an Arch guest and play around with some windows (starting programs, resizing and moving/dragging windows). Soon the desktop becomes inoperable by mouse. A couple of times keyboard stopped working too (the system was still running fine, it wasn't frozen). Some of the impacted users downgraded xorg-server (or/and xorg-server-common?) or the kernel (to 4.16) and corresponding VirtualBox guest modules to go back to a usable desktop. |
This task depends upon
Closed by Doug Newgard (Scimmia)
Wednesday, 04 July 2018, 01:30 GMT
Reason for closing: Fixed
Additional comments about closing: linux 4.17.4-1
Wednesday, 04 July 2018, 01:30 GMT
Reason for closing: Fixed
Additional comments about closing: linux 4.17.4-1
https://www.virtualbox.org/ticket/17827
My only "workaround" for now: blacklisting vboxguest kernel module.
I virtualize guest so that they are available over my LAN starting each with VBoxManage startvm "VM_name" --type headless. After xorg update there is no way to use the left-mouse button to interface with Linux guests (Win7 guests continue to work fine). Keyboard input seems to work OK (I was able to use up-arrow, down-arrow to exit fluxbox). Console input is fine.
If a window is opened in the remote guest (e.g. xterm), there is no way to left-click and drag to move the window, and clicking on the toolbar controls does nothing.
Prior to xorg 1.20.0-8 (and Linux 4.17.2), this setup has been flawless for years.
Or a fix to get additions to be built against linux 4.17.
But when I tried to build VirtualBox from svn (using virtualbox-svn AUR package), it doesn't build because of QT 5.11.x...
"/home/fred/virtualbox-svn/src/VirtualBox/src/VBox/Frontends/VirtualBox/src/settings/global/UIGlobalSettingsProxy.cpp: In member function 'void UIGlobalSettingsProxy::prepare()':
/home/fred/virtualbox-svn/src/VirtualBox/src/VBox/Frontends/VirtualBox/src/settings/global/UIGlobalSettingsProxy.cpp:215:59: error: invalid use of incomplete type 'class QButtonGroup'
QButtonGroup *pButtonGroup = new QButtonGroup(this);"
Ouch!
https://www.virtualbox.org/ticket/17827
It is looking like a Linux 4.17 issue, as similar problems are reported with openSuSE Tumbleweed with 4.17 and older xorg, and on Ubuntu as well, but it is unclear if there is enough information to rule the kernel, libinput or xorg out.
1. on first login, you get one left-click which still leaves mouse-over events active.
2. if you right-click, you lose left-click and mouse-over events
3. if you use your left-click to open the KDE menu, you can continue forever to use the left-click to open the KDE menu, but right-click and mouse-over are dead.
4. you must use your "bonus" left-click on first login before logging out and back in to get a fully functional desktop. if you boot up into your desktop and immediately use the ACPI Shutdown to force a logout, the left-click issue persists into the next desktop session.
I have log files from the initial login and the subsequent functional logout/login. There is no apparent difference between the Xorg.0.log files and I can see nothing obvious in the other logs.
Also, linux 4.17.3 does not fix this issue.
Another thought - if you have to use one left-click to force a reset on the next session, it seems to me that that first left-click is breaking something that subsequently needs to be reinitialized or reloaded. if you simply logout then login without using your one left-click, the issue persists across desktop sessions until that one left-click is used.
Updated both Arch host and Arch guest to linux-4.17.3-1. Left mouse and focus-follows-mouse is ignored. I can confirm left mouse is active before rt-click but after leaving the window where the left click was used BOTH left-mouse and right-mouse are Inoperative. That is bewildering.
The way I tested was to start Fluxbox and I have the panel set to Auto-Hide. The only way to raise the panel is mouse-over.
When fluxbox start -- if my first motion is to move the mouse over the panel, the panel will raise and I can click with the left-mouse over the triangle to cycle Desktop 1->4.
However as soon as the mouse leaves the panel all Left-Mouse AND Right-Mouse inputs and focus-follows-mouse is lost. I cannot raise the panel a second time, and now, with the Right-mouse lost I cannot access the fluxbox menu.
Thankfully, I can Alt+F2 to bring up fbrun and enter 'sudo systemctl poweroff' to shut the VM down gracefully.
For this test, I started fluxbox, it opened, and while I had not used the mouse I could mouseover and raise the hidden panel, but as soon as I right-clicked to bring up the menu -- the left mouse functionality died. I exiting fluxbox by bringing up the menu with the rt-mouse and then used the arrow-keys to exit fluxbox.
I then restarted fluxbox (I use startx) and on the second starting, the mouse continued to work. I have used the left-mouse, middle-mouse, right-mouse and mouse-wheel (to switch desktops 1->4) and the mouse remained active and working normally.
I can't even venture a guess as to how or why this could occur. It seems too consistent between people reporting to be Undefined Behavior, but on the other hand you could see how some kernel pointer left with an indeterminate value could cause the mouse event/input state to get screwed up as well. This is going to be one that the smart people have to figure out (which will probably end of being the same people responsible for the behavior as well...)
I don't know the mechanism of the focus relationship in the Xorg window System. It seems that there is a "hidden" top-most window that robs the mouse focus at start up. Or, there is a problem with the geometry position calculation . Is it possible that the GUI coordinate offset of the parent process is not set correctly at the beginning ?
My understanding of the Linux system is too elementary, sincerely hope that you archlinux experts find the reason!
No one with the issue has bisected 4.16-4.17 to locate the commit causing the issue which would gain more attention should it be reported to upstream linux.
I doubt very much this is an X issue because if it were, we'd be seeing similar failures on non-virtual platforms as well. And we're not seeing that either.
Perhaps we need to apply some pressure to the open virtualbox bug (the URL for which is listed above) and concentrate on what's happening in the host logs.
@fredbezies are you certain that there is a fix in svn for the issue if you could get it to build with Qt 5.11? Have you tried Using ALA to switch back to Qt 5.10 build from svn and proved that includes a fix?
[1] https://bugs.archlinux.org/task/59091#comment170810
I concede that there may indeed be some other issue of compatibility between virtualbox 5.2.12 and linux 4.17.x, but since the kernel's vboxguest codebase hasn;t changed in any notable way between 4.16.13 and 4.17.3, it's doubtful that the issue is in the vboxguest/vboxvideo kernel extensions. The last Arch release of virtualbox was June 6, and that would have been after at least several days of testing by the Arch team and who knows how long it was tested by the Oracle team before it even made it to Arch testing. Linux 4.17.0 was released June 3. So what version of linux 4.17 was virtualbox 5.2.12 actually tested against? Best case, it had to have been tested/built against a release candidate. So by extension then, what version of linux-headers was virtualbox 5.2.12 built against?
That said, I do hope that the issue comes down to something like the Qt version, although Arch's version of virtualbox 5.2.12 already builds against Qt 5.11.
I'm currently doing a full build of virtualbox 5.2.12 in a fully updated Arch environment. I'll report back on whether that makes any difference.
@tpowa?
@heftig?
Can we get some feedback from someone please?
@loqs This bug has mostly being running under the radar, so what you think should be happening might not be happening. It doesn;t seem to have piqued much interest over at Oracle's Virtualbox site either - they seem to be under the impression that nobody's running the latest versions of anything. Sooner or later, when all distros are running linux 4.17, look out fan... That's when it'll get fixed. Either that or we have to pester the Oracle folks so they'll take notice. Meanwhile, if you want to try a bisection of the kernels, please do. Be aware that about a quarter million lines of code were removed for 4.17, so bisecting 4.16 and 4.17 might return a whole lot more than you want to address.
I did a rebuild of virtualbox and my distro iso, and the problem is still there, so the issue is not related to kernel header file changes. For now, I'm at a loss. Ideas welcome...