Hi Guys,
The first patch fixes the bug I discovered lately. This bug was related to the out
of bound bitfield test, so it concerns every known devices. Ideally, it should go
to upstream-fixes, but this would requires additional adaptations.
Jiri, How do you want to proceed?
The last 4 patches are the beginning of the support of Win8 devices. It's only the
beginning as the specification is much more precise than the Win7, and we will need
to do more tuning in the future. However, Win8 devices are retro-compatible with
Win7, so they will work out of the box though.
Cheers,
Benjamin
From: Benjamin Tissoires <redacted>
Win8 devices are required to present the feature "Maximum Contact Number".
If the current value is 0, then, the driver can get the actual supported
contact count by seeing the logical_max.
Signed-off-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-multitouch.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
@@ -265,6 +265,8 @@ static void mt_feature_mapping(struct hid_device *hdev,caseHID_DG_CONTACTMAX:td->maxcontact_report_id=field->report->id;td->maxcontacts=field->value[0];+if(!td->maxcontacts)+td->maxcontacts=field->logical_maximum;if(td->mtclass.maxcontacts)/* check if the maxcontacts is given by the class */td->maxcontacts=td->mtclass.maxcontacts;
From: Benjamin Tissoires <redacted>
The previous implementation introduced a randomness in the splitting
of the different touches reported by the device. This version is more
robust as we don't rely on hi->input->absbit, but on our own structure.
This also prepares hid-multitouch to better support Win8 devices.
Signed-off-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-multitouch.c | 58 +++++++++++++++++++++++++++++++++--------
1 files changed, 46 insertions(+), 12 deletions(-)
@@ -70,9 +70,16 @@ struct mt_class {boolis_indirect;/* true for touchpads */};+structmt_fields{+unsignedusages[HID_MAX_FIELDS];+unsignedintlength;+};+structmt_device{structmt_slotcurdata;/* placeholder of incoming data */structmt_classmtclass;/* our mt device class */+structmt_fields*fields;/* temporary placeholder for storing the+multitouchfields*/unsignedlast_field_index;/* last field index of the report */unsignedlast_slot_field;/* the last field of a slot */__s8inputmode;/* InputMode HID feature, -1 if non-existent */
From: Benjamin Tissoires <redacted>
Win8 input specification clarifies the X and Y sent by devices.
It distincts the position where the user wants to Touch (T) from
the center of the ellipsoide (C). This patch enable supports for this
distinction in hid-multitouch.
We recognize Win8 certified devices from their vendor field 0xff0000c5
where Microsoft put a signed blob in the report to check if the device
passed the certification.
Signed-off-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-multitouch.c | 77 +++++++++++++++++++++++++++++++++++++++---
1 files changed, 72 insertions(+), 5 deletions(-)
@@ -51,9 +51,10 @@ MODULE_LICENSE("GPL");#define MT_QUIRK_VALID_IS_INRANGE (1 << 5)#define MT_QUIRK_VALID_IS_CONFIDENCE (1 << 6)#define MT_QUIRK_SLOT_IS_CONTACTID_MINUS_ONE (1 << 8)+#define MT_QUIRK_WIN_8_CERTIFIED (1 << 9)structmt_slot{-__s32x,y,p,w,h;+__s32x,y,cx,cy,p,w,h;__s32contactid;/* the device ContactID assigned to this slot */booltouch_state;/* is the touch valid? */boolseen_in_this_frame;/* has this slot been updated */
@@ -666,6 +688,47 @@ static void mt_post_parse_default_settings(struct mt_device *td)td->mtclass.quirks=quirks;}+staticvoidmt_post_parse_win8(structmt_device*td)+{+structmt_fields*f=td->fields;+intfield_count_per_touch=f->length/td->touches_by_report;+inti;++intposition_x_index=-1;+intposition_y_index=-1;+intcenter_x_index=-1;+intcenter_y_index=-1;++for(i=0;i<field_count_per_touch;i++){+switch(f->usages[i]->hid){+caseHID_GD_X:+if(position_x_index<0)+position_x_index=i;+else+center_x_index=i;+break;+caseHID_GD_Y:+if(position_y_index<0)+position_y_index=i;+else+center_y_index=i;+break;+}+}++if(center_x_index<0||center_y_index<0)+/* center X and center y are not provided */+return;++for(i=0;i<td->touches_by_report;i++){+intcur_touch_index=i*field_count_per_touch;+structhid_usage**usages=&f->usages[cur_touch_index];++usages[center_x_index]->code=ABS_MT_CENTER_X;+usages[center_y_index]->code=ABS_MT_CENTER_Y;+}+}+staticvoidmt_post_parse(structmt_device*td){structmt_fields*f=td->fields;
From: Benjamin Tissoires <redacted>
Microsoft published a new version of their multitouch specification.
They introduced a new multitouch field: MT_CENTER_X|Y.
Signed-off-by: Benjamin Tissoires <redacted>
---
Documentation/input/multi-touch-protocol.txt | 14 ++++++++++++--
include/linux/input.h | 8 +++++---
2 files changed, 17 insertions(+), 5 deletions(-)
@@ -254,11 +254,21 @@ between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1] ABS_MT_POSITION_X-The surface X coordinate of the center of the touching ellipse.+The surface X coordinate of the point the user intended to touch. ABS_MT_POSITION_Y-The surface Y coordinate of the center of the touching ellipse.+The surface Y coordinate of the point the user intended to touch.++ABS_MT_CENTER_X++The surface X coordinate of the center of the touching ellipse. This field is+introduced by Windows 8 multitouch protocol.++ABS_MT_CENTER_Y++The surface Y coordinate of the center of the touching ellipse. This field is+introduced by Windows 8 multitouch protocol. ABS_MT_TOOL_TYPE
@@ -806,18 +806,20 @@ struct input_keymap_entry {#define ABS_MT_WIDTH_MAJOR 0x32 /* Major axis of approaching ellipse */#define ABS_MT_WIDTH_MINOR 0x33 /* Minor axis (omit if circular) */#define ABS_MT_ORIENTATION 0x34 /* Ellipse orientation */-#define ABS_MT_POSITION_X 0x35 /* Center X ellipse position */-#define ABS_MT_POSITION_Y 0x36 /* Center Y ellipse position */+#define ABS_MT_POSITION_X 0x35 /* X the user intended to touch */+#define ABS_MT_POSITION_Y 0x36 /* Y the user intended to touch */#define ABS_MT_TOOL_TYPE 0x37 /* Type of touching device */#define ABS_MT_BLOB_ID 0x38 /* Group a set of packets as a blob */#define ABS_MT_TRACKING_ID 0x39 /* Unique ID of initiated contact */#define ABS_MT_PRESSURE 0x3a /* Pressure on contact area */#define ABS_MT_DISTANCE 0x3b /* Contact hover distance */+#define ABS_MT_CENTER_X 0x3c /* Center X ellipse position */+#define ABS_MT_CENTER_Y 0x3d /* Center Y ellipse position */#ifdef __KERNEL__/* Implementation details, userspace should not care about these */#define ABS_MT_FIRST ABS_MT_TOUCH_MAJOR-#define ABS_MT_LAST ABS_MT_DISTANCE+#define ABS_MT_LAST ABS_MT_CENTER_Y#endif#define ABS_MAX 0x3f
From: Benjamin Tissoires <redacted>
Win8 certification introduced the ability to transmit two X and two Y per
touch. The specification precises that it must be in an array, with a
report count == 2.
This test guarantees that we split the touches on the last element
in this array.
Signed-off-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-multitouch.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
@@ -589,7 +589,10 @@ static int mt_event(struct hid_device *hid, struct hid_field *field,return0;}-if(usage->hid==td->last_slot_field)+if(usage->hid==td->last_slot_field&&+usage==&field->usage[field->maxusage-1])+/* we only take into account the last report+*ofafieldifreport_count>1*/mt_complete_slot(td);if(field->index==td->last_field_index
From: Henrik Rydberg <hidden> Date: 2012-05-04 13:43:48
Hi Benjamin, Stephane,
Microsoft published a new version of their multitouch specification.
They introduced a new multitouch field: MT_CENTER_X|Y.
I would like a bit of elaboration here, since I am not convinced the
mapping should be directly translated to the MT protocol.
Clearly, the basic idea to be able to model an assymmetric tool is
good. Without an angle description, however, there seems to be a
mismatch in the degrees of freedom. In win8, one can place the hot
spot in a corner of the rectangle, but one cannot make the rectangle
into an ellipse in that direction. In linux, one can put the ellipse
in the wanted direction, but the hot spot is always in the center. To
first order, both models allow for finger-rotation information, but in
different ways. Adding more parameters requires a bit more
thought. Perhaps one should use the newly found win8 parameters to
reshape the pointing ellipse to start with.
Thanks,
Henrik
From: Benjamin Tissoires <hidden> Date: 2012-05-06 14:34:31
Hi Henrik,
Well, this is the mail I intended to send yesterday before I run out
of internet connection. This may be useless, but, I'll send it
anyway....
On Fri, May 4, 2012 at 3:48 PM, Henrik Rydberg [off-list ref] wrote:
Hi Benjamin, Stephane,
quoted
Microsoft published a new version of their multitouch specification.
They introduced a new multitouch field: MT_CENTER_X|Y.
I would like a bit of elaboration here, since I am not convinced the
mapping should be directly translated to the MT protocol.
Clearly, the basic idea to be able to model an assymmetric tool is
good. Without an angle description, however, there seems to be a
mismatch in the degrees of freedom. In win8, one can place the hot
spot in a corner of the rectangle, but one cannot make the rectangle
into an ellipse in that direction.
That's not the interpretation I made of the spec.
http://msdn.microsoft.com/library/windows/hardware/br259100
Win8 is a total respin of the multitouch protocol (though backward
compatible). It asks for a lot more reliability and performances for
the devices.
From what I understood, the T point (the touch) can be an arbitrary
point within the ellipse. Furthermore, the ellipse can be oriented in
an arbitrary rotation (like linux) because they introduced the hid
field Azimuth (0x3f) that is the "Counter-clockwise rotation of the
cursor around the Z axis".
To sum up, there are two kind of information:
- The touch point (where the user wants to touch)
- The elliptic shape of the touch (width, height, center, azimuth, pressure)
I think these two information are interesting as most of the time, the
center of the ellipse is _not_ the point where the user wants to
touch. The best thing to test that is to see how many time you miss
the pixel you want to touch in the current implementation.
I also wanted to publish these 2 last patches to raise the discussion,
and to show that the fix of the randomness in the splitting of the
touches within the reports was compatible with new kinds of devices.
We should focus for now (3.5) on the first 3 patches, and let aside
the 2 last for the next version, when everyone agrees.
Cheers,
Benjamin
In linux, one can put the ellipse
in the wanted direction, but the hot spot is always in the center. To
first order, both models allow for finger-rotation information, but in
different ways. Adding more parameters requires a bit more
thought. Perhaps one should use the newly found win8 parameters to
reshape the pointing ellipse to start with.
Thanks,
Henrik
From: Henrik Rydberg <hidden> Date: 2012-05-06 17:38:22
Hi Benjamin,
quoted
I would like a bit of elaboration here, since I am not convinced the
mapping should be directly translated to the MT protocol.
Clearly, the basic idea to be able to model an assymmetric tool is
good. Without an angle description, however, there seems to be a
mismatch in the degrees of freedom. In win8, one can place the hot
spot in a corner of the rectangle, but one cannot make the rectangle
into an ellipse in that direction.
Win8 is a total respin of the multitouch protocol (though backward
compatible). It asks for a lot more reliability and performances for
the devices.
From what I understood, the T point (the touch) can be an arbitrary
point within the ellipse. Furthermore, the ellipse can be oriented in
an arbitrary rotation (like linux) because they introduced the hid
field Azimuth (0x3f) that is the "Counter-clockwise rotation of the
cursor around the Z axis".
The document is a bit unclear on what object azimuth is referring to,
and whether it correlates with the C-T vector, but essentially, there
is a lot more details, I agree.
To sum up, there are two kind of information:
- The touch point (where the user wants to touch)
- The elliptic shape of the touch (width, height, center, azimuth, pressure)
Width and height still refer to the bounding box, that much is clear
from the document. The shape modelled by azimuth is not quite that
clear.
I think these two information are interesting as most of the time, the
center of the ellipse is _not_ the point where the user wants to
touch. The best thing to test that is to see how many time you miss
the pixel you want to touch in the current implementation.
No argument here; separating the touch and shape points is a great
improvement. It also gives directional information in a simpler manner
than via the shape angle.
I also wanted to publish these 2 last patches to raise the discussion,
and to show that the fix of the randomness in the splitting of the
touches within the reports was compatible with new kinds of devices.
We should focus for now (3.5) on the first 3 patches, and let aside
the 2 last for the next version, when everyone agrees.
Yes, it may well be that the userland discussion carries over into
3.6, and we can certainly treat the hid enablement separately.
More to come on the shape modelling in the other thread.
Thanks,
Henrik
From: Henrik Rydberg <hidden> Date: 2012-05-06 18:56:51
Hi Benjamin,
quoted hunk
The previous implementation introduced a randomness in the splitting
of the different touches reported by the device. This version is more
robust as we don't rely on hi->input->absbit, but on our own structure.
This also prepares hid-multitouch to better support Win8 devices.
Signed-off-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-multitouch.c | 58 +++++++++++++++++++++++++++++++++--------
1 files changed, 46 insertions(+), 12 deletions(-)
@@ -70,9 +70,16 @@ struct mt_class {boolis_indirect;/* true for touchpads */};+structmt_fields{+unsignedusages[HID_MAX_FIELDS];+unsignedintlength;+};+structmt_device{structmt_slotcurdata;/* placeholder of incoming data */structmt_classmtclass;/* our mt device class */+structmt_fields*fields;/* temporary placeholder for storing the+multitouchfields*/
Why not skip the pointer here?
quoted hunk
unsigned last_field_index; /* last field index of the report */
unsigned last_slot_field; /* the last field of a slot */
__s8 inputmode; /* InputMode HID feature, -1 if non-existent */
How about adding the last_field_index here also, using a function like
static void mt_store_field(struct mt_device *td, struct hid_input *hi,
struct hid_field *field, struct hid_usage *usage)
From: Henrik Rydberg <hidden> Date: 2012-05-06 18:58:26
Hi,
Win8 devices are required to present the feature "Maximum Contact Number".
If the current value is 0, then, the driver can get the actual supported
contact count by seeing the logical_max.
@@ -265,6 +265,8 @@ static void mt_feature_mapping(struct hid_device *hdev,caseHID_DG_CONTACTMAX:td->maxcontact_report_id=field->report->id;td->maxcontacts=field->value[0];+if(!td->maxcontacts)+td->maxcontacts=field->logical_maximum;if(td->mtclass.maxcontacts)/* check if the maxcontacts is given by the class */td->maxcontacts=td->mtclass.maxcontacts;
The first patch fixes the bug I discovered lately. This bug was related to the out
of bound bitfield test, so it concerns every known devices. Ideally, it should go
to upstream-fixes, but this would requires additional adaptations.
Jiri, How do you want to proceed?
When did the bug get introduced, please? i.e. is it a regression?
As we are getting close to 3.5 merge window being open, maybe the best
thing to do would be just push it there once it's open, and then
eventually backport it for stable@ if necessary.
The last 4 patches are the beginning of the support of Win8 devices.
It's only the beginning as the specification is much more precise than
the Win7, and we will need to do more tuning in the future. However,
Win8 devices are retro-compatible with Win7, so they will work out of
the box though.
I understand that Henrik had some valid concerns, so I will wait for a
second respin and Henrik's ack, ok?
Thanks,
--
Jiri Kosina
SUSE Labs
From: Benjamin Tissoires <hidden> Date: 2012-05-09 17:52:09
Hello Jiri,
On Wed, May 9, 2012 at 4:39 PM, Jiri Kosina [off-list ref] wrote:
On Fri, 4 May 2012, benjamin.tissoires wrote:
quoted
The first patch fixes the bug I discovered lately. This bug was related to the out
of bound bitfield test, so it concerns every known devices. Ideally, it should go
to upstream-fixes, but this would requires additional adaptations.
Jiri, How do you want to proceed?
When did the bug get introduced, please? i.e. is it a regression?
Well, it's not exactly a regression: it's always been there... ;-)
More seriously, the bug was introduced in the commit
"HID: multitouch: fix handling of buggy reports descriptors for Dell
ST2220T" (in kernel 3.3)
The thing is that this bug fix was not good and was working by miracle.
As we are getting close to 3.5 merge window being open, maybe the best
thing to do would be just push it there once it's open, and then
eventually backport it for stable@ if necessary.
That seems fair.
quoted
The last 4 patches are the beginning of the support of Win8 devices.
It's only the beginning as the specification is much more precise than
the Win7, and we will need to do more tuning in the future. However,
Win8 devices are retro-compatible with Win7, so they will work out of
the box though.
I understand that Henrik had some valid concerns, so I will wait for a
second respin and Henrik's ack, ok?
From: Benjamin Tissoires <hidden> Date: 2012-05-09 19:04:36
Hi Henrik,
thanks for the review.
Some comments inlined:
On Sun, May 6, 2012 at 9:01 PM, Henrik Rydberg [off-list ref] wrote:
Hi Benjamin,
quoted
The previous implementation introduced a randomness in the splitting
of the different touches reported by the device. This version is more
robust as we don't rely on hi->input->absbit, but on our own structure.
This also prepares hid-multitouch to better support Win8 devices.
Signed-off-by: Benjamin Tissoires <redacted>
---
drivers/hid/hid-multitouch.c | 58 +++++++++++++++++++++++++++++++++--------
1 files changed, 46 insertions(+), 12 deletions(-)
bool is_indirect; /* true for touchpads */
};
+struct mt_fields {
+ unsigned usages[HID_MAX_FIELDS];
+ unsigned int length;
+};
+
struct mt_device {
struct mt_slot curdata; /* placeholder of incoming data */
struct mt_class mtclass; /* our mt device class */
+ struct mt_fields *fields; /* temporary placeholder for storing the
+ multitouch fields */
Why not skip the pointer here?
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
quoted
unsigned last_field_index; /* last field index of the report */
unsigned last_slot_field; /* the last field of a slot */
__s8 inputmode; /* InputMode HID feature, -1 if non-existent */
How about adding the last_field_index here also, using a function like
I'm not a big fan of this idea.
last_field_index represent the last mt field, was it local or global
(i.e. per touch or global to the report).
mt_store_field stores only the local (per-touch) information to be
able to divide the array by the number of touch. Adding the global
items there too will force us to introduce a switch to exclude global
items.
Cheers,
Benjamin
--
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: Benjamin Tissoires <hidden> Date: 2012-05-09 19:13:10
On Sun, May 6, 2012 at 9:03 PM, Henrik Rydberg [off-list ref] wrote:
Hi,
quoted
Win8 devices are required to present the feature "Maximum Contact Number".
If the current value is 0, then, the driver can get the actual supported
contact count by seeing the logical_max.
And for win7, it is zero?
Well, the truth is that the Win8 specification formally describes the
values here. And to get the certification, hardware makers have to put
the right value in logical_max.
TBH, I don't care that much now with win7 devices. Most of them are a
piece of crap (not true dual fingers, problems in hid reports
descriptors, etc...), but they just work (we made the necessary
things). With the introduction of Win8, hardware makers will have to
*certify* their devices, and thus, the Win8 driver is much less
tolerant. I really think that we are going to see more and more win8
devices, whereas win7 devices will fade out.
I had to add this patch because I have a win8 device that has the
value associated to this field at 0, and it's the first I saw with
this behavior.
Cheers,
Benjamin
case HID_DG_CONTACTMAX:
td->maxcontact_report_id = field->report->id;
td->maxcontacts = field->value[0];
+ if (!td->maxcontacts)
+ td->maxcontacts = field->logical_maximum;
if (td->mtclass.maxcontacts)
/* check if the maxcontacts is given by the class */
td->maxcontacts = td->mtclass.maxcontacts;
--
1.7.7.6
Thanks,
Henrik
--
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: Henrik Rydberg <hidden> Date: 2012-05-09 19:41:15
Hi Benjamin,
quoted
quoted
Win8 devices are required to present the feature "Maximum Contact Number".
If the current value is 0, then, the driver can get the actual supported
contact count by seeing the logical_max.
And for win7, it is zero?
Well, the truth is that the Win8 specification formally describes the
values here. And to get the certification, hardware makers have to put
the right value in logical_max.
TBH, I don't care that much now with win7 devices. Most of them are a
piece of crap (not true dual fingers, problems in hid reports
descriptors, etc...), but they just work (we made the necessary
things). With the introduction of Win8, hardware makers will have to
*certify* their devices, and thus, the Win8 driver is much less
tolerant. I really think that we are going to see more and more win8
devices, whereas win7 devices will fade out.
I had to add this patch because I have a win8 device that has the
value associated to this field at 0, and it's the first I saw with
this behavior.
As long as all existing devices are unaffected, it's fine, hence the question.
Thanks,
Henrik
From: Henrik Rydberg <hidden> Date: 2012-05-09 19:51:19
quoted
Why not skip the pointer here?
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
My bad, I misread the placement of the free() statement. I was also
concerned about memory, since HID is big enough a memory hog as it
is. Barring the added complexity of this patch, it now makes more
sense.
Acked-by: Henrik Rydberg [off-list ref]
Thanks,
Henrik
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
My bad, I misread the placement of the free() statement. I was also
concerned about memory, since HID is big enough a memory hog as it
is. Barring the added complexity of this patch, it now makes more
sense.
Acked-by: Henrik Rydberg [off-list ref]
drivers/hid/hid-multitouch.c: In function ‘mt_post_parse’:
drivers/hid/hid-multitouch.c:673: error: invalid type argument of ‘->’ (have ‘unsigned int’)
make[1]: *** [drivers/hid/hid-multitouch.o] Error 1
I believe that
td->last_slot_field = f->usages[field_count_per_touch - 1]->hid;
should be
td->last_slot_field = f->usages[field_count_per_touch - 1];
but I leave this up to you guys to fix.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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: Benjamin Tissoires <hidden> Date: 2012-05-10 09:32:59
On Thu, May 10, 2012 at 10:31 AM, Jiri Kosina [off-list ref] wrote:
On Wed, 9 May 2012, Henrik Rydberg wrote:
quoted
quoted
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
My bad, I misread the placement of the free() statement. I was also
concerned about memory, since HID is big enough a memory hog as it
is. Barring the added complexity of this patch, it now makes more
sense.
Acked-by: Henrik Rydberg [off-list ref]
drivers/hid/hid-multitouch.c: In function ‘mt_post_parse’:
drivers/hid/hid-multitouch.c:673: error: invalid type argument of ‘->’ (have ‘unsigned int’)
make[1]: *** [drivers/hid/hid-multitouch.o] Error 1
I believe that
td->last_slot_field = f->usages[field_count_per_touch - 1]->hid;
should be
td->last_slot_field = f->usages[field_count_per_touch - 1];
Ouch, indeed. the "->hid" is extra. When I split the patch 1 and 5, I
missed that one.
I tested it without the ->hid, and it's good. Do I need to resend the patch?
Cheers,
Benjamin
but I leave this up to you guys to fix.
Thanks,
--
Jiri Kosina
SUSE Labs
--
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
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
My bad, I misread the placement of the free() statement. I was also
concerned about memory, since HID is big enough a memory hog as it
is. Barring the added complexity of this patch, it now makes more
sense.
Acked-by: Henrik Rydberg [off-list ref]
drivers/hid/hid-multitouch.c: In function ‘mt_post_parse’:
drivers/hid/hid-multitouch.c:673: error: invalid type argument of ‘->’ (have ‘unsigned int’)
make[1]: *** [drivers/hid/hid-multitouch.o] Error 1
I believe that
td->last_slot_field = f->usages[field_count_per_touch - 1]->hid;
should be
td->last_slot_field = f->usages[field_count_per_touch - 1];
Ouch, indeed. the "->hid" is extra. When I split the patch 1 and 5, I
missed that one.
I tested it without the ->hid, and it's good. Do I need to resend the patch?
No, that's fine, I have fixed that up and applied.
I am not applying the rest of the patchset yet.
--
Jiri Kosina
SUSE Labs
--
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: Benjamin Tissoires <hidden> Date: 2012-05-10 12:15:33
On Wed, May 9, 2012 at 9:46 PM, Henrik Rydberg [off-list ref] wrote:
Hi Benjamin,
quoted
quoted
quoted
Win8 devices are required to present the feature "Maximum Contact Number".
If the current value is 0, then, the driver can get the actual supported
contact count by seeing the logical_max.
And for win7, it is zero?
Well, the truth is that the Win8 specification formally describes the
values here. And to get the certification, hardware makers have to put
the right value in logical_max.
TBH, I don't care that much now with win7 devices. Most of them are a
piece of crap (not true dual fingers, problems in hid reports
descriptors, etc...), but they just work (we made the necessary
things). With the introduction of Win8, hardware makers will have to
*certify* their devices, and thus, the Win8 driver is much less
tolerant. I really think that we are going to see more and more win8
devices, whereas win7 devices will fade out.
I had to add this patch because I have a win8 device that has the
value associated to this field at 0, and it's the first I saw with
this behavior.
As long as all existing devices are unaffected, it's fine, hence the question.
I checked all the reports descriptors that I have.
2 devices (one Stantum and one Irtouch) present an unrealistic
logical_max value (255). The thing is that if this logical_max is
false, and if the value is not provided, then I don't know how could I
retrieve the right value beside introducing a MT_CLS...
Henrik, do you think that 255 is two much for the slots?
Thanks,
Benjamin
From: Henrik Rydberg <hidden> Date: 2012-05-10 12:41:29
quoted
As long as all existing devices are unaffected, it's fine, hence the question.
I checked all the reports descriptors that I have.
2 devices (one Stantum and one Irtouch) present an unrealistic
logical_max value (255). The thing is that if this logical_max is
false, and if the value is not provided, then I don't know how could I
retrieve the right value beside introducing a MT_CLS...
Henrik, do you think that 255 is two much for the slots?
It is large enough for us to start worrying about how we manage
memory, not to mention throughput. Since we do not really have devices
of that type yet, how about adding a MT_MAX_MAXCONTACT next to
MT_DEFAULT_MAXCONTACT, and use it as a sanity check, like so:
if (!td->maxcontacts && field->logical_maximum <= MT_MAX_MAXCONTACT)
td->maxcontacts = field->logical_maximum;
Then the default (10) would be picked for the suspect devices, just as
it is today.
Thanks,
Henrik
From: Drews, Paul <hidden> Date: 2012-05-18 21:14:21
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
owner@vger.kernel.org] On Behalf Of Benjamin Tissoires
Sent: Wednesday, May 09, 2012 12:04 PM
To: Henrik Rydberg
Cc: Dmitry Torokhov; Jiri Kosina; Stephane Chatty; linux-input@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] HID: hid-multitouch: fix wrong protocol detection
On Sun, May 6, 2012 at 9:01 PM, Henrik Rydberg [off-list ref] wrote:
quoted
Hi Benjamin,
quoted
The previous implementation introduced a randomness in the splitting
of the different touches reported by the device. This version is more
robust as we don't rely on hi->input->absbit, but on our own structure.
quoted
quoted
+
struct mt_device {
struct mt_slot curdata; /* placeholder of incoming data */
struct mt_class mtclass; /* our mt device class */
+ struct mt_fields *fields; /* temporary placeholder for storing the
+ multitouch fields */
Why not skip the pointer here?
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
It sounds as though:
() Reviewers are a little uncomfortable with the memory footprint and
allocation/free
() The patch as it stands relies on the pattern of "usage" values repeating
for each touch, and deeming the last one in the repetition pattern to
be the last-slot-field marker.
If this is the case, how about avoiding storing all the slot-field values
and just detecting the point of repetition to use the most-recently-seen
usage value as the last-slot-field marker. I have been successfully using
the patch below based on this notion. It took the failure rate from about
1-per-10 boots to 250+ boots with no failures on an Atmel MaXTouch.
I don't have others to try it with, including the "buggy" one that led
to all this trouble in the first place.
Patch follows:
==========================================================
From 242f6773babe0fc0215764abbeeeff6510f3ca92 Mon Sep 17 00:00:00 2001
From: Paul Drews <redacted>
Date: Wed, 16 May 2012 11:15:00 -0700
Subject: [PATCH] Repair detection of last slot in multitouch reports
The logic for detecting the last per-touch slot in a
multitouch report erroneously used hid usage values (large
numbers such as 0xd0032) as indices into the smaller absbit
bitmap (with bit indexes up to 0x3f). This caused
intermittent failures in the configuration of the last-slot
value leading to stale x,y coordinates being reported in
multi-touch input events. It also carried the risk of a
segmentation fault due to the out-of-range bitmap index.
This patch takes a different approach of detecting the last
per-touch slot: when the hid usage value wraps around to
the first hid usage value we have seen already, we must be
looking at the slots for the next touch of a multi-touch
report, so the last hid usage value we have seen so far must
be the last per-touch value.
Issue: AIA-446
Change-Id: Ic1872998502874298bb60705df9bd2fc70de1738
Signed-off-by: Paul Drews <redacted>
---
drivers/hid/hid-multitouch.c | 39 ++++++++++++++++++++++++++-------------
1 files changed, 26 insertions(+), 13 deletions(-)
@@ -75,6 +75,9 @@ struct mt_device {structmt_classmtclass;/* our mt device class */unsignedlast_field_index;/* last field index of the report */unsignedlast_slot_field;/* the last field of a slot */+boollast_slot_field_found;/* last_slot_field has full init */+unsignedfirst_slot_field;+boolfirst_slot_field_found;/* for detecting wrap to next touch */__s8inputmode;/* InputMode HID feature, -1 if non-existent */__s8maxcontact_report_id;/* Maximum Contact Number HID feature,-1ifnon-existent*/
From: Benjamin Tissoires <hidden> Date: 2012-05-21 16:43:32
Hi Paul,
On Fri, May 18, 2012 at 11:14 PM, Drews, Paul [off-list ref] wrote:
quoted
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-
owner@vger.kernel.org] On Behalf Of Benjamin Tissoires
Sent: Wednesday, May 09, 2012 12:04 PM
To: Henrik Rydberg
Cc: Dmitry Torokhov; Jiri Kosina; Stephane Chatty; linux-input@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] HID: hid-multitouch: fix wrong protocol detection
quoted
On Sun, May 6, 2012 at 9:01 PM, Henrik Rydberg [off-list ref] wrote:
quoted
Hi Benjamin,
quoted
The previous implementation introduced a randomness in the splitting
of the different touches reported by the device. This version is more
robust as we don't rely on hi->input->absbit, but on our own structure.
quoted
quoted
quoted
+
struct mt_device {
struct mt_slot curdata; /* placeholder of incoming data */
struct mt_class mtclass; /* our mt device class */
+ struct mt_fields *fields; /* temporary placeholder for storing the
+ multitouch fields */
Why not skip the pointer here?
well, the idea was to keep the memory footprint low. As these values
are only needed at init, then I freed them once I finished using them.
I can of course skip the pointer, but in that case, wouldn't the
struct declaration be worthless?
It sounds as though:
() Reviewers are a little uncomfortable with the memory footprint and
allocation/free
() The patch as it stands relies on the pattern of "usage" values repeating
for each touch, and deeming the last one in the repetition pattern to
be the last-slot-field marker.
If this is the case, how about avoiding storing all the slot-field values
and just detecting the point of repetition to use the most-recently-seen
usage value as the last-slot-field marker. I have been successfully using
the patch below based on this notion. It took the failure rate from about
1-per-10 boots to 250+ boots with no failures on an Atmel MaXTouch.
I don't have others to try it with, including the "buggy" one that led
to all this trouble in the first place.
Thank you very much for this patch. However, Jiri already applied mine
with the allocation/free mechanism.
You're idea is good but it has one big problem with Win8 devices:
As we can have 2 X and 2 Y per touch report, if these dual-X reporting
or dual-Y reporting is present in the report, we will stop at the
second X or the second Y seen, which will lead to a buggy touchscreen
(the first touch won't get it's second coordinate). However, without
this particularity, the patch would have worked ;-)
If the Win8 norm has came earlier, the initial implementation that
relies on the collection would have suffice, but some hardware makers
made a bad use of it, leading us to stop using this, and relying on a
more brutal approach.
I found a little problem in the patch too:
quoted hunk
Patch follows:
==========================================================
From 242f6773babe0fc0215764abbeeeff6510f3ca92 Mon Sep 17 00:00:00 2001
From: Paul Drews <redacted>
Date: Wed, 16 May 2012 11:15:00 -0700
Subject: [PATCH] Repair detection of last slot in multitouch reports
The logic for detecting the last per-touch slot in a
multitouch report erroneously used hid usage values (large
numbers such as 0xd0032) as indices into the smaller absbit
bitmap (with bit indexes up to 0x3f). This caused
intermittent failures in the configuration of the last-slot
value leading to stale x,y coordinates being reported in
multi-touch input events. It also carried the risk of a
segmentation fault due to the out-of-range bitmap index.
This patch takes a different approach of detecting the last
per-touch slot: when the hid usage value wraps around to
the first hid usage value we have seen already, we must be
looking at the slots for the next touch of a multi-touch
report, so the last hid usage value we have seen so far must
be the last per-touch value.
Issue: AIA-446
Change-Id: Ic1872998502874298bb60705df9bd2fc70de1738
Signed-off-by: Paul Drews <redacted>
---
drivers/hid/hid-multitouch.c | 39 ++++++++++++++++++++++++++-------------
1 files changed, 26 insertions(+), 13 deletions(-)
struct mt_class mtclass; /* our mt device class */
unsigned last_field_index; /* last field index of the report */
unsigned last_slot_field; /* the last field of a slot */
+ bool last_slot_field_found; /* last_slot_field has full init */
+ unsigned first_slot_field;
+ bool first_slot_field_found; /* for detecting wrap to next touch */
__s8 inputmode; /* InputMode HID feature, -1 if non-existent */
__s8 maxcontact_report_id; /* Maximum Contact Number HID feature,
-1 if non-existent */
--
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