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
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
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
[off-list ref] wrote:
Hi Jonathan,
On Jan 24 2017 or thereabouts, Jonathan Clarke wrote:
quoted
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.
quoted
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
quoted
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