-
Notifications
You must be signed in to change notification settings - Fork 36
Description
I was thinking about palm-rejection when using the pen, and figured one way to do that might be rejecting any SynMotionEvents with more than, say, 5 slots. When I tried this out, the number of slots reported in the original TouchEvent wasn't always accurate. I think this is related to #45.
From reading through a log with DEBUG_INPUT_EVENT=1, it looks like what's happening is that each raw event only includes information about the most recently changed slot. I'm not positive, but I think we need to have TouchEvents start with a copy of the previous event (including all slots), since the input appears to be an update, not a full event. For instance, this is a log from a rm2 of placing 4 fingers on the screen, one after the other, and then lifting them up in the same order (i.e. 1 down, 2 down, 3 down, 4 down, 1 up, 2 up, 3 up 4 up). I also did the reverse (1d, 2d, 3d, 4d, 4u, 3u, 2u, 1u) for comparison.
There's a lot of extra junk in there, since each tiny change in location or pressure triggers a new event. The important parts are when a new slot appears, with a corresponding tracking-id, and when that tracking-id goes away.
A small example:
This is a heavily edited excerpt from the first log, showing 2 slots
# Initial event (slot 0)
event: time 1612038446, type: 3, code :39, value 3003 <-- tracking id for slot 0
event: time 1612038446, type: 3, code :35, value 282 <-- x
event: time 1612038446, type: 3, code :36, value 1608 <-- y
event: time 1612038446, type: 3, code :3a, value 113 <-- pressure
event: time 1612038446, type: 3, code :30, value 17
event: time 1612038446, type: 3, code :34, value 3
# Slot 1 appears with a new tracking id
# Note that position and pressure are specific to slot 1 here; slot 0 has not changed
Event: time 1612038446, type: 3, code :2f, value 1 <-- slot 1
Event: time 1612038446, type: 3, code :39, value 3004 <-- tracking id for slot 1
Event: time 1612038446, type: 3, code :35, value 510 <-- x
Event: time 1612038446, type: 3, code :36, value 1650 <-- y
Event: time 1612038446, type: 3, code :3a, value 85 <-- pressure
Event: time 1612038446, type: 3, code :30, value 8
Event: time 1612038446, type: 3, code :31, value 17
Event: time 1612038446, type: 3, code :34, value 2
# Slot 0 updates position and pressure
Event: time 1612038446, type: 3, code :2f, value 0 <-- slot 0
Event: time 1612038446, type: 3, code :36, value 1594 <-- y
Event: time 1612038446, type: 3, code :3a, value 116 <-- pressure
# Slot 0 again, since we haven't gotten another 2f
Event: time 1612038446, type: 3, code :35, value 283 <-- x
Event: time 1612038446, type: 3, code :36, value 1593 <-- y
Event: time 1612038446, type: 3, code :3a, value 115 <-- pressure
# One more slot 0, then slot 2
Event: time 1612038446, type: 3, code :3a, value 113 <-- pressure (slot 0)
Event: time 1612038446, type: 3, code :2f, value 1 <-- slot 1
Event: time 1612038446, type: 3, code :35, value 508 <-- x
Event: time 1612038446, type: 3, code :3a, value 86 <-- pressure
# Slot 0 is lifted up
Event: time 1612038446, type: 3, code :2f, value 0 <-- slot 0
Event: time 1612038446, type: 3, code :39, value -1 <-- tracking-id removed
# Slot 1 keeps getting events
Event: time 1612038446, type: 3, code :2f, value 1 <-- slot 1
Event: time 1612038446, type: 3, code :36, value 1656 <-- y
Event: time 1612038446, type: 3, code :3a, value 86 <-- pressure
# Slot 1 is lifted up
Event: time 1612038446, type: 3, code :39, value -1 <-- tracking-id removed
And at this point there are no more slots left, so we can throw away this event and start the next touch from scratch.
It looks like currently the slot count is set to the most recently seen slot, but I think it actually needs to be a count of the number of slots with positive tracking-ids. I wonder if that might be related to overly sensitive three-finger gesture from #44?