hid-multitouch: change for touch height/width

hid-multitouch: change for touch height/width

[Jonathan Clarke]

Hi all,

I'd like to get your opinion on a proposal for a small change to the
hid-multitouch driver.  As you probably know this driver supports
multi touch input for various touchscreen/touchpad devices.

The change relates to lines 654 & 655 of "hid-multitouch.c" - I would
like to remove the "division by 2" applied to the "touch width" and
"touch height" values received from the input device.  These values
represent the width and height of the area occupied by a finger
touching the input device.

https://github.com/torvalds/linux/blame/master/drivers/
hid/hid-multitouch.c#L654

This division by 2 was added along with the the touch width/height
fields 6 years ago so that those fields "match the visual scale of the
touch" for a specific device (3M PCT) - see comment & associated
commit log for line 653.

I don't think that this scaling is appropriate for all the other devices
that this driver now supports.  On my screen for example (Elan
multitouch screen), the touch width and height reported bear no
relation to the "visual scale of the touch" with or without this /2
scaling applied.  I suspect that the scale of touch width/height
values reported are different for every device (though I've not
checked any other device).

The scaling is also discarding information about touch size (1 bit for
each of width/height) which is useful for any application that wants
to know about it.

So in summary I think the main questions for you are:
1. would making this change have a negative effect on any existing
applications that use this information?
2. does it seem sensible to (continue to) provide touch width/height
values that bear no relation to screen/pixel dimensions?

I delved into this because I wanted to get as much precision on touch
width/height as possible and was surprised at the low resolution of
sizes output by my touchscreen.  I got an extra 2 bits of precision
from my search!

Cheers & thanks for reading.  Jonathan

Re: hid-multitouch: change for touch height/width

[Benjamin Tissoires]

Hi Jonathan,

On Jan 24 2017 or thereabouts, Jonathan Clarke wrote:
> Hi all,
> 
> I'd like to get your opinion on a proposal for a small change to the
> hid-multitouch driver.  As you probably know this driver supports
> multi touch input for various touchscreen/touchpad devices.
> 
> The change relates to lines 654 & 655 of "hid-multitouch.c" - I would
> like to remove the "division by 2" applied to the "touch width" and
> "touch height" values received from the input device.  These values
> represent the width and height of the area occupied by a finger
> touching the input device.
> 
> https://github.com/torvalds/linux/blame/master/drivers/
> hid/hid-multitouch.c#L654
> 
> This division by 2 was added along with the the touch width/height
> fields 6 years ago so that those fields "match the visual scale of the
> touch" for a specific device (3M PCT) - see comment & associated
> commit log for line 653.
> 
> I don't think that this scaling is appropriate for all the other devices
> that this driver now supports.  On my screen for example (Elan
> multitouch screen), the touch width and height reported bear no
> relation to the "visual scale of the touch" with or without this /2
> scaling applied.  I suspect that the scale of touch width/height
> values reported are different for every device (though I've not
> checked any other device).
> 
> The scaling is also discarding information about touch size (1 bit for
> each of width/height) which is useful for any application that wants
> to know about it.
> 
> So in summary I think the main questions for you are:
> 1. would making this change have a negative effect on any existing
> applications that use this information?

It will have a negative effect on the particular models they were a fix
for. Luckily, the 3M panels already have a specific class for them, so I
wouldn't be against adding a quirk for those.

> 2. does it seem sensible to (continue to) provide touch width/height
> values that bear no relation to screen/pixel dimensions?

Unfortunately, that's what the hardware provides, and we can't do much
about it. IIRC Android has some table to match the incoming data with
proper values, and that's the only current solution. Miscorsoft enforced
a much better multitouch protocol in Windows 8, but failed at enforcing
the width and height of the contacts.

So, after a little bit of re-reading of
Documentation/input/multi-touch-protocol.txt, I also think we should get
rid of the divided by 2 in the generic case. WIDTH and HEIGHT are,
according to this document the diameters of the ellipses, so it makes no
sense to divide them by 2 (except in the 3M case, where the value was
too big).

So please submit a patch for this, and add a specific quirk in the MT_CLS_3M
class to divide by 2 the width and height.

Cheers,
Benjamin

> 
> I delved into this because I wanted to get as much precision on touch
> width/height as possible and was surprised at the low resolution of
> sizes output by my touchscreen.  I got an extra 2 bits of precision
> from my search!
> 
> Cheers & thanks for reading.  Jonathan

Re: hid-multitouch: change for touch height/width

[Jonathan Clarke]

Thanks for your thoughts Benjamin, all makes sense.  I'll submit a
patch in the next few days.

Cheers, Jonathan

On 25 January 2017 at 10:39, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> Hi Jonathan,
>
> On Jan 24 2017 or thereabouts, Jonathan Clarke wrote:
>> Hi all,
>>
>> I'd like to get your opinion on a proposal for a small change to the
>> hid-multitouch driver.  As you probably know this driver supports
>> multi touch input for various touchscreen/touchpad devices.
>>
>> The change relates to lines 654 & 655 of "hid-multitouch.c" - I would
>> like to remove the "division by 2" applied to the "touch width" and
>> "touch height" values received from the input device.  These values
>> represent the width and height of the area occupied by a finger
>> touching the input device.
>>
>> https://github.com/torvalds/linux/blame/master/drivers/
>> hid/hid-multitouch.c#L654
>>
>> This division by 2 was added along with the the touch width/height
>> fields 6 years ago so that those fields "match the visual scale of the
>> touch" for a specific device (3M PCT) - see comment & associated
>> commit log for line 653.
>>
>> I don't think that this scaling is appropriate for all the other devices
>> that this driver now supports.  On my screen for example (Elan
>> multitouch screen), the touch width and height reported bear no
>> relation to the "visual scale of the touch" with or without this /2
>> scaling applied.  I suspect that the scale of touch width/height
>> values reported are different for every device (though I've not
>> checked any other device).
>>
>> The scaling is also discarding information about touch size (1 bit for
>> each of width/height) which is useful for any application that wants
>> to know about it.
>>
>> So in summary I think the main questions for you are:
>> 1. would making this change have a negative effect on any existing
>> applications that use this information?
>
> It will have a negative effect on the particular models they were a fix
> for. Luckily, the 3M panels already have a specific class for them, so I
> wouldn't be against adding a quirk for those.
>
>> 2. does it seem sensible to (continue to) provide touch width/height
>> values that bear no relation to screen/pixel dimensions?
>
> Unfortunately, that's what the hardware provides, and we can't do much
> about it. IIRC Android has some table to match the incoming data with
> proper values, and that's the only current solution. Miscorsoft enforced
> a much better multitouch protocol in Windows 8, but failed at enforcing
> the width and height of the contacts.
>
> So, after a little bit of re-reading of
> Documentation/input/multi-touch-protocol.txt, I also think we should get
> rid of the divided by 2 in the generic case. WIDTH and HEIGHT are,
> according to this document the diameters of the ellipses, so it makes no
> sense to divide them by 2 (except in the 3M case, where the value was
> too big).
>
> So please submit a patch for this, and add a specific quirk in the MT_CLS_3M
> class to divide by 2 the width and height.
>
> Cheers,
> Benjamin
>
>>
>> I delved into this because I wanted to get as much precision on touch
>> width/height as possible and was surprised at the low resolution of
>> sizes output by my touchscreen.  I got an extra 2 bits of precision
>> from my search!
>>
>> Cheers & thanks for reading.  Jonathan