[PATCH 3/4] hid-multitouch: added support for Cypress TrueTouch panels

[PATCH 3/4] hid-multitouch: added support for Cypress TrueTouch panels

[Stephane Chatty]

Added support for Cypress TrueTouch panels, which detect up to 10 fingers

Signed-off-by: Stephane Chatty <chatty@enac.fr>

diff -rupN c/drivers/hid/hid-core.c d/drivers/hid/hid-core.c
--- c/drivers/hid/hid-core.c	2010-10-14 01:29:28.009936912 +0200
+++ d/drivers/hid/hid-core.c	2010-10-14 01:27:36.217937105 +0200
@@ -1301,6 +1301,7 @@ static const struct hid_device_id hid_bl
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_2) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_3) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE) },
+	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_TRUETOUCH) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, 0x0006) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1) },
diff -rupN c/drivers/hid/hid-ids.h d/drivers/hid/hid-ids.h
--- c/drivers/hid/hid-ids.h	2010-10-14 01:29:37.273937194 +0200
+++ d/drivers/hid/hid-ids.h	2010-10-14 01:27:06.485936905 +0200
@@ -176,6 +176,7 @@
 #define USB_DEVICE_ID_CYPRESS_BARCODE_1	0xde61
 #define USB_DEVICE_ID_CYPRESS_BARCODE_2	0xde64
 #define USB_DEVICE_ID_CYPRESS_BARCODE_3	0xbca1
+#define USB_DEVICE_ID_CYPRESS_TRUETOUCH	0xc001
 
 #define USB_VENDOR_ID_DEALEXTREAME	0x10c5
 #define USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701	0x819a
diff -rupN c/drivers/hid/hid-multitouch.c d/drivers/hid/hid-multitouch.c
--- c/drivers/hid/hid-multitouch.c	2010-10-14 01:31:48.572936984 +0200
+++ d/drivers/hid/hid-multitouch.c	2010-10-14 01:32:30.914936993 +0200
@@ -57,6 +57,7 @@ struct mt_class {
 /* classes of device behavior */
 #define DUAL1 0
 #define DUAL2 1
+#define CYPRESS 2
 
 /* contact data that only some devices report */
 #define PRESSURE 	(1 << 0)
@@ -77,10 +78,19 @@ static int slot_from_contactnumber(struc
 	return td->curcontact;
 }
 
+static int cypress_compute_slot(struct mt_device *td)
+{
+	if (td->curcontactid != 0 || td->curcontact == 0)
+		return td->curcontactid;
+	else 
+		return -1;
+}
+
 
 struct mt_class mt_classes[] = {
 	/* DUAL1 */		{ slot_from_contactid, 2, -1 },
 	/* DUAL2 */		{ slot_from_contactnumber, 2, -1 },
+	/* CYPRESS */		{ cypress_compute_slot, 10, 3 },
 };
 
 
@@ -379,6 +389,11 @@ static const struct hid_device_id mt_dev
 		HID_USB_DEVICE(USB_VENDOR_ID_CANDO,
 			USB_DEVICE_ID_CANDO_MULTI_TOUCH_11_6) },
 
+	/* Cypress panel */
+	{ .driver_data = CYPRESS,
+		HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
+			USB_DEVICE_ID_CYPRESS_TRUETOUCH) },
+
 	{ }
 };
 MODULE_DEVICE_TABLE(hid, mt_devices);

Re: [PATCH 3/4] hid-multitouch: added support for Cypress TrueTouch panels

[Henrik Rydberg]

On 10/14/2010 12:33 AM, Stephane Chatty wrote:

> Added support for Cypress TrueTouch panels, which detect up to 10 fingers
> 
> Signed-off-by: Stephane Chatty <chatty@enac.fr>
> 
> diff -rupN c/drivers/hid/hid-core.c d/drivers/hid/hid-core.c
> --- c/drivers/hid/hid-core.c	2010-10-14 01:29:28.009936912 +0200
> +++ d/drivers/hid/hid-core.c	2010-10-14 01:27:36.217937105 +0200
> @@ -1301,6 +1301,7 @@ static const struct hid_device_id hid_bl
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_2) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_3) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE) },
> +	{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_TRUETOUCH) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, 0x0006) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_DWAV, USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH1) },
> diff -rupN c/drivers/hid/hid-ids.h d/drivers/hid/hid-ids.h
> --- c/drivers/hid/hid-ids.h	2010-10-14 01:29:37.273937194 +0200
> +++ d/drivers/hid/hid-ids.h	2010-10-14 01:27:06.485936905 +0200
> @@ -176,6 +176,7 @@
>  #define USB_DEVICE_ID_CYPRESS_BARCODE_1	0xde61
>  #define USB_DEVICE_ID_CYPRESS_BARCODE_2	0xde64
>  #define USB_DEVICE_ID_CYPRESS_BARCODE_3	0xbca1
> +#define USB_DEVICE_ID_CYPRESS_TRUETOUCH	0xc001
>  
>  #define USB_VENDOR_ID_DEALEXTREAME	0x10c5
>  #define USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701	0x819a
> diff -rupN c/drivers/hid/hid-multitouch.c d/drivers/hid/hid-multitouch.c
> --- c/drivers/hid/hid-multitouch.c	2010-10-14 01:31:48.572936984 +0200
> +++ d/drivers/hid/hid-multitouch.c	2010-10-14 01:32:30.914936993 +0200
> @@ -57,6 +57,7 @@ struct mt_class {
>  /* classes of device behavior */
>  #define DUAL1 0
>  #define DUAL2 1
> +#define CYPRESS 2
>  
>  /* contact data that only some devices report */
>  #define PRESSURE 	(1 << 0)
> @@ -77,10 +78,19 @@ static int slot_from_contactnumber(struc
>  	return td->curcontact;
>  }
>  
> +static int cypress_compute_slot(struct mt_device *td)
> +{
> +	if (td->curcontactid != 0 || td->curcontact == 0)
> +		return td->curcontactid;
> +	else 
> +		return -1;
> +}


Returned slots should always be valid, since the intent is to actually report
data for the contact. If there is additional logic determining whether a touch
is valid, like here, it can simply be added to the validity computation.

> +
>  
>  struct mt_class mt_classes[] = {
>  	/* DUAL1 */		{ slot_from_contactid, 2, -1 },
>  	/* DUAL2 */		{ slot_from_contactnumber, 2, -1 },
> +	/* CYPRESS */		{ cypress_compute_slot, 10, 3 },
>  };
>  
>  
> @@ -379,6 +389,11 @@ static const struct hid_device_id mt_dev
>  		HID_USB_DEVICE(USB_VENDOR_ID_CANDO,
>  			USB_DEVICE_ID_CANDO_MULTI_TOUCH_11_6) },
>  
> +	/* Cypress panel */
> +	{ .driver_data = CYPRESS,
> +		HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS,
> +			USB_DEVICE_ID_CYPRESS_TRUETOUCH) },
> +
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(hid, mt_devices);


