On Fri, Jun 1, 2018 at 9:03 PM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: > >>> However, I interpret a firmware that send (confidence 1, tip switch 1) >>> and then (confidence 0, tip switch 0) a simple release, and the >>> confidence bit should not be relayed. >> >> This unfortunately leads to false clicks: you start with finger, so >> confidence is 1, then you transition the same touch to palm (use your >> thumb and "roll" your hand until heel of it comes into contact with the >> screen). The firmware reports "no-confidence" and "release" in the same >> report and userspace seeing release does not pay attention to confidence >> (i.e. it does exactly "simple release" logic) and this results in UI >> interpreting this as a click. With splitting no-confidence >> (MT_TOOL_PALM) and release event into separate frames we help userspace >> to recognize that the contact should be discarded. > > This is in part why I objected to this patch on August 11th, 2017. > Logically, the confidence state is a property of a contact, not a new type > of contact. Trying to use it in any other way is bound to lead to confusion. Problem is that MT_TOOL_PALM has been introduced in the kernel since v4.0 (late 2015 by a736775db683 "Input: add MT_TOOL_PALM"). It's been used in the Synaptics RMI4 driver since and by hid-asus in late 2016. I can't find any other users in the current upstream tree, but those two are already making a precedent and changing the semantic is a little bit late :/ Cheers, Benjamin > > Henrik > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
