[PATCH 0/2] autodetection of multitouch devices

[PATCH 0/2] autodetection of multitouch devices

[Benjamin Tissoires]

Hi Guys,

These two patches finally enable the kernel to handle multitouch devices correctly.
If a device presents in its report descriptors the usage Contact ID, then it is considered as
a multitouch device and handled by hid-multitouch.

Cheers,
Benjamin

[PATCH 1/2] HID: add autodetection of multitouch devices

[Benjamin Tissoires]

As mentioned by http://www.microsoft.com/whdc/device/input/DigitizerDrvs_touch.mspx
multitouch devices are those that have the input report HID_CONTACTID.

This patch detects this and unload the generic-usb driver.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>
---
 drivers/hid/hid-core.c  |    6 ++++++
 drivers/hid/hid-input.c |   11 +++++++++++
 include/linux/hid.h     |    1 +
 3 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index af58e9c..7feac97 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1212,6 +1212,12 @@ int hid_connect(struct hid_device *hdev, unsigned int connect_mask)
 	if ((connect_mask & HID_CONNECT_HIDINPUT) && !hidinput_connect(hdev,
 				connect_mask & HID_CONNECT_HIDINPUT_FORCE))
 		hdev->claimed |= HID_CLAIMED_INPUT;
+	if (hdev->quirks & HID_QUIRK_MULTITOUCH) {
+		/* this device should be handled by hid-multitouch, skip it */
+		hdev->quirks &= ~HID_QUIRK_MULTITOUCH;
+		return -ENODEV;
+	}
+
 	if ((connect_mask & HID_CONNECT_HIDDEV) && hdev->hiddev_connect &&
 			!hdev->hiddev_connect(hdev,
 				connect_mask & HID_CONNECT_HIDDEV_FORCE))
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 6559e2e..f333139 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -474,6 +474,10 @@ static void hidinput_configure_usage(struct hid_input *hidinput, struct hid_fiel
 			map_key_clear(BTN_STYLUS2);
 			break;
 
+		case 0x51: /* ContactID */
+			device->quirks |= HID_QUIRK_MULTITOUCH;
+			goto unknown;
+
 		default:  goto unknown;
 		}
 		break;
@@ -978,6 +982,13 @@ int hidinput_connect(struct hid_device *hid, unsigned int force)
 		}
 	}
 
