On Fri, Mar 9, 2012 at 2:30 PM, Chris Bagwell <chris@xxxxxxxxxxxxxx> wrote:
> On Wed, Mar 7, 2012 at 7:39 PM, Jason Gerecke <killertofu@xxxxxxxxx> wrote:
>> 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.
>
> 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).
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
