Incorrect X11 Button Event Sequence when Application Runs under Unity

Bug #1144560 reported by Dominik Röttsches
This bug report is a duplicate of:  Bug #1068994: button1 gets stuck after a while. Edit Remove
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Unity
New
Undecided
Unassigned

Bug Description

Unity's gesture recognition seems to interfere with the expected event sequence that applications see when listening to button events from the X server.
This happens when a "1) finger on screen, (no movement), finger lifted (in short succession) 2) finger on screen (no movement), finger lifted" sequence is played back using evemu-play. (or the same is perfomed on screen)

Running a simple GTK application that receives button press and release events on its main window reports a double "ButtonPress" at the end of the event sequence. These spurious events seem to originate from somewhere in unity or its gesture detection layers below.

Running the same application under an alternative window manager, or disabling the unityshell plugin in compiz leads to a normal event sequence, same for commenting out InitGesturesSupport() in unityshell code and rebuilding the package.

This can be reproduced with the gtk test app that I am attaching, moving it to the top left corner of your screen so that the replayed touch events hit this window's surface, plus replaying the attached evemu sequence using something like:
$ sudo evemu-play /dev/input/event4 < buggyTapShort.event
where /dev/input/event4 is your touch screen device or a virtual input device set up using evemu-device.

The event sequence was originally recorded from a (multi)touchscreen using the hid_multitouch kernel driver.

The resulting output looks like this:
$ ./gtkmt
ButtonPress, Timestamp: 5178071
ButtonRelease, Timestamp: 5178111
ButtonPress, Timestamp: 5178499
ButtonRelease, Timestamp: 5178567
ButtonPress, Timestamp: 5178499
ButtonPress, Timestamp: 5178499

We see two extra ButtonPress events, interestingly with exactly the same timestamp as the second touch event, whereas - looking at the BuggyTapShort.event sequence - there should clearly only be two touch Press and Release events, that match each other.

My current working hypothesis is that unity's gesture recognition decides to somehow replay those events.

Revision history for this message
Dominik Röttsches (drott) wrote :
description: updated
Revision history for this message
Dominik Röttsches (drott) wrote :
description: updated
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

Likely a duplicate (or same cause) of bug 1068994

Revision history for this message
Daniel d'Andrada (dandrader) wrote :
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

If if works when you don't use Unity or comment out unity's gesture stuff is probably because you're removing window manager's use of X11 Touch events. Mixing subscriptions of X11 Touch and Mouse events in the window manager causes quite complex interactions and problems in the xserver.

Revision history for this message
Dominik Röttsches (drott) wrote :

Thanks, Daniel! Bug 1068994 does look like same cause. Also, your explanation seems like a good fit for what I've been observing. I'll keep an eye on the related bugs and will try experimental packages.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.