* Re: ABS_MT_TOUCH_MAJOR metric
2014-05-22 19:29 ` Ferruh Yigit
@ 2014-05-22 19:42 ` Dmitry Torokhov
2014-05-22 19:45 ` Michael Wright
2014-05-22 19:46 ` Henrik Rydberg
2 siblings, 0 replies; 6+ messages in thread
From: Dmitry Torokhov @ 2014-05-22 19:42 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: linux-input@vger.kernel.org, Henrik Rydberg
On Thu, May 22, 2014 at 10:29:43PM +0300, Ferruh Yigit wrote:
> On 05/22/2014 08:23 PM, Dmitry Torokhov wrote:
> > Hi Ferruh,
> >
> > On Thu, May 22, 2014 at 02:03:40PM +0300, Ferruh Yigit wrote:
> >> Hi,
> >>
> >> What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?
> >>
> >> The Linux documentation
> >> <https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
> >> "The length of the major axis of the contact. The length should be given
> >> in surface units. ..."
> >>
> >> What does "surface units" means, is it millimeter or pixels?
> > It is whatever unit the device reports, similarly to ABS_MT_POSITION_X
> > and ABS_MT_POSITION_Y. Userspace can use EVIOCGABS to map device units
> > onto common units.
> >
> > From include/uapi/linux/input.h (struct input_absinfo):
> >
> > * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
> > * units per millimeter (units/mm), resolution for rotational axes
> > * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
> >
> > Hope this helps.
> >
> Hi Dmitry,
>
> I understand this works for Dmitry ABS_X, ABS_Y,
> touchscreen reports between 0..A, screen resolution is 0..B, a mapping
> can be done 0..A -> 0..B
>
> But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
> touchscreen reports between 0..A, do we know the min/max values for
> application side?
I believe in normal (all?) cases we'd use the same resolution iand
limits for ABS_MT_TOUCH_MAJOR/MINOR and ABS_X/Y and kernel not report
any mix/max on ABS_MT_TOUCH_MAJOR/MINOR.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ABS_MT_TOUCH_MAJOR metric
2014-05-22 19:29 ` Ferruh Yigit
2014-05-22 19:42 ` Dmitry Torokhov
@ 2014-05-22 19:45 ` Michael Wright
2014-05-22 19:46 ` Henrik Rydberg
2 siblings, 0 replies; 6+ messages in thread
From: Michael Wright @ 2014-05-22 19:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Dmitry Torokhov, linux-input@vger.kernel.org, Henrik Rydberg
Yes, you do know the min / max values via EVICGABS. That being said,
you don't want to use these values to scale from surface units to
screen coordinates, as those only tell you the max reported width.
ABS_MT_TOUCH_MAJOR should be in the same units that ABS_X and ABS_Y
are for that device, so you should use those scaling values to do the
mapping. Theoretically the resolution should be exactly the same for
both, if you want to do the conversion into physical units (i.e. mm).
On Thu, May 22, 2014 at 12:29 PM, Ferruh Yigit <fery@cypress.com> wrote:
> On 05/22/2014 08:23 PM, Dmitry Torokhov wrote:
>> Hi Ferruh,
>>
>> On Thu, May 22, 2014 at 02:03:40PM +0300, Ferruh Yigit wrote:
>>> Hi,
>>>
>>> What is the metric of ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR events?
>>>
>>> The Linux documentation
>>> <https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt> says:
>>> "The length of the major axis of the contact. The length should be given
>>> in surface units. ..."
>>>
>>> What does "surface units" means, is it millimeter or pixels?
>> It is whatever unit the device reports, similarly to ABS_MT_POSITION_X
>> and ABS_MT_POSITION_Y. Userspace can use EVIOCGABS to map device units
>> onto common units.
>>
>> From include/uapi/linux/input.h (struct input_absinfo):
>>
>> * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
>> * units per millimeter (units/mm), resolution for rotational axes
>> * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
>>
>> Hope this helps.
>>
> Hi Dmitry,
>
> I understand this works for Dmitry ABS_X, ABS_Y,
> touchscreen reports between 0..A, screen resolution is 0..B, a mapping
> can be done 0..A -> 0..B
>
> But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
> touchscreen reports between 0..A, do we know the min/max values for
> application side?
>
> --
>
> Thanks,
> ferruh
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ABS_MT_TOUCH_MAJOR metric
2014-05-22 19:29 ` Ferruh Yigit
2014-05-22 19:42 ` Dmitry Torokhov
2014-05-22 19:45 ` Michael Wright
@ 2014-05-22 19:46 ` Henrik Rydberg
2 siblings, 0 replies; 6+ messages in thread
From: Henrik Rydberg @ 2014-05-22 19:46 UTC (permalink / raw)
To: Ferruh Yigit, Dmitry Torokhov; +Cc: linux-input@vger.kernel.org
Ferruh,
> I understand this works for Dmitry ABS_X, ABS_Y,
> touchscreen reports between 0..A, screen resolution is 0..B, a mapping
> can be done 0..A -> 0..B
>
> But for ABS_MT_TOUCH_MAJOR how this scaling can be done,
> touchscreen reports between 0..A, do we know the min/max values for
> application side?
You are right to be confused here. The axes you refer to are, in a way,
meaningless because both TOUCH_MAJOR and TOUCH_MINOR (and the corresponding
WIDTH_MAJOR and WIDTH_MINOR) are assumed to be measured in surface coordinates,
i.e., of the same scale as ABS_X and ABS_Y.
Historically, these axes have had specific values anyways, as an indication of
how large a touch area can be a the specific device. This is how userland MT
applications interpret the data. Strictly speaking, this is incorrect, but
that's how it is.
Henrik
^ permalink raw reply [flat|nested] 6+ messages in thread