HID: wacom: Correct behavior when processing some confidence == false… #406
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… touches
There appear to be a few different ways that Wacom devices can deal with
confidence:
1. If the device looses confidence in a touch, it will first clear
the tipswitch flag in one report, and then clear the confidence
flag in a second report. This behavior is used by e.g. DTH-2452.
2. If the device looses confidence in a touch, it will clear both
the tipswitch and confidence flags within the same report. This
behavior is used by some AES devices.
3. If the device looses confidence in a touch, it will clear *only*
the confidence bit. The tipswitch bit will remain set so long as
the touch is tracked. This behavior may be used in future devices.
The driver does not currently handle situation 3 properly. Touches that
loose confidence will remain "in prox" and essentially frozen in place
until the tipswitch bit is finally cleared. Not only does this result
in userspace seeing a stuck touch, but it also prevents pen arbitration
from working properly (the pen won't send events until all touches are
up, but we don't currently process events from non-confident touches).
This commit centralizes the checking of the confidence bit in the
wacom_wac_finger_slot() function and has 'prox' depend on it. In the
case where situation 3 is encountered, the treat the touch as though
it was removed, allowing both userspace and the pen arbitration to
act normally.
Signed-off-by: Tatsunosuke Tobita <[email protected]>
Signed-off-by: Ping Cheng <[email protected]>
Signed-off-by: Jason Gerecke <[email protected]>
Fixes: 7fb0413baa7f ("HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts")
Cc: [email protected]
Signed-off-by: Jiri Kosina <[email protected]>
Link: https://lore.kernel.org/all/[email protected]/
[[email protected]: Imported into input-wacom (502296030ec6)]
Signed-off-by: Tatsunosuke Tobita <[email protected]>
|
Thank you Tats for your effort! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… touches
There appear to be a few different ways that Wacom devices can deal with confidence:
If the device looses confidence in a touch, it will first clear the tipswitch flag in one report, and then clear the confidence flag in a second report. This behavior is used by e.g. DTH-2452.
If the device looses confidence in a touch, it will clear both the tipswitch and confidence flags within the same report. This behavior is used by some AES devices.
If the device looses confidence in a touch, it will clear only the confidence bit. The tipswitch bit will remain set so long as the touch is tracked. This behavior may be used in future devices.
The driver does not currently handle situation 3 properly. Touches that loose confidence will remain "in prox" and essentially frozen in place until the tipswitch bit is finally cleared. Not only does this result in userspace seeing a stuck touch, but it also prevents pen arbitration from working properly (the pen won't send events until all touches are up, but we don't currently process events from non-confident touches).
This commit centralizes the checking of the confidence bit in the wacom_wac_finger_slot() function and has 'prox' depend on it. In the case where situation 3 is encountered, the treat the touch as though it was removed, allowing both userspace and the pen arbitration to act normally.
Fixes: 7fb0413baa7f ("HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts")
Cc: [email protected]
Link: https://lore.kernel.org/all/[email protected]/
[[email protected]: Imported into input-wacom (502296030ec6)]