Re: [PATCH] input: wacom: Use touch size for ABS_MT_TOUCH_MAJOR

On Fri, Mar 9, 2012 at 5:26 PM, Jason Gerecke [off-list ref] wrote:

On Fri, Mar 9, 2012 at 2:30 PM, Chris Bagwell [off-list ref] wrote:

quoted

On Wed, Mar 7, 2012 at 7:39 PM, Jason Gerecke [off-list ref] wrote:

quoted

3rd-gen Bamboo devices report both "amplitude" and "size" data
in their touch packets. This patch changes the source for
ABS_MT_TOUCH_MAJOR to be the latter rather than the former.
---
 drivers/input/tablet/wacom_wac.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index d0b0fc4..5daf11d 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c

@@ -916,7 +916,7 @@ static void wacom_bpt3_touch_msg(struct wacom_wac *wacom, unsigned char *data)

       if (touch) {
               int x = (data[2] << 4) | (data[4] >> 4);
               int y = (data[3] << 4) | (data[4] & 0x0f);
-               int w = data[6];
+               int w = data[5];

               input_report_abs(input, ABS_MT_POSITION_X, x);
               input_report_abs(input, ABS_MT_POSITION_Y, y);
--
1.7.9.1

I found time to test this patch and used "mtview" so I could get some
visual feedback.

The lines because extremely thin with this change.  Part of reason I
quickly traced to we are setting range as 0-255 but I couldn't get
data[5] to go above a value of 18.  So I changed range to 0-16 and it
works better but the lines still never gets very thick (this could
well be that mtview doesn't scale values and prefers 0-255.  I didn't
look).

Looks like its a combination of two problems, one mine one mtview's...

I did some reading, and the MT protocol docs specify that
ABS_MT_TOUCH_MAJOR are in terms of surface units. That means a value
of e.g. "20" should represent a touch that spans 20 units of X. The
touch sensor has a resolution of ~0.1mm, which would imply the touch
was only 2 mm wide... There's going to have to be a correction factor
to transform the value to something more appropriate.

As for mtview, it looks like it doesn't scale the major/minor axis
values based on the output size. At the very least it should scale
everything by roughly (output_max_x / sensor_max_x) so that a touch
taking up e.g. 10% of the tablet would take up 10% of the output.

I see now that I got lucky that I had a 0-255 value available and
didn't look into what I needed to report close enough.

quoted

Amplitude feels better to me using test apps but your in a better
position to say if we should really change this.  Please adjust
declared range though if you still think we should change this.

Chris

My main reasons for switching away from amplitude were that amplitude
is a very crude number (I think I can get three or four unique values
out of it), and that the tablet reports a size already. Worst case --
assuming a correction factor isn't sufficient to get data[5] working
as MAJOR -- we should at least send data[5] through PRESSURE (which
the MT docs state may be used instead of MAJOR/MINOR if the units are
arbitrary).

I've not found time to dig deeply to this (to compute real scale
value) but I'll offer this.  I compared behaviour of original data[6]
to this:

int w = (data[5] > 31) ? 255 : data[5] << 3;

and with mtview the size change is much more responsive and
consistent.  So I'm on board with changing to data[5] in some form.

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