On Thu, Mar 15, 2012 at 7:10 PM, Jason Gerecke <killertofu@xxxxxxxxx> wrote:
> 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.
>
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
--
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
