On Fri, Mar 9, 2012 at 5:26 PM, Jason Gerecke <killertofu@xxxxxxxxx> wrote:
> 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.
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.
>
>>
>> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
