Hi Dmitry,
The meaning of confidence is literally "contact is too large to be a
finger", so it is not touch state, but really tool identity. We do
allow tool identity to change over time.
What I am arguing is rather that since "palm" is a property, just like
contact size, there should be no need to confuse that property with the
touch state, which is, as you state, what happens in userland when the
tool type is modified. Using a different event for the palm property
ought to remove that confusion.
The additional state is simply because we have never updated the tool
type on release events and userspace is not expecting it and is likely
to ignore any data in the slot that is accompanied with
ABS_TRACKING_ID == -1. So we synthesize an extra event to have
distinct tool change and release.
We update all other properties of a contact freely at release, so logically there is no good reason to treat palm, the binary version of max contact size, differently.
Mostly because with BTN_TOOL_PALM we are not able to decide which
contact is turning into palm. Also, other drivers (RMI) use
MT_TOOL_PALM and I would like to report palm state in unified way.
Precedent certainly matters, but in this case, I think the modification
promises problems down the road. I would rather suggest to add a new
binary palm property, with the precise meaning "contact size = max
contact size", and take it from there. I dont mind writing a patch for
it if you agree.
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
