[PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Multitouch info was reported only via a old protocol used by the
proprietary X driver from elantech. Let's report the multitouch info
also following the official MT protocol.

This was done following the multi-touch-protocol.txt documentation, and
inspired by the bcm5974 implementation. Testing was light as there is
not many applications using this protocol yet, but the X synaptics
driver didn't complain and the X multitouch driver behaved correctly.

Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
---
 drivers/input/mouse/elantech.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 6a99b30..22978a9 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -253,7 +253,6 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 
 	/* byte 0: n1  n0   .   .   .   .   R   L */
 	fingers = (packet[0] & 0xc0) >> 6;
-	input_report_key(dev, BTN_TOUCH, fingers != 0);
 
 	switch (fingers) {
 	case 1:
@@ -268,6 +267,10 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 		 * byte 5: y7  y6  y5  y4  y3  y2  y1  y0
 		 */
 		y1 = ETP_YMAX_V2 - (((packet[4] & 0x03) << 8) | packet[5]);
+		input_report_abs(dev, ABS_MT_POSITION_X, x1);
+		input_report_abs(dev, ABS_MT_POSITION_Y, y1);
+		input_mt_sync(dev);
+
 		input_report_abs(dev, ABS_TOOL_WIDTH, width);
 		input_report_abs(dev, ABS_X, x1);
 		input_report_abs(dev, ABS_Y, y1);
@@ -290,6 +293,13 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 		x2 = ((packet[3] & 0x10) << 4) | packet[4];
 		/* byte 5: by7 by6 by5 by4 by3 by2 by1 by0 */
 		y2 = ETP_2FT_YMAX - (((packet[3] & 0x20) << 3) | packet[5]);
+		/* Multitouch */
+		input_report_abs(dev, ABS_MT_POSITION_X, x1 << 2);
+		input_report_abs(dev, ABS_MT_POSITION_Y, y1 << 2);
+		input_mt_sync(dev);
+		input_report_abs(dev, ABS_MT_POSITION_X, x2 << 2);
+		input_report_abs(dev, ABS_MT_POSITION_Y, y2 << 2);
+		input_mt_sync(dev);
 		/*
 		 * For compatibility with the X Synaptics driver scale up
 		 * one coordinate and report as ordinary mouse movent
@@ -307,6 +317,7 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 		break;
 	}
 
+	input_report_key(dev, BTN_TOUCH, fingers != 0);
 	input_report_key(dev, BTN_TOOL_FINGER, fingers == 1);
 	input_report_key(dev, BTN_TOOL_DOUBLETAP, fingers == 2);
 	input_report_key(dev, BTN_TOOL_TRIPLETAP, fingers == 3);
@@ -472,6 +483,8 @@ static void elantech_set_input_params(struct psmouse *psmouse)
 		input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2, ETP_WMAX_V2, 0, 0);
 		input_set_abs_params(dev, ABS_X, ETP_XMIN_V2, ETP_XMAX_V2, 0, 0);
 		input_set_abs_params(dev, ABS_Y, ETP_YMIN_V2, ETP_YMAX_V2, 0, 0);
+		input_set_abs_params(dev, ABS_MT_POSITION_X, ETP_XMIN_V2, ETP_XMAX_V2, 0, 0);
+		input_set_abs_params(dev, ABS_MT_POSITION_Y, ETP_YMIN_V2, ETP_YMAX_V2, 0, 0);
 		input_set_abs_params(dev, ABS_HAT0X, ETP_2FT_XMIN, ETP_2FT_XMAX, 0, 0);
 		input_set_abs_params(dev, ABS_HAT0Y, ETP_2FT_YMIN, ETP_2FT_YMAX, 0, 0);
 		input_set_abs_params(dev, ABS_HAT1X, ETP_2FT_XMIN, ETP_2FT_XMAX, 0, 0);
-- 
1.7.1


--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Dmitry Torokhov]

Hi Eric,

On Wed, May 05, 2010 at 02:20:46PM +0200, Éric Piel wrote:
> 
> Multitouch info was reported only via a old protocol used by the
> proprietary X driver from elantech. Let's report the multitouch info
> also following the official MT protocol.
> 
> This was done following the multi-touch-protocol.txt documentation, and
> inspired by the bcm5974 implementation. Testing was light as there is
> not many applications using this protocol yet, but the X synaptics
> driver didn't complain and the X multitouch driver behaved correctly.
> 
> Signed-off-by: Éric Piel <eric.piel@tremplin-utc.net>
> ---
>  drivers/input/mouse/elantech.c |   15 ++++++++++++++-
>  1 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 6a99b30..22978a9 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -253,7 +253,6 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>  
>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>  	fingers = (packet[0] & 0xc0) >> 6;
> -	input_report_key(dev, BTN_TOUCH, fingers != 0);

Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
looks good.

Henrik, should we report "tool width" as ABS_MT_WIDTH_MAJOR?

Eric, we don't have the "width" for the 2nd point of contact, do we?

Where is the proprietary driver BTW? Do we even care? I'd probably get
rid of HAT abuse if our standard tools provide good user experience.

>  
>  	switch (fingers) {
>  	case 1:
> @@ -268,6 +267,10 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>  		 * byte 5: y7  y6  y5  y4  y3  y2  y1  y0
>  		 */
>  		y1 = ETP_YMAX_V2 - (((packet[4] & 0x03) << 8) | packet[5]);
> +		input_report_abs(dev, ABS_MT_POSITION_X, x1);
> +		input_report_abs(dev, ABS_MT_POSITION_Y, y1);
> +		input_mt_sync(dev);
> +
>  		input_report_abs(dev, ABS_TOOL_WIDTH, width);
>  		input_report_abs(dev, ABS_X, x1);
>  		input_report_abs(dev, ABS_Y, y1);
> @@ -290,6 +293,13 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>  		x2 = ((packet[3] & 0x10) << 4) | packet[4];
>  		/* byte 5: by7 by6 by5 by4 by3 by2 by1 by0 */
>  		y2 = ETP_2FT_YMAX - (((packet[3] & 0x20) << 3) | packet[5]);
> +		/* Multitouch */
> +		input_report_abs(dev, ABS_MT_POSITION_X, x1 << 2);
> +		input_report_abs(dev, ABS_MT_POSITION_Y, y1 << 2);
> +		input_mt_sync(dev);
> +		input_report_abs(dev, ABS_MT_POSITION_X, x2 << 2);
> +		input_report_abs(dev, ABS_MT_POSITION_Y, y2 << 2);
> +		input_mt_sync(dev);
>  		/*
>  		 * For compatibility with the X Synaptics driver scale up
>  		 * one coordinate and report as ordinary mouse movent
> @@ -307,6 +317,7 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>  		break;
>  	}
>  
> +	input_report_key(dev, BTN_TOUCH, fingers != 0);
>  	input_report_key(dev, BTN_TOOL_FINGER, fingers == 1);
>  	input_report_key(dev, BTN_TOOL_DOUBLETAP, fingers == 2);
>  	input_report_key(dev, BTN_TOOL_TRIPLETAP, fingers == 3);
> @@ -472,6 +483,8 @@ static void elantech_set_input_params(struct psmouse *psmouse)
>  		input_set_abs_params(dev, ABS_TOOL_WIDTH, ETP_WMIN_V2, ETP_WMAX_V2, 0, 0);
>  		input_set_abs_params(dev, ABS_X, ETP_XMIN_V2, ETP_XMAX_V2, 0, 0);
>  		input_set_abs_params(dev, ABS_Y, ETP_YMIN_V2, ETP_YMAX_V2, 0, 0);
> +		input_set_abs_params(dev, ABS_MT_POSITION_X, ETP_XMIN_V2, ETP_XMAX_V2, 0, 0);
> +		input_set_abs_params(dev, ABS_MT_POSITION_Y, ETP_YMIN_V2, ETP_YMAX_V2, 0, 0);
>  		input_set_abs_params(dev, ABS_HAT0X, ETP_2FT_XMIN, ETP_2FT_XMAX, 0, 0);
>  		input_set_abs_params(dev, ABS_HAT0Y, ETP_2FT_YMIN, ETP_2FT_YMAX, 0, 0);
>  		input_set_abs_params(dev, ABS_HAT1X, ETP_2FT_XMIN, ETP_2FT_XMAX, 0, 0);


-- 
Dmitry
--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Op 05-05-10 18:38, Dmitry Torokhov schreef:
> Hi Eric,
> 
> On Wed, May 05, 2010 at 02:20:46PM +0200, Éric Piel wrote:
>>
:
>>  
>>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>>  	fingers = (packet[0] & 0xc0) >> 6;
>> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
> 
> Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
> looks good.
I moved it there because somehow I had understood in the
multi-touch-protocol that all the old events had to be reported after
the last SYNC_MT. That said, I don't recall any influence on the
synaptics nor multitouch X drivers. Maybe it matters just for the ABS_*
events?

> 
> Henrik, should we report "tool width" as ABS_MT_WIDTH_MAJOR?
> 
> Eric, we don't have the "width" for the 2nd point of contact, do we?
I looked a bit at the values generated when there are two touches, and
couldn't any changing when I was varying the pressure.

> Where is the proprietary driver BTW? Do we even care? I'd probably get
> rid of HAT abuse if our standard tools provide good user experience.
Actually I had never heard of a proprietary driver before reading the
code ;-) Maybe Florian knows?

Eric

--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Dmitry Torokhov]

On Wed, May 05, 2010 at 07:06:25PM +0200, Éric Piel wrote:
> Op 05-05-10 18:38, Dmitry Torokhov schreef:
> > Hi Eric,
> > 
> > On Wed, May 05, 2010 at 02:20:46PM +0200, Éric Piel wrote:
> >>
> :
> >>  
> >>  	/* byte 0: n1  n0   .   .   .   .   R   L */
> >>  	fingers = (packet[0] & 0xc0) >> 6;
> >> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
> > 
> > Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
> > looks good.
> I moved it there because somehow I had understood in the
> multi-touch-protocol that all the old events had to be reported after
> the last SYNC_MT. That said, I don't recall any influence on the
> synaptics nor multitouch X drivers. Maybe it matters just for the ABS_*
> events?

I was talking about mousedev - the in-kernel mouse emulation.

I do not believe the order of events shoudl matter for userspace, which
should collect all data until it receives EV_SYN/SYN_REPORT and then act
upon the collected data.

> 
> > 
> > Henrik, should we report "tool width" as ABS_MT_WIDTH_MAJOR?
> > 
> > Eric, we don't have the "width" for the 2nd point of contact, do we?
> I looked a bit at the values generated when there are two touches, and
> couldn't any changing when I was varying the pressure.
> 
> > Where is the proprietary driver BTW? Do we even care? I'd probably get
> > rid of HAT abuse if our standard tools provide good user experience.
> Actually I had never heard of a proprietary driver before reading the
> code ;-) Maybe Florian knows?
> 
> Eric
> 

-- 
Dmitry
--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Op 05-05-10 19:15, Dmitry Torokhov schreef:
> On Wed, May 05, 2010 at 07:06:25PM +0200, Éric Piel wrote:
>> Op 05-05-10 18:38, Dmitry Torokhov schreef:
>>> Hi Eric,
>>>
>>> On Wed, May 05, 2010 at 02:20:46PM +0200, Éric Piel wrote:
>>>>
>> :
>>>>  
>>>>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>>>>  	fingers = (packet[0] & 0xc0) >> 6;
>>>> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
>>>
>>> Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
>>> looks good.
>> I moved it there because somehow I had understood in the
>> multi-touch-protocol that all the old events had to be reported after
>> the last SYNC_MT. That said, I don't recall any influence on the
>> synaptics nor multitouch X drivers. Maybe it matters just for the ABS_*
>> events?
> 
> I was talking about mousedev - the in-kernel mouse emulation.
Oh... never thought on how the emulation was working!
> 
> I do not believe the order of events shoudl matter for userspace, which
> should collect all data until it receives EV_SYN/SYN_REPORT and then act
> upon the collected data.
Then it should be safe to put back BTN_TOUCH at the beginning. I can
send you a new version, with also ABS_MT_WIDTH_MAJOR if Henrik
recommends it.

See you,
Eric
--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Éric Piel wrote:
> Op 05-05-10 18:38, Dmitry Torokhov schreef:
>> Hi Eric,
>>
>> On Wed, May 05, 2010 at 02:20:46PM +0200, Éric Piel wrote:
> :
>>>  
>>>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>>>  	fingers = (packet[0] & 0xc0) >> 6;
>>> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
>> Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
>> looks good.
> I moved it there because somehow I had understood in the
> multi-touch-protocol that all the old events had to be reported after
> the last SYNC_MT. That said, I don't recall any influence on the
> synaptics nor multitouch X drivers. Maybe it matters just for the ABS_*
> events?

The "old" events can be reported anywhere in the sequence, it does not matter.

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Florian Ragwitz]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Wed, May 05, 2010 at 07:06:25PM +0200, Éric Piel wrote:
> Op 05-05-10 18:38, Dmitry Torokhov schreef:
> > Where is the proprietary driver BTW? Do we even care? I'd probably get
> > rid of HAT abuse if our standard tools provide good user experience.
> Actually I had never heard of a proprietary driver before reading the
> code ;-) Maybe Florian knows?