+	if (hid->quirks & HID_QUIRK_MULTITOUCH) {
+		/* generic hid does not know how to handle multitouch devices */
+		if (hidinput)
+			goto out_cleanup;
+		goto out_unwind;
+	}
+
 	if (hidinput && input_register_device(hidinput->input))
 		goto out_cleanup;
 
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 42f7e2f..e55a0f8 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -312,6 +312,7 @@ struct hid_item {
 #define HID_QUIRK_BADPAD			0x00000020
 #define HID_QUIRK_MULTI_INPUT			0x00000040
 #define HID_QUIRK_HIDINPUT_FORCE		0x00000080
+#define HID_QUIRK_MULTITOUCH			0x00000100
 #define HID_QUIRK_SKIP_OUTPUT_REPORTS		0x00010000
 #define HID_QUIRK_FULLSPEED_INTERVAL		0x10000000
 #define HID_QUIRK_NO_INIT_REPORTS		0x20000000
-- 
1.7.4.4

[PATCH 2/2] decide if hid-multitouch needs to handle mt devices

[Benjamin Tissoires]

Now that hid-generic ignores all win7 compatible multitouch devices,
this patch allows hid-multitouch to catch them.
The idea is to rely on the quirk HID_QUIRK_MULTITOUCH to drop the
device if no ContactID is given.
There is the need for a blacklist here as other devices may need
a special driver (ntrig for instance).

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
---
 drivers/hid/hid-multitouch.c |   47 ++++++++++++++++++++++++++++++++++++++---
 1 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index a2c4bda..b82b83d 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -291,6 +291,7 @@ static int mt_input_mapping(struct hid_device *hdev, struct hid_input *hi,
 			td->last_slot_field = usage->hid;
 			td->last_field_index = field->index;
 			td->last_mt_collection = usage->collection_index;
+			hdev->quirks &= ~HID_QUIRK_MULTITOUCH;
 			return 1;
 		case HID_DG_WIDTH:
 			hid_map_usage(hi, usage, bit, max,
@@ -529,12 +530,44 @@ static void mt_set_input_mode(struct hid_device *hdev)
 	}
 }
 
+/* a list of devices for which there is a specialized multitouch driver */
+static const struct hid_device_id mt_have_special_driver[] = {
+	{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, 0x0001) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, 0x0006) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA,
+			USB_DEVICE_ID_PIXART_IMAGING_INC_OPTICAL_TOUCH_SCREEN) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_QUANTA,
+			USB_DEVICE_ID_QUANTA_OPTICAL_TOUCH) },
+	{ }
+};
+
+static bool mt_match_one_id(struct hid_device *hdev,
+		const struct hid_device_id *id)
+{
+	return id->bus == hdev->bus &&
+		(id->vendor == HID_ANY_ID || id->vendor == hdev->vendor) &&
+		(id->product == HID_ANY_ID || id->product == hdev->product);
+}
+
+static const struct hid_device_id *mt_match_id(struct hid_device *hdev,
+		const struct hid_device_id *id)
+{
+	for (; id->bus; id++)
+		if (mt_match_one_id(hdev, id))
+			return id;
+
+	return NULL;
+}
+
 static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
 {
 	int ret, i;
 	struct mt_device *td;
 	struct mt_class *mtclass = mt_classes; /* MT_CLS_DEFAULT */
 
+	if (mt_match_id(hdev, mt_have_special_driver))
+		return -ENODEV;
+
 	for (i = 0; mt_classes[i].name ; i++) {
 		if (id->driver_data == mt_classes[i].name) {
 			mtclass = &(mt_classes[i]);
@@ -542,10 +575,6 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
 		}
 	}
 
-	/* This allows the driver to correctly support devices
-	 * that emit events over several HID messages.
-	 */
-	hdev->quirks |= HID_QUIRK_NO_INPUT_SYNC;
 
 	td = kzalloc(sizeof(struct mt_device), GFP_KERNEL);
 	if (!td) {
@@ -561,10 +590,16 @@ static int mt_probe(struct hid_device *hdev, const struct hid_device_id *id)
 	if (ret != 0)
 		goto fail;
 
+	hdev->quirks |= HID_QUIRK_MULTITOUCH;
 	ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
 	if (ret)
 		goto fail;
 
+	/* This allows the driver to correctly support devices
+	 * that emit events over several HID messages.
+	 */
+	hdev->quirks |= HID_QUIRK_NO_INPUT_SYNC;
+
 	td->slots = kzalloc(td->maxcontacts * sizeof(struct mt_slot),
 				GFP_KERNEL);
 	if (!td->slots) {
@@ -749,6 +784,10 @@ static const struct hid_device_id mt_devices[] = {
 		HID_USB_DEVICE(USB_VENDOR_ID_UNITEC,
 			USB_DEVICE_ID_UNITEC_USB_TOUCH_0A19) },
 
+	/* Rest of the world */
+	{ .driver_data = MT_CLS_DEFAULT,
+		HID_USB_DEVICE(HID_ANY_ID, HID_ANY_ID) },
+
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, mt_devices);
-- 
1.7.4.4

Re: [PATCH 0/2] autodetection of multitouch devices

[Jiri Kosina]

On Wed, 21 Sep 2011, Benjamin Tissoires wrote:

> Hi Guys,
> 
> These two patches finally enable the kernel to handle multitouch devices correctly.
> If a device presents in its report descriptors the usage Contact ID, then it is considered as
> a multitouch device and handled by hid-multitouch.

Hi Banjamin,

thanks a lot for working on this. I have now queued the patches in my 
tree.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 0/2] autodetection of multitouch devices

[Henrik Rydberg]

On Mon, Sep 26, 2011 at 02:20:08PM +0200, Jiri Kosina wrote:
> On Wed, 21 Sep 2011, Benjamin Tissoires wrote:
> 
> > Hi Guys,
> > 
> > These two patches finally enable the kernel to handle multitouch devices correctly.
> > If a device presents in its report descriptors the usage Contact ID, then it is considered as
> > a multitouch device and handled by hid-multitouch.
> 
> Hi Banjamin,
> 
> thanks a lot for working on this. I have now queued the patches in my 
> tree.

Hi Benjamin,

Late as it seems, here are a couple of questions:

1. How was this tested? By removing all white-listed devices in
hid-multitouch.c to see if the usual suspects are still picked up?

2. Having the device blacklist inside hid-multitouch.c seems awkward.
I can see the benefits of putting it in a module, but is there any
other rationale? Right now the blacklist duplicates the hid whitelist.

Thanks,
Henrik

Re: [PATCH 0/2] autodetection of multitouch devices

[Jiri Kosina]

On Mon, 26 Sep 2011, Henrik Rydberg wrote:

> > > These two patches finally enable the kernel to handle multitouch devices correctly.
> > > If a device presents in its report descriptors the usage Contact ID, then it is considered as
> > > a multitouch device and handled by hid-multitouch.
> > 
> > Hi Banjamin,
> > 
> > thanks a lot for working on this. I have now queued the patches in my 
> > tree.
> 
> Hi Benjamin,
> 
> Late as it seems, here are a couple of questions:
> 
> 1. How was this tested? By removing all white-listed devices in
> hid-multitouch.c to see if the usual suspects are still picked up?

If we didn't have full test coverage (which I suppose to be the case), we 
can still revert to the old method after the merge window if there reports 
that this broke things on particular devices.

Do you guys at least have report descriptor dumps from most of the 
supported devices?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 0/2] autodetection of multitouch devices

[Stéphane Chatty]

Le 26 sept. 2011 à 16:47, Jiri Kosina a écrit :

