Re: [RFC] Multi-Touch (MT) support - arbitration or not

[Henrik Rydberg <rydberg@euromail.se>]

On 11/11/2010 12:53 AM, Peter Hutterer wrote:

> On Wed, Nov 10, 2010 at 11:00:05AM +0100, Henrik Rydberg wrote:
>> A comment on pixels and resolution:
>>
>> A pen and a thumb may have different resolution (signal-to-noise ratio), but
>> there is no reason they cannot be reported on the same scale. In fact, it could
>> be argued that it is natural for objects on the same surface to be reported in
>> the coordinate system of the surface.
> 
> it may be natural from a human perspective, but the computer doesn't care
> about it.


The fact that we discuss a computer protocol suggests the computer does care.
;-) The question is whether we need to be able to support different scales for
different tools types. I argue that among the three things value range, physical
range and SN ratio, the one most naturally seen as an attribute of a tool is the
SN ratio.

> And given that most input device interpretation is done in
> software, the scale used doesn't matter as long as it's correct.

> in the UI, even with different ranges for different tools, top-left should
> refer to whatever coordinate that is.
> 
> in other words, if the pure numbers matter in the UI, we've done something
> wrong.

> 
> what benefit do we get from reporting tools on the same scale if the HW
> doesn't do so?


The question is, given a set of tool types reported via MT events, what
additional information is needed. Having tools share the same ABS axes, I would
like to see that as a good thing. So what is missing from that picture?

>> So, if anything, the resolution is object/sensor dependent, and adding a
>> possibility to specify resolution per object type would be good. It would also
>> be good to know the physical dimensions of the surface.
> 
> well, the physical dimensions are exported through the resolution, isn't it?
> if I have a range of 0-1000 and a resolution of 100 units per cm, I can
> guesstimate the phys size of the device.


I see, we are apparently using different meanings of resolution. I meant
signal-to-noise ratio, the number of distinctly measurable different values. If
you mean how many ticks on your scale there are in an inch, you are of course
right. The SN ratio is still unknown, though - that would be how many
_different_ ticks there are in an inch.


> I know that in the X protocol resolution is specified in units/m, but given
> previous threads the kernel seems to be ambiguous here, alternating between
> in and mm.


Using finger width is another means of estimation.

Cheers,
Henrik