No, unfortunately he doesn't.

I've only ever heard of it through the comment in the current driver.
I've tried to find them, but failed.

git blames Arjan Opmeer <arjan@opmeer.net> for the comment, but he seems
a little unresponsive these days.


-- 
BOFH excuse #445:
Browser's cookie is corrupted -- someone's been nibbling on it.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Florian Ragwitz wrote:
> On Wed, May 05, 2010 at 07:06:25PM +0200, Éric Piel wrote:
>> Op 05-05-10 18:38, Dmitry Torokhov schreef:
>>> Where is the proprietary driver BTW? Do we even care? I'd probably get
>>> rid of HAT abuse if our standard tools provide good user experience.
>> Actually I had never heard of a proprietary driver before reading the
>> code ;-) Maybe Florian knows?
> 
> No, unfortunately he doesn't.
> 
> I've only ever heard of it through the comment in the current driver.
> I've tried to find them, but failed.
> 
> git blames Arjan Opmeer <arjan@opmeer.net> for the comment, but he seems
> a little unresponsive these days.
> 
> 

Speaking of proprietary drivers (sorry for going OT here), I am curious about
the development around synaptics. Has anyone seen any attempt to add MT events
for their new touchpads?

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Dmitry Torokhov]

On Wed, May 05, 2010 at 08:11:06PM +0200, Henrik Rydberg wrote:
> Florian Ragwitz wrote:
> > On Wed, May 05, 2010 at 07:06:25PM +0200, Éric Piel wrote:
> >> Op 05-05-10 18:38, Dmitry Torokhov schreef:
> >>> Where is the proprietary driver BTW? Do we even care? I'd probably get
> >>> rid of HAT abuse if our standard tools provide good user experience.
> >> Actually I had never heard of a proprietary driver before reading the
> >> code ;-) Maybe Florian knows?
> > 
> > No, unfortunately he doesn't.
> > 
> > I've only ever heard of it through the comment in the current driver.
> > I've tried to find them, but failed.
> > 
> > git blames Arjan Opmeer <arjan@opmeer.net> for the comment, but he seems
> > a little unresponsive these days.
> > 
> > 
> 
> Speaking of proprietary drivers (sorry for going OT here), I am curious about
> the development around synaptics. Has anyone seen any attempt to add MT events
> for their new touchpads?
> 

