These two values go hand-in-hand and must be valid for the driver to behave correctly. We are currently lazy about updating the values and rely on the "expected" code flow to take care of making sure they're valid at the point they're needed. The "expected" flow changed somewhat with commit f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report"), however. This led to problems with the DTH-2452 due (in part) to *all* contacts being fully processed -- even those past the expected contact count. Specifically, the received count gets reset to 0 once all expected fingers are processed, but not the expected count. The rest of the contacts in the report are then *also* processed since now the driver thinks we've only processed 0 of N expected contacts.
Later commits such as 7fb0413baa7f (HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts) worked around the DTH-2452 issue by skipping the invalid contacts at the end of the report, but this is not a complete fix. The confidence flag cannot be relied on when a contact is removed (see the following patch), and dealing with that condition re-introduces the DTH-2452 issue unless we also address this contact count laziness. By resetting expected and received counts at the same time we ensure the driver understands that there are 0 more contacts expected in the report. Similarly, we also make sure to reset the received count if for some reason we're out of sync in the pre-report phase.
Link: https://github.com/linuxwacom/input-wacom/issues/288 Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report") CC: stable@vger.kernel.org Signed-off-by: Jason Gerecke jason.gerecke@wacom.com Reviewed-by: Ping Cheng ping.cheng@wacom.com --- drivers/hid/wacom_wac.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c index 2a4cc39962e7..5978399ae7d2 100644 --- a/drivers/hid/wacom_wac.c +++ b/drivers/hid/wacom_wac.c @@ -2692,11 +2692,14 @@ static void wacom_wac_finger_pre_report(struct hid_device *hdev, hid_data->cc_index >= 0) { struct hid_field *field = report->field[hid_data->cc_index]; int value = field->value[hid_data->cc_value_index]; - if (value) + if (value) { hid_data->num_expected = value; + hid_data->num_received = 0; + } } else { hid_data->num_expected = wacom_wac->features.touch_max; + hid_data->num_received = 0; } }
@@ -2724,6 +2727,7 @@ static void wacom_wac_finger_report(struct hid_device *hdev,
input_sync(input); wacom_wac->hid_data.num_received = 0; + wacom_wac->hid_data.num_expected = 0;
/* keep touch state for pen event */ wacom_wac->shared->touch_down = wacom_wac_finger_count_touches(wacom_wac);
AES hardware may internally re-classify a contact that it thought was intentional as a palm. Intentional contacts are reported as "down" with the confidence bit set. When this re-classification occurs, however, the state transitions to "up" with the confidence bit cleared. This kind of transition appears to be legal according to Microsoft docs, but we do not handle it correctly. Because the confidence bit is clear, we don't call `wacom_wac_finger_slot` and update userspace. This causes hung touches that confuse userspace and interfere with pen arbitration.
This commit adds a special case to ignore the confidence flag if a contact is reported as removed. This ensures we do not leave a hung touch if one of these re-classification events occured. Ideally we'd have some way to also let userspace know that the touch has been re-classified as a palm and needs to be canceled, but that's not possible right now :)
Link: https://github.com/linuxwacom/input-wacom/issues/288 Fixes: 7fb0413baa7f (HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts) CC: stable@vger.kernel.org Signed-off-by: Jason Gerecke jason.gerecke@wacom.com Reviewed-by: Ping Cheng ping.cheng@wacom.com --- drivers/hid/wacom_wac.c | 29 ++++++++++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c index 5978399ae7d2..92b52b1de526 100644 --- a/drivers/hid/wacom_wac.c +++ b/drivers/hid/wacom_wac.c @@ -2588,6 +2588,24 @@ static void wacom_wac_finger_slot(struct wacom_wac *wacom_wac, } }
+static bool wacom_wac_slot_is_active(struct input_dev *dev, int key) +{ + struct input_mt *mt = dev->mt; + struct input_mt_slot *s; + + if (!mt) + return false; + + for (s = mt->slots; s != mt->slots + mt->num_slots; s++) { + if (s->key == key && + input_mt_get_value(s, ABS_MT_TRACKING_ID) >= 0) { + return true; + } + } + + return false; +} + static void wacom_wac_finger_event(struct hid_device *hdev, struct hid_field *field, struct hid_usage *usage, __s32 value) { @@ -2638,9 +2656,14 @@ static void wacom_wac_finger_event(struct hid_device *hdev, }
if (usage->usage_index + 1 == field->report_count) { - if (equivalent_usage == wacom_wac->hid_data.last_slot_field && - wacom_wac->hid_data.confidence) - wacom_wac_finger_slot(wacom_wac, wacom_wac->touch_input); + if (equivalent_usage == wacom_wac->hid_data.last_slot_field) { + bool touch_removed = wacom_wac_slot_is_active(wacom_wac->touch_input, + wacom_wac->hid_data.id) && !wacom_wac->hid_data.tipswitch; + + if (wacom_wac->hid_data.confidence || touch_removed) { + wacom_wac_finger_slot(wacom_wac, wacom_wac->touch_input); + } + } } }
On Tue, 18 Jan 2022, Jason Gerecke wrote:
These two values go hand-in-hand and must be valid for the driver to behave correctly. We are currently lazy about updating the values and rely on the "expected" code flow to take care of making sure they're valid at the point they're needed. The "expected" flow changed somewhat with commit f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report"), however. This led to problems with the DTH-2452 due (in part) to *all* contacts being fully processed -- even those past the expected contact count. Specifically, the received count gets reset to 0 once all expected fingers are processed, but not the expected count. The rest of the contacts in the report are then *also* processed since now the driver thinks we've only processed 0 of N expected contacts.
Later commits such as 7fb0413baa7f (HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts) worked around the DTH-2452 issue by skipping the invalid contacts at the end of the report, but this is not a complete fix. The confidence flag cannot be relied on when a contact is removed (see the following patch), and dealing with that condition re-introduces the DTH-2452 issue unless we also address this contact count laziness. By resetting expected and received counts at the same time we ensure the driver understands that there are 0 more contacts expected in the report. Similarly, we also make sure to reset the received count if for some reason we're out of sync in the pre-report phase.
Link: https://github.com/linuxwacom/input-wacom/issues/288 Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report") CC: stable@vger.kernel.org Signed-off-by: Jason Gerecke jason.gerecke@wacom.com Reviewed-by: Ping Cheng ping.cheng@wacom.com
Both patches applied, thanks.
linux-stable-mirror@lists.linaro.org
-
Jason Gerecke -
Jiri Kosina