After the freeze, I can see that when I move the finger on the trackpad :

$ sudo evtest /dev/input/event18
...
Event: time 1431295178.297416, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1803
Event: time 1431295178.297416, -------------- EV_SYN ------------
Event: time 1431295178.307882, type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 2
Event: time 1431295178.307882, -------------- EV_SYN ------------
Event: time 1431295178.308671, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 182
Event: time 1431295178.308671, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1800
Event: time 1431295178.308671, -------------- EV_SYN ------------
Event: time 1431295178.319917, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 168
Event: time 1431295178.319917, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 248
Event: time 1431295178.319917, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1797
Event: time 1431295178.319917, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value -1146
Event: time 1431295178.319917, -------------- EV_SYN ------------
Event: time 1431295178.331171, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 180
Event: time 1431295178.331171, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 256
Event: time 1431295178.331171, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1795
Event: time 1431295178.331171, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value -1145
Event: time 1431295178.331171, -------------- EV_SYN ------------
Event: time 1431295178.341204, type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 2
Event: time 1431295178.341204, -------------- EV_SYN ------------
Event: time 1431295178.342452, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 0
Event: time 1431295178.342452, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 0
Event: time 1431295178.342452, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1794
Event: time 1431295178.342452, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value -1144
Event: time 1431295178.342452, -------------- EV_SYN ------------
Event: time 1431295178.353655, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1431295178.353655, type 1 (EV_KEY), code 333 (BTN_TOOL_DOUBLETAP), value 1
Event: time 1431295178.353655, type 1 (EV_KEY), code 334 (BTN_TOOL_TRIPLETAP), value 0
Event: time 1431295178.353655, -------------- EV_SYN ------------

Created attachment 115673 [details]
This is evtest output when I click with three finger

This is evtest output when I click with three finger

sorry for the delay, this one slipped through. can you please attach an evemu recording instead of the evtest, that one can be replayed locally to reproduce the issue.

What's your kernel version btw?


also - you get repeat events for your button, I've never seen that before... wonder what's going on there.

Created attachment 119552 [details]
evemu-record session for a single finger tap

Created attachment 119553 [details]
evemu-record session for a double finger tap

Created attachment 119554 [details]
evemu-record session for a triple finger tap

Created attachment 119555 [details]
evemu-record session for a quad finger tap

I just got me one of these things and was bitten by this bug the moment I pointed more than two fingers at it. Attached are four evemu-record sessions, one each for a single/double/triple/quad finger tap (and only a tap, no more interaction) on the device. The triple and quad taps behave oddly, with 'phantom' events firing after seemingly random delays. As soon as this happens, the device becomes inoperable (ie. can not be used to move cursor etc) for a random amount of time. Eventually something seems to sync up again and the device starts responding again.

Tests performed on current Debian/Sid:

Linux ouroboros 4.2.0-1-amd64 #1 SMP Debian 4.2.5-1 (2015-10-27) x86_64 GNU/Linux
X.Org X Server 1.17.3
Release Date: 2015-10-26

honestly, this looks like either a kernel bug or some hw issue. Something is losing track of the touches.

The single-finger tap recording has a BTN_TOOL_DOUBLETAP 0 event which is the event for "from 2 fingers down to 1 finger". It's also missing the initial set of events so if you started evemu-record when the touchpad was in a physically neutral position (i.e. you didn't touch it) then kernel/hw lost track of the touchpoints earlier on.

Same for the double tap sequence, it has a transition from tripletap to doubletap at the end and remains there (i.e. at the end of the recording the touchpad logically still has 2 fingers down). The triple tap sequence returns from quinttap to quadtap at the end, so 4 fingers still logically down.

Now, the interesting thing is that the touchpad supports 16 slots (individually tracked fingers) and each recording has the expected number of slots changing as you move your fingers, but the BTN_TOOL_* are out of whack. And they're the ones that we rely on in synaptics for multifinger interaction.
The slot numbers used are strange though and indicate that some slots weren't terminated earlier - that could cause the kernel to be out of whack for the BTN_TOOL_* events.

Punting this to benjamin, maybe he's aware of something in the kernel that could be the cause of this.

libinput uses the actual slot values btw, so I think using that would paper over this bug if it gets too annoying.

The recordings are from a 'clean' state, ie. no fingers down at the moment evemu-record was started, but the pad had been in use before. I'll attach a recording made directly after issuing an hci reset (hciconfig hci0 reset) for comparison.

Created attachment 119561 [details]
evemu-record session for a triple finger tap (first interaction after hci reset)

At timestamp 152.117283 I got tired of seeing all those 'EV_KEY / BTN_TOOL_TRIPLETAP   2' events fly by so I issued another hci reset (hciconfig hci0 reset) to stop the flow.

If the only reports for this problem come from users of this device (and possibly the related Apple 'magic mouse, I suspect the bug to live in its driver (drivers/hid/hid-magicmouse.c). After all, there are other multi-touch trackpads around.

There seem be some assumptions in the driver which might be related to this issue, eg. the bit masks used to signal proximity, touch, start and stop - maybe something is off there. Another potential cause might be the loss of event data due to some overflow, the fact that this issue only starts when more than two fingers are used hints at this. I noticed some patches for this driver, first adding extra buffer space [1], later removing it because the input driver gained some extra smarts regarding required buffer sizes [2]. The former was applied, the latter seems to have been rejected/inored/forgotten. I'll experiment a bit with this driver to see if I can get it to behave.

 [1] http://www.serverphorums.com/read.php?12,297391
 [2] https://lkml.org/lkml/2012/8/12/120

Looking at the driver (hid-magicmouse.c) I suspect the problem lies somewhere in the handling of 'DOUBLE_REPORT_ID' type responses, the which seem to be fired for touch interaction involving three or more fingers. As soon as one of those comes in the input driver gets stuck in a (autorepeat?) loop, emitting KEY events. On unloading the hid-magicmouse module and reloading it, the stuck events get fired.

The problem is - at least in my case - not located in the hid-magicmouse.c driver but in the bluetooth module (ath3k in an Acer Aspire 5552). Using either another (external) bluetooth dongle on the same machine or another machine with a different type of bluetooth adapter makes the thing work 'out of the box' with the same kernel version.

In other words, this is not a bug in either the synaptics driver nor in the kernel support for the magicmouse/trackpad. It most likely is a bug in the bluetooth firmware, given that the same bluetooth dongle gives problems under MacOSX:

http://www.tonymacx86.com/general-help/16474-enabling-bluetooth-p8p67-boards-bt-211-a.html

"Note that Apple Magic Mouse and Magic Trackpad are NOT WORKING with this fix (they freeze constantly, e.g. trackpad freezes on 4-finger swipe). If they happen to work with your setup, please report in this thread.
On the other hand, some other devices, including wireless keyboard, audio and phones has been reported to work ok. If you own Magic Mouse or Apple Trackpad, just buy Rocketfish Micro Bluetooth USB Adapter (RF-MRBTAD) that is confirmed to work."

Another report on Bluetooth problems wrt. Apple 'magic' mice/trackpads:

https://code.google.com/p/chromium/issues/detail?id=214588

In this report the device with Intel Bluetooth hardware failed to work while those with Broadcom and Atheros (no version reported) work. In other words, getting these Apple products to work reliably might take some experimenting with Bluetooth adapters.