Unfortunately they are not willing/able/ready to disclose their MT
protocol so unless someone spends time and reverse-engineer it - not at
this moment.

-- 
Dmitry
--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Dmitry Torokhov wrote:
[...]
>>>
>> Speaking of proprietary drivers (sorry for going OT here), I am curious about
>> the development around synaptics. Has anyone seen any attempt to add MT events
>> for their new touchpads?
>>
> 
> Unfortunately they are not willing/able/ready to disclose their MT
> protocol so unless someone spends time and reverse-engineer it - not at
> this moment.
> 

What a delicious bait. :-)

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Dmitry Torokhov]

On Wed, May 05, 2010 at 08:29:47PM +0200, Henrik Rydberg wrote:
> Dmitry Torokhov wrote:
> [...]
> >>>
> >> Speaking of proprietary drivers (sorry for going OT here), I am curious about
> >> the development around synaptics. Has anyone seen any attempt to add MT events
> >> for their new touchpads?
> >>
> > 
> > Unfortunately they are not willing/able/ready to disclose their MT
> > protocol so unless someone spends time and reverse-engineer it - not at
> > this moment.
> > 
> 
> What a delicious bait. :-)

Yep, this is me, the great motivator ;)

-- 
Dmitry

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Dmitry Torokhov wrote:
>> @@ -253,7 +253,6 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>>  
>>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>>  	fingers = (packet[0] & 0xc0) >> 6;
>> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
> 
> Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
> looks good.
> 
> Henrik, should we report "tool width" as ABS_MT_WIDTH_MAJOR?

