Possible extra third (0, 0) touch when two touches land in same frame
Opening this issue by request as discussed in #5 (closed) - this behavior was revealed while experimenting with tp_detect_thumb_while_moving. It seems that if two touches arrive in the exact same frame, three touches are registered by tp_for_each_touch, one of which has point coordinates (0, 0).
Here is a patched version of libinput that reveals this behavior, with the experimental thumb-detect code as well as some extra logging: https://github.com/mdmayfield/libinput.git
Here's a recording demonstrating the issue: zero-coords.txt Note that the issue doesn't occur on mainline libinput; so this could be revealing some interesting edge case, or it might just be a mistake in my code.
There are three movements - the issue is shown in the second one:
- Regular pointer movement
- Scroll that doesn't work (false positive thumb due to "phantom" third 0,0 touch)
- Scroll that works
This is the relevant output from debug-events where it sees 3 touches instead of 2. The "second" gets overwritten because two of the touches have state == TOUCH_BEGIN:
event18 - button state: touch 0 from BUTTON_STATE_AREA, event BUTTON_EVENT_UP to BUTTON_STATE_NONE
event18 - thumb state: touch 0, THUMB_STATE_MAYBE → THUMB_STATE_NO
event18 - thumb state: touch 1, THUMB_STATE_MAYBE → THUMB_STATE_NO
event18 - Assigning second to new touch 0, coords (842, 494)
event18 - Assigning second to new touch 1, coords (600, 498)
event18 - Assigning first to existing touch 2, coords (0, 0)
event18 - comparing first at (0, 0) to second at (600, 498)
event18 - second (index 1) is lower; marking as thumb
This is the first libinput record frame where the above happens:
- evdev:
- [ 1, 68189, 3, 57, 24] # EV_ABS / ABS_MT_TRACKING_ID 24
- [ 1, 68189, 3, 53, 842] # EV_ABS / ABS_MT_POSITION_X 842
- [ 1, 68189, 3, 54, 494] # EV_ABS / ABS_MT_POSITION_Y 494
- [ 1, 68189, 3, 47, 1] # EV_ABS / ABS_MT_SLOT 1
- [ 1, 68189, 3, 57, 25] # EV_ABS / ABS_MT_TRACKING_ID 25
- [ 1, 68189, 3, 53, 600] # EV_ABS / ABS_MT_POSITION_X 600
- [ 1, 68189, 3, 54, 498] # EV_ABS / ABS_MT_POSITION_Y 498
- [ 1, 68189, 1, 330, 1] # EV_KEY / BTN_TOUCH 1
- [ 1, 68189, 1, 333, 1] # EV_KEY / BTN_TOOL_DOUBLETAP 1
- [ 1, 68189, 3, 0, 842] # EV_ABS / ABS_X 842
- [ 1, 68189, 3, 1, 494] # EV_ABS / ABS_Y 494
- [ 1, 68189, 4, 5, 1073100] # EV_MSC / MSC_TIMESTAMP 1073100
- [ 1, 68189, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +539ms
The working scroll starts at line 945 in the recording, where you can see the touches started on separate frames. This is consistent with all my testing yesterday - the only factor that made the difference was if the fingers touched simultaneously in the same frame.
Do you suppose that my touchpad is sending an extra "tool" representing a double-touch, along with each of the actual touches, which is then being interpreted as a third touch with no coordinates included?
Finally, yesterday during one test, all of the "phantom" touches that were previously at (0, 0) were at some arbitrary spot, like (481, 860) or such - consistently regardless of where I touched the pad. Unfortunately I did not capture this in a recording and was not able to reproduce it today.