On Mon, Mar 12, 2012 at 3:41 PM, Chris Bagwell <chris@xxxxxxxxxxxxxx> wrote:
> 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
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.
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