I might be missing some context here, I see no prior use of width in the driver.
The answer is either ABS_MT_TOUCH_MAJOR or ABS_MT_WIDTH_MAJOR depending on how
the width is actually computed. Generally, it makes little sense to have
ABS_MT_WIDTH_MAJOR (width of approaching finger) without ABS_MT_TOUCH_MAJOR
(width of touching finger), but it is ok to have only ABS_MT_TOUCH_MAJOR. Things
like thumb detection requires both values to be reliable.

Henrik

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Op 05-05-10 20:01, Henrik Rydberg schreef:
> Dmitry Torokhov wrote:
>>> @@ -253,7 +253,6 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>>>  
>>>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>>>  	fingers = (packet[0] & 0xc0) >> 6;
>>> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
>>
>> Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
>> looks good.
>>
>> Henrik, should we report "tool width" as ABS_MT_WIDTH_MAJOR?
> 
> I might be missing some context here, I see no prior use of width in the driver.
> The answer is either ABS_MT_TOUCH_MAJOR or ABS_MT_WIDTH_MAJOR depending on how
> the width is actually computed. Generally, it makes little sense to have
> ABS_MT_WIDTH_MAJOR (width of approaching finger) without ABS_MT_TOUCH_MAJOR
> (width of touching finger), but it is ok to have only ABS_MT_TOUCH_MAJOR. Things
> like thumb detection requires both values to be reliable.
Ok, so it seems in this case, ABS_MT_TOUCH_MAJOR is the most
appropriate... if we care at all.

