[PATCH 1/2] elantech: Report tool width when it is known

[PATCH 1/2] elantech: Report tool width when it is known

[Éric Piel]

>From observation of the values sent from the hardware version 2, it
seems that the first four bits of byte 1 represents the width. So we can
report it as well. Observed values on my hardware were always between 1
and 12, so let's use this for min and max.

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

diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 0520c2e..6a99b30 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -249,7 +249,7 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 {
 	struct input_dev *dev = psmouse->dev;
 	unsigned char *packet = psmouse->packet;
-	int fingers, x1, y1, x2, y2;
+	int fingers, x1, y1, x2, y2, width;
 
 	/* byte 0: n1  n0   .   .   .   .   R   L */
 	fingers = (packet[0] & 0xc0) >> 6;
@@ -258,17 +258,19 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 	switch (fingers) {
 	case 1:
 		/*
-		 * byte 1:  .   .   .   .   .  x10 x9  x8
+		 * byte 1: w3  w2  w1  w0   .  x10 x9  x8
 		 * byte 2: x7  x6  x5  x4  x4  x2  x1  x0
 		 */
-		input_report_abs(dev, ABS_X,
-			((packet[1] & 0x07) << 8) | packet[2]);
+		width = ((packet[1] & 0xf0) >> 4);
+		x1 = ((packet[1] & 0x07) << 8) | packet[2];
 		/*
 		 * byte 4:  .   .   .   .   .   .  y9  y8
 		 * byte 5: y7  y6  y5  y4  y3  y2  y1  y0
 		 */
-		input_report_abs(dev, ABS_Y,
-			ETP_YMAX_V2 - (((packet[4] & 0x03) << 8) | packet[5]));
+		y1 = ETP_YMAX_V2 - (((packet[4] & 0x03) << 8) | packet[5]);
+		input_report_abs(dev, ABS_TOOL_WIDTH, width);
+		input_report_abs(dev, ABS_X, x1);
+		input_report_abs(dev, ABS_Y, y1);
 		break;
 
 	case 2:
@@ -286,7 +288,7 @@ static void elantech_report_absolute_v2(struct psmouse *psmouse)
 		 * byte 4: bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0
 		 */
 		x2 = ((packet[3] & 0x10) << 4) | packet[4];
-		/* byte 5: by7 by8 by5 by4 by3 by2 by1 by0 */
+		/* byte 5: by7 by6 by5 by4 by3 by2 by1 by0 */
 		y2 = ETP_2FT_YMAX - (((packet[3] & 0x20) << 3) | packet[5]);
 		/*
 		 * For compatibility with the X Synaptics driver scale up
@@ -467,6 +469,7 @@ static void elantech_set_input_params(struct psmouse *psmouse)
 		break;
 
 	case 2:
+		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_HAT0X, ETP_2FT_XMIN, ETP_2FT_XMAX, 0, 0);
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index feac5f7..2ce79c1 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -76,6 +76,8 @@
 #define ETP_XMAX_V2			(1152 - ETP_EDGE_FUZZ_V2)
 #define ETP_YMIN_V2			(   0 + ETP_EDGE_FUZZ_V2)
 #define ETP_YMAX_V2			( 768 - ETP_EDGE_FUZZ_V2)
+#define ETP_WMIN_V2			0
+#define ETP_WMAX_V2			12
 
 /*
  * For two finger touches the coordinate of each finger gets reported
-- 
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 1/2] elantech: Report tool width when it is known

[Dmitry Torokhov]

On Wed, May 05, 2010 at 02:14:25PM +0200, Éric Piel wrote:
> >From observation of the values sent from the hardware version 2, it
> seems that the first four bits of byte 1 represents the width. So we can
> report it as well. Observed values on my hardware were always between 1
> and 12, so let's use this for min and max.
> 

I think we shoudl have threshold for the firmware version when we start
reporting the width.

-- 
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 1/2] elantech: Report tool width when it is known

[Florian Ragwitz]

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

On Wed, May 05, 2010 at 02:14:25PM +0200, Éric Piel wrote:
> >From observation of the values sent from the hardware version 2, it
> seems that the first four bits of byte 1 represents the width. So we can
> report it as well. Observed values on my hardware were always between 1
> and 12, so let's use this for min and max.

Excellent. I'm quite happy to see this.

I've actually thought about reporting some kind of width based on the
"thumb" bit in the first byte. The actual width information being
available didn't occur to me for some reason.

The patch itself looks just fine to me, but it might also want to update
the elantech documentation accordingly.

See also https://patchwork.kernel.org/patch/95448/ which isn't part of
the -input tree yet.


-- 
BOFH excuse #362:
Plasma conduit breach

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

Re: [PATCH 1/2] elantech: Report tool width when it is known

[Éric Piel]

Op 05-05-10 18:39, Dmitry Torokhov schreef:
> On Wed, May 05, 2010 at 02:14:25PM +0200, Éric Piel wrote:
>> >From observation of the values sent from the hardware version 2, it
>> seems that the first four bits of byte 1 represents the width. So we can
>> report it as well. Observed values on my hardware were always between 1
>> and 12, so let's use this for min and max.
>>
> 
> I think we shoudl have threshold for the firmware version when we start
> reporting the width.
> 
What do you mean? That the width might not be reported correctly by all
the firmwares? I have no idea if that is the case. For info, IIRC my
firmware report 2.1 with middle byte 8.

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 1/2] elantech: Report tool width when it is known

[Dmitry Torokhov]

On Wed, May 05, 2010 at 06:53:24PM +0200, Florian Ragwitz wrote:
> On Wed, May 05, 2010 at 02:14:25PM +0200, Éric Piel wrote:
> > >From observation of the values sent from the hardware version 2, it
> > seems that the first four bits of byte 1 represents the width. So we can
> > report it as well. Observed values on my hardware were always between 1
> > and 12, so let's use this for min and max.
> 
> Excellent. I'm quite happy to see this.
> 
> I've actually thought about reporting some kind of width based on the
> "thumb" bit in the first byte. The actual width information being
> available didn't occur to me for some reason.
> 
> The patch itself looks just fine to me, but it might also want to update
> the elantech documentation accordingly.
> 
> See also https://patchwork.kernel.org/patch/95448/ which isn't part of
> the -input tree yet.
> 

It is - I folded it with the changes to the driver and it is upstream. I
left out the new 4.1 signature patch until we know better about firmware
versions, but otherwise your changes are in mainline.

-- 
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 1/2] elantech: Report tool width when it is known

[Dmitry Torokhov]

On Wed, May 05, 2010 at 06:58:18PM +0200, Éric Piel wrote:
> Op 05-05-10 18:39, Dmitry Torokhov schreef:
> > On Wed, May 05, 2010 at 02:14:25PM +0200, Éric Piel wrote:
> >> >From observation of the values sent from the hardware version 2, it
> >> seems that the first four bits of byte 1 represents the width. So we can
> >> report it as well. Observed values on my hardware were always between 1
> >> and 12, so let's use this for min and max.
> >>
> > 
> > I think we shoudl have threshold for the firmware version when we start
> > reporting the width.
> > 
> What do you mean? That the width might not be reported correctly by all
> the firmwares? I have no idea if that is the case. For info, IIRC my
> firmware report 2.1 with middle byte 8.
> 

My understanding was that older firmwares would report 0. I might be
mistaken.

-- 
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 1/2] elantech: Report tool width when it is known

[Florian Ragwitz]

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

On Wed, May 05, 2010 at 10:13:50AM -0700, Dmitry Torokhov wrote:
> On Wed, May 05, 2010 at 06:58:18PM +0200, Éric Piel wrote:
> > Op 05-05-10 18:39, Dmitry Torokhov schreef:
> > > I think we shoudl have threshold for the firmware version when we start
> > > reporting the width.
> > >
> > What do you mean? That the width might not be reported correctly by all
> > the firmwares? I have no idea if that is the case. For info, IIRC my
> > firmware report 2.1 with middle byte 8.
>
> My understanding was that older firmwares would report 0. I might be
> mistaken.

Some firmwares always set the upper bits to 0. Others don't.

As far as I can see, we only know about firmware version 2.1 and 4.1
using those high bits for width reports.

However, there's firmware versions inbetween, like 2.48, which don't
report width information. And there's even other firmware versions
inbetween, like 2.36, which actually implment what the driver calls
hardware version 1. Those have a quite different packet format, and also
no width information.

Currently it seems to be unknown how to detect hw ver 1 vs. 2 based on
the firmware version. Guesses tend towards the middle bit being
signifficant, somehow.


-- 
BOFH excuse #136:
Daemons loose in system.

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

Re: [PATCH 1/2] elantech: Report tool width when it is known

[Dmitry Torokhov]

On Wednesday 05 May 2010 11:00:48 am Florian Ragwitz wrote:
> On Wed, May 05, 2010 at 10:13:50AM -0700, Dmitry Torokhov wrote:
> > On Wed, May 05, 2010 at 06:58:18PM +0200, Éric Piel wrote:
> > > Op 05-05-10 18:39, Dmitry Torokhov schreef:
> > > > I think we shoudl have threshold for the firmware version when we
> > > > start reporting the width.
> > > 
> > > What do you mean? That the width might not be reported correctly by all
> > > the firmwares? I have no idea if that is the case. For info, IIRC my
> > > firmware report 2.1 with middle byte 8.
> > 
> > My understanding was that older firmwares would report 0. I might be
> > mistaken.
> 
> Some firmwares always set the upper bits to 0. Others don't.
> 
> As far as I can see, we only know about firmware version 2.1 and 4.1
> using those high bits for width reports.
> 
> However, there's firmware versions inbetween, like 2.48, which don't
> report width information. And there's even other firmware versions
> inbetween, like 2.36, which actually implment what the driver calls
> hardware version 1. Those have a quite different packet format, and also
> no width information.

What we need to figure out if 2.48 and 2.36 are in fact something like
2.0.48 and 2.0.36.. And 2.1 is actually 2.x.1. Then it would all make
better sense.

> 
> Currently it seems to be unknown how to detect hw ver 1 vs. 2 based on
> the firmware version. Guesses tend towards the middle bit being
> signifficant, somehow.

-- 
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 1/2] elantech: Report tool width when it is known

[Éric Piel]

Op 05-05-10 20:09, Dmitry Torokhov schreef:
> On Wednesday 05 May 2010 11:00:48 am Florian Ragwitz wrote:
:
>> Some firmwares always set the upper bits to 0. Others don't.
>>
>> As far as I can see, we only know about firmware version 2.1 and 4.1
>> using those high bits for width reports.
>>
>> However, there's firmware versions inbetween, like 2.48, which don't
>> report width information. And there's even other firmware versions
>> inbetween, like 2.36, which actually implment what the driver calls
>> hardware version 1. Those have a quite different packet format, and also
>> no width information.
> 
> What we need to figure out if 2.48 and 2.36 are in fact something like
> 2.0.48 and 2.0.36.. And 2.1 is actually 2.x.1. Then it would all make
> better sense.
Could it be that the ability of detecting width is indicated in the
capability bytes? Here I have 0x08 0x13 0x0d .

Eric