Cheers,
Henrik

Re: [PATCH 3/4] hid-multitouch: added support for Cypress TrueTouch panels

[Stéphane Chatty]

Le 14 oct. 10 à 14:06, Henrik Rydberg a écrit :
>>
>> +static int cypress_compute_slot(struct mt_device *td)
>> +{
>> +	if (td->curcontactid != 0 || td->curcontact == 0)
>> +		return td->curcontactid;
>> +	else
>> +		return -1;
>> +}
>
>
> Returned slots should always be valid, since the intent is to  
> actually report
> data for the contact. If there is additional logic determining  
> whether a touch
> is valid, like here, it can simply be added to the validity  
> computation.

Then you'd need a second device-specific function, one that  
determines if a contact is valid. I was trying to minimize that,  
especially because it would be for the sake of one device only.  
Managing it in the compute_slot function makes sense to me, giving  
this function the semantics of "is this contact a real slot, and if  
yes which is it?".

Maybe we could add somthing like td->curvalid = false to the  
computation function? This would not work in the current code, but  
maybe we can make it work.

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 3/4] hid-multitouch: added support for Cypress TrueTouch panels

[Henrik Rydberg]

On 10/14/2010 02:33 PM, Stéphane Chatty wrote:

> 
> Le 14 oct. 10 à 14:06, Henrik Rydberg a écrit :
>>>
>>> +static int cypress_compute_slot(struct mt_device *td)
>>> +{
>>> +    if (td->curcontactid != 0 || td->curcontact == 0)
>>> +        return td->curcontactid;
>>> +    else
>>> +        return -1;
>>> +}
>>
>>
>> Returned slots should always be valid, since the intent is to actually report
>> data for the contact. If there is additional logic determining whether a touch
>> is valid, like here, it can simply be added to the validity computation.
> 
> Then you'd need a second device-specific function, one that determines if a
> contact is valid. I was trying to minimize that, especially because it would be
> for the sake of one device only.


Now that single device clutters the logic for all other devices instead... We
could actually get away with zero device-specific functions, only branching on
the device class at a couple of places in the driver.

> Managing it in the compute_slot function makes
> sense to me, giving this function the semantics of "is this contact a real slot,
> and if yes which is it?".
> 
> Maybe we could add somthing like td->curvalid = false to the computation
> function? This would not work in the current code, but maybe we can make it work.


Another thing I forgot about: do all the currently included devices have good
contact ids, in the sense that they handle contacts during their lifetime? Are
there any examples other than ntrig where it does not work that way? I am of
course asking to see if we need to care about non-slotted devices.

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

Re: [PATCH 3/4] hid-multitouch: added support for Cypress TrueTouch panels

[Stéphane Chatty]

Le 14 oct. 10 à 14:54, Henrik Rydberg a écrit :

>>> Returned slots should always be valid, since the intent is to  
>>> actually report
>>> data for the contact. If there is additional logic determining  
>>> whether a touch
>>> is valid, like here, it can simply be added to the validity  
>>> computation.
>>
>> Then you'd need a second device-specific function, one that  
>> determines if a
>> contact is valid. I was trying to minimize that, especially  
>> because it would be
>> for the sake of one device only.
>
>
> Now that single device clutters the logic for all other devices  
> instead... We
> could actually get away with zero device-specific functions, only  
> branching on
> the device class at a couple of places in the driver.

Yes, but we don't know how many classes we'll get and might be safer  
to protect the core logic of the driver from people who'll want to  
add a new class.

Coming back to your point about the invalid slot number, I'll try to  
think about it again. Honestly, I'm pretty much at ease with the  
concept of overloading the return value of a function with a code for  
errors, because it is so common in Unix and Linux. And the overall  
meaning of the function is "is there any slot that corresponds to  
this contact?", which makes sense to me. But let's see if we can find  
a better way.


>> Managing it in the compute_slot function makes
>> sense to me, giving this function the semantics of "is this  
>> contact a real slot,
>> and if yes which is it?".
>>
>> Maybe we could add somthing like td->curvalid = false to the  
>> computation
>> function? This would not work in the current code, but maybe we  
>> can make it work.
>
>
> Another thing I forgot about: do all the currently included devices  
> have good
> contact ids, in the sense that they handle contacts during their  
> lifetime? Are
> there any examples other than ntrig where it does not work that  
> way? I am of
> course asking to see if we need to care about non-slotted devices.

NTrig is alone in its class so far.

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