Let me give you some more details. From what is seems, the hardware can
reports the width of a touch, but only when there is one single touch.
So far we report it via ABS_TOOL_WIDTH. When there is 2 or 3 touches,
the width is unknown. So the precise question is:
Should we report also ABS_MT_TOUCH_MAJOR in addition to ABS_TOOL_WIDTH,
whenever it is known (ie: one finger), or just not bother and only
report ABS_TOOL_WIDTH?

Eric

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Éric Piel wrote:
> Op 05-05-10 20:01, Henrik Rydberg schreef:
>> Dmitry Torokhov wrote:
>>>> @@ -253,7 +253,6 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
>>>>  
>>>>  	/* byte 0: n1  n0   .   .   .   .   R   L */
>>>>  	fingers = (packet[0] & 0xc0) >> 6;
>>>> -	input_report_key(dev, BTN_TOUCH, fingers != 0);
>>> Mousedev works a tad better if BTN_TOUCH is reported first. Otherwise
>>> looks good.
>>>
>>> Henrik, should we report "tool width" as ABS_MT_WIDTH_MAJOR?
>> I might be missing some context here, I see no prior use of width in the driver.
>> The answer is either ABS_MT_TOUCH_MAJOR or ABS_MT_WIDTH_MAJOR depending on how
>> the width is actually computed. Generally, it makes little sense to have
>> ABS_MT_WIDTH_MAJOR (width of approaching finger) without ABS_MT_TOUCH_MAJOR
>> (width of touching finger), but it is ok to have only ABS_MT_TOUCH_MAJOR. Things
>> like thumb detection requires both values to be reliable.
> Ok, so it seems in this case, ABS_MT_TOUCH_MAJOR is the most
> appropriate... if we care at all.
> 
> Let me give you some more details. From what is seems, the hardware can
> reports the width of a touch, but only when there is one single touch.
> So far we report it via ABS_TOOL_WIDTH. When there is 2 or 3 touches,
> the width is unknown. So the precise question is:
> Should we report also ABS_MT_TOUCH_MAJOR in addition to ABS_TOOL_WIDTH,
> whenever it is known (ie: one finger), or just not bother and only
> report ABS_TOOL_WIDTH?

With only partial information available it will not be of much use anyway, so
omitting ABS_MT_TOUCH is probably best. The ABS_TOOL_WIDTH will most likely not
be used by a driver either (it wont in the Multitouch X Driver anyways). The
synaptics driver cares for palm detection, but the scale has to be very specific
to work properly (i.e., requires testing with synaptics to be useful).

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Op 05-05-10 20:26, Henrik Rydberg schreef:
> Éric Piel wrote:
:
>> Let me give you some more details. From what is seems, the hardware can
>> reports the width of a touch, but only when there is one single touch.
>> So far we report it via ABS_TOOL_WIDTH. When there is 2 or 3 touches,
>> the width is unknown. So the precise question is:
>> Should we report also ABS_MT_TOUCH_MAJOR in addition to ABS_TOOL_WIDTH,
>> whenever it is known (ie: one finger), or just not bother and only
>> report ABS_TOOL_WIDTH?
> 
> With only partial information available it will not be of much use anyway, so
> omitting ABS_MT_TOUCH is probably best. The ABS_TOOL_WIDTH will most likely not
> be used by a driver either (it wont in the Multitouch X Driver anyways). The
> synaptics driver cares for palm detection, but the scale has to be very specific
> to work properly (i.e., requires testing with synaptics to be useful).
Thanks for clarifying!

BTW, does anyone know a graphical app which reads the MT events from a
/dev/input/eventX device and displays them as points in a window? That
would be rather helpful to reverse-engineer/debug multitouch hardwares.

Eric

--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Éric Piel wrote:
> 
> BTW, does anyone know a graphical app which reads the MT events from a
> /dev/input/eventX device and displays them as points in a window? That
> would be rather helpful to reverse-engineer/debug multitouch hardwares.

Something like fingermgmt in OSX? Not to my knowledge. The touchd project
includes some graphics via python, but is not based on MT events. Maybe our
friends at ENAC has something cooking?

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

Op 05-05-10 21:06, Henrik Rydberg schreef:
> Éric Piel wrote:
>>
>> BTW, does anyone know a graphical app which reads the MT events from a
>> /dev/input/eventX device and displays them as points in a window? That
>> would be rather helpful to reverse-engineer/debug multitouch hardwares.
> 
> Something like fingermgmt in OSX? Not to my knowledge. The touchd project
> includes some graphics via python, but is not based on MT events. Maybe our
> friends at ENAC has something cooking?