> On Mon, 26 Sep 2011, Henrik Rydberg wrote:
> 
>>>> These two patches finally enable the kernel to handle multitouch devices correctly.
>>>> If a device presents in its report descriptors the usage Contact ID, then it is considered as
>>>> a multitouch device and handled by hid-multitouch.
>>> 
>>> Hi Banjamin,
>>> 
>>> thanks a lot for working on this. I have now queued the patches in my 
>>> tree.
>> 
>> Hi Benjamin,
>> 
>> Late as it seems, here are a couple of questions:
>> 
>> 1. How was this tested? By removing all white-listed devices in
>> hid-multitouch.c to see if the usual suspects are still picked up?
> 
> If we didn't have full test coverage (which I suppose to be the case), we 
> can still revert to the old method after the merge window if there reports 
> that this broke things on particular devices.
> 
> Do you guys at least have report descriptor dumps from most of the 
> supported devices?


Yes, we have report descriptors for about 20-30 different models now, and about 10 actual devices for testing purposes. Unfortunately, this still does not tell us exactly how all these devices manage to work with the same Win 7 driver, given their diversity. We are getting close, but just not yet.

BTW we gladly accept to receive sample panels from vendors, this usually ensures fast support. Additionally, the panels are then reused by ENAC students in their projects, so this stimulates the market of multitouch devices in aviation :-)

Cheers,

St.


--
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

Re: [PATCH 0/2] autodetection of multitouch devices

[Benjamin Tissoires]

On Wed, Sep 28, 2011 at 22:32, Stéphane Chatty <chatty@enac.fr> wrote:
>
> Le 26 sept. 2011 à 16:47, Jiri Kosina a écrit :
>
>> On Mon, 26 Sep 2011, Henrik Rydberg wrote:
>>
>>>>> These two patches finally enable the kernel to handle multitouch devices correctly.
>>>>> If a device presents in its report descriptors the usage Contact ID, then it is considered as
>>>>> a multitouch device and handled by hid-multitouch.
>>>>
>>>> Hi Banjamin,
>>>>
>>>> thanks a lot for working on this. I have now queued the patches in my
>>>> tree.
>>>
>>> Hi Benjamin,
>>>
>>> Late as it seems, here are a couple of questions:
>>>
>>> 1. How was this tested? By removing all white-listed devices in
>>> hid-multitouch.c to see if the usual suspects are still picked up?

Well, nearly all the devices that has been included since March passed
the first patch (I had it in my queue since a long time).
For now, only Stantum products are known to not work with this patch
if we remove them from hid_have_special_driver.

As for the blacklist problem, we also know that this is not very
beautiful, but we are working on a better solution. For the moment, it
just allows people to have their device working out of the box
(crossing fingers).

Cheers,
Benjamin


>>
>> If we didn't have full test coverage (which I suppose to be the case), we
>> can still revert to the old method after the merge window if there reports
>> that this broke things on particular devices.
>>
>> Do you guys at least have report descriptor dumps from most of the
>> supported devices?
>
>
> Yes, we have report descriptors for about 20-30 different models now, and about 10 actual devices for testing purposes. Unfortunately, this still does not tell us exactly how all these devices manage to work with the same Win 7 driver, given their diversity. We are getting close, but just not yet.
>
> BTW we gladly accept to receive sample panels from vendors, this usually ensures fast support. Additionally, the panels are then reused by ENAC students in their projects, so this stimulates the market of multitouch devices in aviation :-)
>
> Cheers,
>
> St.
>
>
>

Re: [PATCH 0/2] autodetection of multitouch devices

[Henrik Rydberg]

On Wed, Sep 28, 2011 at 11:25:38PM +0200, Benjamin Tissoires wrote:
> On Wed, Sep 28, 2011 at 22:32, Stéphane Chatty <chatty@enac.fr> wrote:
> >
> > Le 26 sept. 2011 à 16:47, Jiri Kosina a écrit :
> >
> >> On Mon, 26 Sep 2011, Henrik Rydberg wrote:
> >>
> >>>>> These two patches finally enable the kernel to handle multitouch devices correctly.
> >>>>> If a device presents in its report descriptors the usage Contact ID, then it is considered as
> >>>>> a multitouch device and handled by hid-multitouch.
> >>>>
> >>>> Hi Banjamin,
> >>>>
> >>>> thanks a lot for working on this. I have now queued the patches in my
> >>>> tree.
> >>>
> >>> Hi Benjamin,
> >>>
> >>> Late as it seems, here are a couple of questions:
> >>>
> >>> 1. How was this tested? By removing all white-listed devices in
> >>> hid-multitouch.c to see if the usual suspects are still picked up?
> 
> Well, nearly all the devices that has been included since March passed
> the first patch (I had it in my queue since a long time).
> For now, only Stantum products are known to not work with this patch
> if we remove them from hid_have_special_driver.

I see, thanks.

> As for the blacklist problem, we also know that this is not very
> beautiful, but we are working on a better solution. For the moment, it
> just allows people to have their device working out of the box
> (crossing fingers).

It is great that you share a working solution for most cases, but it
does not look like mainline material yet, does it. A clean solution
should probably modify the driver selection mechanism on a deeper
level, or at least make use of the current whitelist.

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