[input] palm detection
based on #74, the ultimate goal is palm detection.
approaches:
- multiple contact points: no good
- stylus near screen: no good
- mt_tool_palm: not impl.
- ABS_MT_TOUCH_MAJOR: probably good
I see we aren't capturing ABS_MT_TOUCH_MAJOR or ABS_MT_TOUCH_MINOR, but those describe the size of the touch on the screen. For me a finger shows up as around major=17;minor=8. The edge of my hand has a lot of different sizes, but it seems like it's always at least major >= 26 OR minor >= 17, so maybe that's a reasonable threshold.
some numbers for ABS_MT_TOUCH_MAJOR for me:
on rm1 with direct press: 4 and 9 emitted for touch major on rm2 with direct press: 8 and 17 on rm1 with finger laid flat: 14 - 29 on rm2 with finger laid flat: ??? on rm1 with palm: 14 - 33 on rm2 with palm: 17 - 52
it looks like rm1 is about half of rm2 for me. the min/max (via evtest) are the same on the rm1 and rm2 for the touch major field, so not sure how to detect (aside from just making rm1/rm2 distinction).
cc @mrichards42
what do you think are good numbers here? something like 10 on major access we ignore for rm1 and 15+ on rm2?
Good question. I think we have to consider both major and minor, since it's trying to describe an ellipse, so what really matters is the area? e.g. this is what mine look like in terms of area:
| type | rm | major | minor | area (pi*major*minor/4) |
|---|---|---|---|---|
| touch | 2 | 17 | 8 | 106.81415 |
| palm | 2 | 26 | 8 | 163.362818 |
| palm | 2 | 17 | 17 | 226.980069 |
sounds like your rm2 numbers might be close? so that would suggest that the boundary is about at 130 in area -- although given that *pi and /4 are constants, maybe we could factor those out so it's major*minor > 150?
i think there is palm detection now and it's configurable (in remux)