Thanks a lot for the tips.
I've hacked up an app which does just this, based on touchd and
pyinputevent.

Apparently when there are two fingers, the hardware doesn't report
really the finger coordinates but the lowest and highest points of the
rectangle defined by the two fingers.

For those who want to tinker too, attached is the source code of my
hack. Note that the synaptics driver grabs the event device so normally
you cannot receive anything. So you need to disable it, for instance
with a HAL rule like this:
 <?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.touchpad">
       <match key="info.product" contains="ETPS/2 Elantech Touchpad">
        <merge key="input.x11_driver" type="string">mult</merge>
       </match>
    </match>
  </device>
</deviceinfo>

Then a rmmod psmouse; modprobe psmouse should free the device. You also
need pyinputevent.py in the same directory.

See you,
Eric

[-- Attachment #2: fingerviewer.py --]
[-- Type: text/x-python, Size: 4774 bytes --]

# Copyright 2010, Eric Piel <eric.piel@tremplin-utc.net>

# This file contains part of touchd - 2008, Scott Shawcroft, scott.shawcroft@gmail.com
# This file uses pyinputevent available http://github.com/rmt/pyinputevent/ by Robert Thomson and individual contributors.

# FingerViewer is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 2 of the License, or
# (at your option) any later version.

# FingerViewer is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.

# You should have received a copy of the GNU General Public License
# along with FingerViewer.  If not, see <http://www.gnu.org/licenses/>.

# Runs the finger view window.
# use a command like:
# sudo python fingerviewer.py /dev/input/event1

import pygtk
import gtk
import math
import time
import threading, thread
from pyinputevent import *

gtk.gdk.threads_init()


class MouseDevice(SimpleDevice):
    """
    Report Multitouch events
    """
    def __init__(self, viewer, *args, **kwargs):
        SimpleDevice.__init__(self, *args, **kwargs)
        self.viewer = viewer
        self.x = 0
        self.y = 0
        self.num = 0
    def receive(self, event):
        etype, ecode, evalue = (
            event.etype,
            event.ecode,
            event.evalue,
        )
        #print "%s" % event
        if etype == 3:
            if ecode == 53:
                self.x = evalue
            elif ecode == 54:
                self.y = evalue
        elif etype == 0:
            if ecode == 2:
               viewer.got_finger(self.num, self.x, self.y, 0, 0, 10)
               self.num += 1
            elif ecode == 0:
               self.num = 0
            

class FingerViewer:
	def __init__(self):
		self.window = gtk.Window()
		self.window.set_title("Fingers")
		self.width = 400
		self.height = 200
		self.window.width = self.width
		self.window.height = self.height
		
		self.window.connect("destroy",self.hide)
		self.window.show()
		
		self.image = gtk.Image()
		self.image.show()
		self.window.add(self.image)
		
		pixmap = gtk.gdk.Pixmap(None,self.width,self.height,24)
		self.image.set_from_pixmap(pixmap,None)
		self.context = pixmap.cairo_create()
		self.context.rectangle(0,0,self.width,self.height)
		self.context.set_source_rgb(1,1,1)
		self.context.fill()
		
		self.context.set_line_width(2)
		
		self.fingers = []
	
	def got_finger(self,num,x,y,dx,dy,p):
		if num==0:
			# update the image
			self.draw_all()
		
		self.fingers.append((num,x,y,dx,dy,p))

	def draw_all(self):
		self.context.rectangle(0,0,self.width,self.height) # fill with white
		self.context.set_source_rgb(1,1,1)
		self.context.fill()
		
		for i in range(len(self.fingers)):
			num,x,y,dx,dy,p = self.fingers[i]
			self.draw_finger(num,x,y,dx,dy,p)
		
		self.image.queue_draw()
		self.fingers = []

	def draw_finger(self,num,x,y,dx,dy,p):
		dy*=-1
		
		# draw the finger
		tx = self.translate_x(x)
		ty = self.translate_y(y)
		self.context.arc(tx,ty,10+p/500.0*20,0,2*math.pi)
		self.context.set_source_rgba(0,0,1)
		self.context.fill()
		
		# draw the velocity
		VRES = 500
		VSCALE = 100
		self.context.set_source_rgb(0,0,0)
		self.context.move_to(tx,ty)
		self.context.line_to(tx+(float(dx)/VRES)*VSCALE,ty-(float(dy)/VRES)*VSCALE)
		self.context.stroke()
		
		# draw number label
		self.context.set_source_rgb(1,1,1)
		self.context.move_to(tx-5,ty+5)
		self.context.set_font_size(15)
		self.context.show_text(str(num+1))
	
	def num_fingers(self,i):
		if i==0:
			self._wipe()
	
	# translate to the graphical coordinates
	def translate_x(self,v):
		XRES = 1152
		return ((float(v)/XRES)*(self.width))
	
	# translate to the graphical coordinates
	def translate_y(self,v):
		YRES = 768
		YOFF = 0
		return ((float(v+YOFF)/YRES)*(self.height))
	
	def hide(self,widget):
		#self.window.hide()
                gtk.main_quit()

	def readValues(self, args):
            import select
            controller = Controller("Controller")
            fds = {}
            poll = select.poll()
            dev = args
            print dev
            dev = MouseDevice(self, dev)
            fds[dev.fileno()] = dev
            poll.register(dev, select.POLLIN | select.POLLPRI)
            while True:
                for x,e in poll.poll():
                    dev = fds[x]
                    dev.read()

if __name__ == "__main__":
    viewer = FingerViewer()
    threading.Thread(target=viewer.readValues, args=sys.argv[1:]).start()
    gtk.main()


# vim:shiftwidth=4:expandtab:spelllang=en_gb:spell:         

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Éric Piel wrote:
> Op 05-05-10 21:06, Henrik Rydberg schreef:
>> Éric Piel wrote:
>>> BTW, does anyone know a graphical app which reads the MT events from a
>>> /dev/input/eventX device and displays them as points in a window? That
>>> would be rather helpful to reverse-engineer/debug multitouch hardwares.
>> Something like fingermgmt in OSX? Not to my knowledge. The touchd project
>> includes some graphics via python, but is not based on MT events. Maybe our
>> friends at ENAC has something cooking?
> 
> Thanks a lot for the tips.
> I've hacked up an app which does just this, based on touchd and
> pyinputevent.

Thanks for the app, works nicely after adjusting the touchpad resolution to fit
my bcm5974.

Henrik

> Apparently when there are two fingers, the hardware doesn't report
> really the finger coordinates but the lowest and highest points of the
> rectangle defined by the two fingers.

I take it you are referring to the enumeration of the fingers, the order in
which they appear on the wire?

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Op 06-05-10 00:15, Henrik Rydberg schreef:
> Éric Piel wrote:
>> Op 05-05-10 21:06, Henrik Rydberg schreef:
:
>> Thanks a lot for the tips.
>> I've hacked up an app which does just this, based on touchd and
>> pyinputevent.
> 
> Thanks for the app, works nicely after adjusting the touchpad resolution to fit
> my bcm5974.
Cool! (actually it could be possible to read this resolution from the
input info on the device, to make the app more user-friendly)

>> Apparently when there are two fingers, the hardware doesn't report
>> really the finger coordinates but the lowest and highest points of the
>> rectangle defined by the two fingers.
> 
> I take it you are referring to the enumeration of the fingers, the order in
> which they appear on the wire?
No. What I mean is that one reported point always contains the maximum X
of the two coordinate and the maximum Y of the two coodinates, while the
other point always get the minimum of both.

So if you have the fingers like this:
-------------------
|                 |
|            A    |
|                 |
|     B           |
|                 |
-------------------
You get the actual values, but if you put your fingers like this:
-------------------
|                 |
|     A           |
|                 |
|            B    |
|                 |
-------------------
You get the same values as for the previous configuration!

I guess that for a lot of gestures it doesn't matter much...

Eric
--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Stéphane Chatty]

