Comment 0 for bug 1144560

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

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

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