Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines
Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines
Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#59091 - X intermittent input event handling (mostly mouse) after xorg-server and libinput upgrade
Attached to Project:
Arch Linux
Opened by Radu Pralea (rpralea) - Wednesday, 20 June 2018, 20:26 GMT
Opened by Radu Pralea (rpralea) - Wednesday, 20 June 2018, 20:26 GMT
|
DetailsDescription:
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
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.