Le 5 mai 10 à 21:06, Henrik Rydberg a écrit :

> Éric Piel wrote:
>>
>> BTW, does anyone know a graphical app which reads the MT events  
>> from a
>> /dev/input/eventX device and displays them as points in a window?  
>> That
>> would be rather helpful to reverse-engineer/debug multitouch  
>> hardwares.
>
> Something like fingermgmt in OSX? Not to my knowledge. The touchd  
> project
> includes some graphics via python, but is not based on MT events.  
> Maybe our
> friends at ENAC has something cooking?

Unfortunately, we're at least one coder short in the group, and so  
far we've had to focus on low level code. I know that several distros  
have asked me about what kind of demos they could build, and even who  
they could get to code that for them, so there might be things  
brewing somewhere.

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Mohamed Ikbel Boulabiar]

Hi !

> Unfortunately, we're at least one coder short in the group, and so far we've
> had to focus on low level code. I know that several distros have asked me
> about what kind of demos they could build, and even who they could get to
> code that for them, so there might be things brewing somewhere.

I haven't heard of that, otherwize I could maybe helped.
I know someone making demos, not using multitouchd of X.org, but
reading from /dev/input/inputX in a Compiz plugin.
http://www.youtube.com/watch?v=eE56rdKtV5k


Mohamed-Ikbel

