From: Jason Gerecke <hidden> Date: 2016-07-11 17:59:58
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occuring, we stop mapping usages after having seen
HID_DG_CONTACTCOUNT. This usage is only present in multitouch reports,
so the format of any following single-touch reports will have no effect.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
drivers/hid/wacom_wac.c | 5 +++++
1 file changed, 5 insertions(+)
From: Benjamin Tissoires <hidden> Date: 2016-07-12 07:32:55
Hi Jason,
On Jul 11 2016 or thereabouts, Jason Gerecke wrote:
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occuring, we stop mapping usages after having seen
HID_DG_CONTACTCOUNT. This usage is only present in multitouch reports,
so the format of any following single-touch reports will have no effect.
I had a quick look at the driver, and it looks like the Cintiq Companion
2 has more than one multitouch collection (see 499522c "HID: wacom: Tie
cached HID_DG_CONTACTCOUNT indices to report ID").
So if this doesn't break the cintiq companion 2, you have my
reviewed-by, but I'd rather be sure (and please see if we really need to
keep 499522c then).
Cheers,
Benjamin
From: Jason Gerecke <hidden> Date: 2016-07-20 16:36:31
On 07/12/2016 12:32 AM, Benjamin Tissoires wrote:
Hi Jason,
On Jul 11 2016 or thereabouts, Jason Gerecke wrote:
quoted
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occuring, we stop mapping usages after having seen
HID_DG_CONTACTCOUNT. This usage is only present in multitouch reports,
so the format of any following single-touch reports will have no effect.
I had a quick look at the driver, and it looks like the Cintiq Companion
2 has more than one multitouch collection (see 499522c "HID: wacom: Tie
cached HID_DG_CONTACTCOUNT indices to report ID").
So if this doesn't break the cintiq companion 2, you have my
reviewed-by, but I'd rather be sure (and please see if we really need to
keep 499522c then).
Cheers,
Benjamin
Thanks for the reminder about 499522c. This patch should supersede it in
terms of functionality, so I can make a patch to remove it instead.
As far as compatibility goes, I don't have a Companion 2 to actually
test, but looking at the descriptor [1], it shouldn't pose any problems:
the second report containing HID_DG_CONTACTCOUNT is the single-touch
report that we don't want to use anyway.
[1]:
https://github.com/linuxwacom/wacom-hid-descriptors/blob/master/Wacom%20Cintiq%20Companion%202/0003:056A:0326.0002.hid.txt
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
@@ -1560,6 +1560,11 @@ static void wacom_wac_finger_usage_mapping(struct hid_device *hdev,structinput_dev*input=wacom_wac->touch_input;unsignedtouch_max=wacom_wac->features.touch_max;+/* stop processing after the first multitouch report */+if(wacom_wac->hid_data.cc_report&&+wacom_wac->hid_data.cc_report!=field->report->id)+return;+switch(usage->hid){caseHID_GD_X:features->last_slot_field=usage->hid;
--
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jason Gerecke <hidden> Date: 2016-07-20 21:35:48
On 07/20/2016 09:36 AM, Jason Gerecke wrote:
On 07/12/2016 12:32 AM, Benjamin Tissoires wrote:
quoted
Hi Jason,
On Jul 11 2016 or thereabouts, Jason Gerecke wrote:
quoted
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occuring, we stop mapping usages after having seen
HID_DG_CONTACTCOUNT. This usage is only present in multitouch reports,
so the format of any following single-touch reports will have no effect.
I had a quick look at the driver, and it looks like the Cintiq Companion
2 has more than one multitouch collection (see 499522c "HID: wacom: Tie
cached HID_DG_CONTACTCOUNT indices to report ID").
So if this doesn't break the cintiq companion 2, you have my
reviewed-by, but I'd rather be sure (and please see if we really need to
keep 499522c then).
Cheers,
Benjamin
Thanks for the reminder about 499522c. This patch should supersede it in
terms of functionality, so I can make a patch to remove it instead.
As far as compatibility goes, I don't have a Companion 2 to actually
test, but looking at the descriptor [1], it shouldn't pose any problems:
the second report containing HID_DG_CONTACTCOUNT is the single-touch
report that we don't want to use anyway.
[1]:
https://github.com/linuxwacom/wacom-hid-descriptors/blob/master/Wacom%20Cintiq%20Companion%202/0003:056A:0326.0002.hid.txt
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
On closer inspection, it's probably not right to say that this patch
supersedes 499522c. It does remove the need for it, but only under the
(currently valid) assumption that the first report with
HID_DG_CONTACTCOUNT is the report the tablet will send.
If we want to be free of that assumption, it might be a better idea to
replace this patch with something that instead does additional work in
the pre_report phase to update last_slot_field (just like how 499522c
updates cc_index and cc_value_index during pre_report).
Thoughts?
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
@@ -1560,6 +1560,11 @@ static void wacom_wac_finger_usage_mapping(struct hid_device *hdev,structinput_dev*input=wacom_wac->touch_input;unsignedtouch_max=wacom_wac->features.touch_max;+/* stop processing after the first multitouch report */+if(wacom_wac->hid_data.cc_report&&+wacom_wac->hid_data.cc_report!=field->report->id)+return;+switch(usage->hid){caseHID_GD_X:features->last_slot_field=usage->hid;
--
2.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Jason Gerecke <hidden> Date: 2016-07-21 16:11:02
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
Changes from v1:
* The v1 patch cut off processing by wacom_wac_finger_usage_mapping once
it saw a HID_DG_CONTACTCOUNT usage in any report. This method of
handling the bug has two potential problems: 1) reports which place
the HID_DG_CONTACTCOUNT usage near the beginning of the packet will
not properly map the rest of the usages, and 2) devices which have
multiple reports with the HID_DG_CONTACTCOUNT usage will only send
reports formatted like the first discovered. Neither of these should
cause issues for currently available hardware, but to maximize forward
compatibility, the revised scheme contained here was devised.
drivers/hid/wacom_wac.c | 62 +++++++++++++++++++++----------------------------
drivers/hid/wacom_wac.h | 2 +-
2 files changed, 27 insertions(+), 37 deletions(-)
On Thu, Jul 21, 2016 at 9:10 AM, Jason Gerecke [off-list ref] wrote:
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Nice job, Jason! I like this approach. The patch is:
Reviewed-by: Ping Cheng <redacted>
Cheers,
Ping
quoted hunk
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
Changes from v1:
* The v1 patch cut off processing by wacom_wac_finger_usage_mapping once
it saw a HID_DG_CONTACTCOUNT usage in any report. This method of
handling the bug has two potential problems: 1) reports which place
the HID_DG_CONTACTCOUNT usage near the beginning of the packet will
not properly map the rest of the usages, and 2) devices which have
multiple reports with the HID_DG_CONTACTCOUNT usage will only send
reports formatted like the first discovered. Neither of these should
cause issues for currently available hardware, but to maximize forward
compatibility, the revised scheme contained here was devised.
drivers/hid/wacom_wac.c | 62 +++++++++++++++++++++----------------------------
drivers/hid/wacom_wac.h | 2 +-
2 files changed, 27 insertions(+), 37 deletions(-)
From: Benjamin Tissoires <hidden> Date: 2016-07-25 09:38:35
On Jul 21 2016 or thereabouts, Jason Gerecke wrote:
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
Changes from v1:
* The v1 patch cut off processing by wacom_wac_finger_usage_mapping once
it saw a HID_DG_CONTACTCOUNT usage in any report. This method of
handling the bug has two potential problems: 1) reports which place
the HID_DG_CONTACTCOUNT usage near the beginning of the packet will
not properly map the rest of the usages, and 2) devices which have
multiple reports with the HID_DG_CONTACTCOUNT usage will only send
reports formatted like the first discovered. Neither of these should
cause issues for currently available hardware, but to maximize forward
compatibility, the revised scheme contained here was devised.
Thanks for the fix. The overall difference between before and after the
patch seems null (few variable allocations), so:
Reviewed-by: Benjamin Tissoires <redacted>
Cheers,
Benjamin
From: Jason Gerecke <hidden> Date: 2016-08-10 18:21:18
Making sure this patch doesn't fall into the cracks...
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
On 07/25/2016 02:38 AM, Benjamin Tissoires wrote:
On Jul 21 2016 or thereabouts, Jason Gerecke wrote:
quoted
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
---
Changes from v1:
* The v1 patch cut off processing by wacom_wac_finger_usage_mapping once
it saw a HID_DG_CONTACTCOUNT usage in any report. This method of
handling the bug has two potential problems: 1) reports which place
the HID_DG_CONTACTCOUNT usage near the beginning of the packet will
not properly map the rest of the usages, and 2) devices which have
multiple reports with the HID_DG_CONTACTCOUNT usage will only send
reports formatted like the first discovered. Neither of these should
cause issues for currently available hardware, but to maximize forward
compatibility, the revised scheme contained here was devised.
Thanks for the fix. The overall difference between before and after the
patch seems null (few variable allocations), so:
Reviewed-by: Benjamin Tissoires <redacted>
Cheers,
Benjamin
Making sure this patch doesn't fall into the cracks...
Alright, I apparently wasn't CCed; please don't forget to do so on patches
you want me to apply, otherwise they might easily be missed.
My understanding is that this is rather 4.8 material still, do you agree?
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jason Gerecke <hidden> Date: 2016-08-11 15:23:32
On 08/11/2016 01:27 AM, Jiri Kosina wrote:
On Wed, 10 Aug 2016, Jason Gerecke wrote:
quoted
Making sure this patch doesn't fall into the cracks...
Alright, I apparently wasn't CCed; please don't forget to do so on patches
you want me to apply, otherwise they might easily be missed.
My understanding is that this is rather 4.8 material still, do you agree?
Thanks,
Yes, it should be fine to target for 4.8.
Thanks,
Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....
If a touchscreen contains both multitouch and single-touch reports in its
descriptor in that order, the driver may overwrite information it saved
about the format of the multitouch report. This can cause the report
processing code to get tripped up and send an incorrect event stream to
userspace.
In particular, this can cause last_slot_field to be overwritten with the
result that the driver prematurely assumes it has finished processing a
slot and sending the ABS_MT_SLOT event at the wrong point in time,
associating events for the current contact with the following contact
instead.
To prevent this from occurring, we update the value of last_slot_field
durring the pre_report phase to ensure that it is correct for the report
that is to be processed.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Applied to for-4.8/upstream-fixes.
--
Jiri Kosina
SUSE Labs