It happens on Ubuntu running on laptop with a touchscreen. Scenario: - There's a small window whose client called XISelectEvents on it for the touchscreen slave device with mask=XI_TouchBegin|XI_TouchUpdate|XI_TouchEnd (client[5290, /usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene qml-demo-minimal-client.qml] in the logs). - compiz and nautilus (which handles the desktop background) have selections and/or grabs on the master device Actions: 1- user taps the qmlscene window. Touch events are reported to both qmlscene (from the slave device) and to compiz (from the master device). compiz rejects the touch sequence and it's not delivered to anyone else 2- user now presses on the desktop background. TouchBegin, TouchOwnership and further TouchUpdates are sent to compiz. 3- compiz rejects the touch sequence. TouchPuntToNextOwner fails to emulate a pointer and pass it to nautilus as it still thinks that touch 1 is active. And as per pointer emulation rules, only the oldest active touch is used for touch emulation. From the logs, the lines are: """ [ 9223.917] (II) TouchPuntToNextOwner: touch 2 [ 9223.917] (II) - Not all older pointer emulated touches have been seen yet. Oldest touch(client_id=1, active=1, pending_finish=0, emulate_pointer=1). """ 4- user lifts his finger So that scenario on touch 1 clearly left xserver in an inconsistent, buggy, state.
Created attachment 98564 [details] Xorg.log with detailed input event handling info
Created attachment 98565 [details] A filtered Xorg.log with only the interesting parts
Created attachment 98566 [details] output of xinput
Created attachment 98567 [details] output of xwininfo showing the whole window tree
For reference, those were the steps I took when recording the log - started lightdm (and threfore X) - logged in - launched the Qt app (qmlscene) - tapped on the qmlscene window - tapped on the desktop background (nautilus) - closed the Qt app (qmlscene) - stopped lightdm (and threfore X)
Created attachment 98629 [details] [review] xorg-integration-tests testcase I think this reproduces the bug quite well, does this match your logs?
Comment on attachment 98629 [details] [review] xorg-integration-tests testcase Woops, test is broken, the way it was written probably doesn't reproduce this bug. Although I believe it probably matches the description of the bug. Maybe missing something?
Created attachment 98694 [details] [review] xorg-integration-tests testcase try 2 Ok so I've finally isolated the problem. The problem is the XIGrabDevice on the slave pointer, which is only removed after the touch ends. When this happens the ButtonRelease call for pointer emulation is never generated, leading to the 'stuck button' bug. Modifying qt to listen to touch events on the master fixes it and removes the need for the XIGrabDevice call. The grab was originally done to prevent pointer emulation events, but these won't get generated when we listen for touch events on the master, solving both problems. But this is still a bug in xorg-server, regardless. :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/569.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.