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@xxxxxxxxxxxxxxx
> Signed-off-by: Jason Gerecke <jason.gerecke@xxxxxxxxx>
> Reviewed-by: Ping Cheng <ping.cheng@xxxxxxxxx>
Both patches applied, thanks.
--
Jiri Kosina
SUSE Labs