Re: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Mohamed Ikbel Boulabiar wrote:
> Hi !
> 
> Unfortunately, we're at least one coder short in the group, and so far we've
>> had to focus on low level code. I know that several distros have asked me
>> about what kind of demos they could build, and even who they could get to
>> code that for them, so there might be things brewing somewhere.
>>
> 
> I haven't heard of that, otherwize I could maybe helped.
> I know someone making demos, not using multitouchd of X.org, but reading
> from /dev/input/inputX in a Compiz plugin.
> http://www.youtube.com/watch?v=eE56rdKtV5k
> 
> 
> Mohamed-Ikbel
> 

Very nice look to it, reminding of Jeff Han's original demos.

Henrik

RE: [PATCH 2/2] elantech: Report multitouch with proper ABS_MT messages

[Hennerich, Michael]

Henrik Rydberg wrote on 2010-05-05:
> Éric Piel wrote:
>>
>> BTW, does anyone know a graphical app which reads the MT events from a
>> /dev/input/eventX device and displays them as points in a window? That
>> would be rather helpful to reverse-engineer/debug multitouch
> hardwares.
>
> Something like fingermgmt in OSX? Not to my knowledge. The touchd
> project includes some graphics via python, but is not based on MT
> events. Maybe our friends at ENAC has something cooking?
>
> Henrik
>

I've been playing with Benjamin's xf86-input-evdev multitouch-subdevs work.
http://cgit.freedesktop.org/~tissoire/xf86-input-evdev/log/?h=multitouch-subdevs

Its supports finger tracking ID and you can control multiple pointers on your X.
What's currently lacking is that xf86-input-evdev doesn't generate click events (something like a LEFT CLICK) for touches.

What also supports Linux MT events is Android Éclair
http://lukehutch.wordpress.com/2010/01/06/my-multi-touch-code-ported-to-eclair/

It Uses:
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
ABS_MT_TOUCH_MAJOR
ABS_MT_WIDTH_MAJOR

Without ABS_MT_TRACKING_ID.

Luke Hutchison wrote some basic MT demo applications, such as mtvisualizer.apk.
http://lukehutch.wordpress.com/2009/01/25/get-multi-touch-support-on-your-t-mobile-g1-today/


Greetings,
Michael

Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 4036 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif


--
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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Henrik Rydberg]

Hennerich, Michael wrote:
> Henrik Rydberg wrote on 2010-05-05:
>> Éric Piel wrote:
>>> BTW, does anyone know a graphical app which reads the MT events from a
>>> /dev/input/eventX device and displays them as points in a window? That
>>> would be rather helpful to reverse-engineer/debug multitouch
>> hardwares.
>>
>> Something like fingermgmt in OSX? Not to my knowledge. The touchd
>> project includes some graphics via python, but is not based on MT
>> events. Maybe our friends at ENAC has something cooking?
>>
>> Henrik
>>
> 
> I've been playing with Benjamin's xf86-input-evdev multitouch-subdevs work.
> http://cgit.freedesktop.org/~tissoire/xf86-input-evdev/log/?h=multitouch-subdevs
> 
> Its supports finger tracking ID and you can control multiple pointers on your X.
> What's currently lacking is that xf86-input-evdev doesn't generate click events (something like a LEFT CLICK) for touches.
> 
> What also supports Linux MT events is Android Éclair
> http://lukehutch.wordpress.com/2010/01/06/my-multi-touch-code-ported-to-eclair/
> 
> It Uses:
> ABS_MT_POSITION_X
> ABS_MT_POSITION_Y
> ABS_MT_TOUCH_MAJOR
> ABS_MT_WIDTH_MAJOR
> 
> Without ABS_MT_TRACKING_ID.
> 
> Luke Hutchison wrote some basic MT demo applications, such as mtvisualizer.apk.
> http://lukehutch.wordpress.com/2009/01/25/get-multi-touch-support-on-your-t-mobile-g1-today/

Thanks for the update on MT demos!

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 2/2] elantech: Report multitouch with proper ABS_MT messages

[Éric Piel]

Op 05-05-10 20:35, Éric Piel schreef:
:
> 
> BTW, does anyone know a graphical app which reads the MT events from a
> /dev/input/eventX device and displays them as points in a window? That
> would be rather helpful to reverse-engineer/debug multitouch hardwares.
Now that I have my little app, it was easier to test with the protocol.
When there are 3 fingers, there is only one coordinate reported, and it
is done in the same way as with one finger.

There might also be some additional info on the 5th and 6th bit of byte
3, and 5th to 8th bits of byte 4. No idea yet what they correspond to.

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