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

On Thu, Mar 15, 2012 at 8:22 PM, Chris Bagwell [off-list ref] wrote:

On Thu, Mar 15, 2012 at 7:10 PM, Jason Gerecke [off-list ref] wrote:

quoted

On Mon, Mar 12, 2012 at 3:41 PM, Chris Bagwell [off-list ref] wrote:

quoted

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

quoted

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

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

I did a little more testing, and it looks like data[5] is proportional
to the area (not linear dimension) of the touch. Given the intended
semantics (and ignoring the huge blobs it produces in mtview),
int_sqrt(data[5] << 13) seems to work well. We'd probably have to
increase the maximum to 512 or 1024 though since I've been able to get
my palm to produce values of ~600...

Also, I don't yet know how these values scale between tablet sizes --
I imagine smaller tablets produce larger values (since their sensors
are denser), but haven't been able to get my hands on other hardware
yet.

You've already given it much more thought than I but I made the
following assumption a little bit related.  The sensors report X/Y
maximums of 4096 even though its a rectangle tablet. Thats why I made
sure resolution was reported proportionally.  Here is from Xorg log of
my medium size tablet:

 (--) Wacom Wireless Receiver Finger pad: Wacom Unknown USB tablet
maxX=4096 maxY=4096 maxZ=0 resX=18000 resY=29000

I suspect that same ratio also applies to width reporting as well.

I'm also guessing the value of size is really defining an ellipse with
fixed orientation.  But we can't really expose that to user as
WIDTH_MINOR because it will be incorrectly interrupted as a pressure
estimate.

But I suspect the above resolution calculation will help push the
scaling issue to user land and we can concentrate on reporting
something like the int_sqrt() values you've come up with.

Chris

Whoops. Looks like this fell off my radar.

So, if I were to adjust the uncorrected width by the aspect ratio to
get values for ABS_MT_TOUCH_MAJOR and ABS_MT_TOUCH_MINOR, would that
be correct? For example, should placing a quarter (diameter of
24.26mm) on my Intuos5 Medium (logical size: 4096 x 4096, physical
size: 223mm x 139mm) ideally report a contact with a MAJOR axis of 714
and MINOR axis of 445?

Jason

---
Day xee-nee-svsh duu-'ushtlh-ts'it;
nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it.
Huu-chan xuu naa~-gha.
--
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