The newly released HID protocol for win8 input devices is capable of
transmitting the same information found in the Apple HID and Linux MT
protocols. In addition, it includes an extension useful for touch
alignment. This patch completes the MT protocol with the
ABS_MT_APPROACH_X/Y events, and documents how to map win8 devices.
Signed-off-by: Henrik Rydberg <[email protected]>
---
Hi all,
In response to the win8 HID protocol and Benjamin's work on this, here
is a first draft of the needed extension to the MT protocol. I am
cc:ing the usual suspects, as this will affect userland. Comments and
criticism expected. :-)
Cheers,
Henrik
Documentation/input/multi-touch-protocol.txt | 35 +++++++++++++++++++++++++-
include/linux/input.h | 4 ++-
2 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 543101c..504ca6d 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -168,7 +168,9 @@ The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
looking through a window at someone gently holding a finger against the
glass. You will see two regions, one inner region consisting of the part
of the finger actually touching the glass, and one outer region formed by
-the perimeter of the finger. The diameter of the inner region is the
+the perimeter of the finger. The center of the inner region is
+ABS_MT_POSITION_X/Y. The center of the outer region may be different,
+denoted by ABS_MT_APPROACH_X/Y. The diameter of the inner region is the
ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
against the glass. The inner region will increase, and in general, the
@@ -252,6 +254,9 @@ can distinguish between the two axis, but not (uniquely) any values in
between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
[4].
+For devices capable of 360 degree orientation, the reported orientation
+should be twice the given range.
+
ABS_MT_POSITION_X
The surface X coordinate of the center of the touching ellipse.
@@ -260,6 +265,23 @@ ABS_MT_POSITION_Y
The surface Y coordinate of the center of the touching ellipse.
+ABS_MT_APPROACH_X
+
+The surface X coordinate of the center of the approaching ellipse. Omit if
+the device cannot distinguish between the intended touching point and the
+center of the approaching contact.
+
+ABS_MT_APPROACH_Y
+
+The surface Y coordinate of the center of the approaching ellipse. Omit if
+the device cannot distinguish between the intended touching point and the
+center of the approaching contact.
+
+The four position values can be used to separate the intended touch point
+from the center of the approaching object. The difference also yields an
+approximation of the directed orientation of the approaching ellipse, with
+ABS_MT_WIDTH_MAJOR pointing towards the touch center.
+
ABS_MT_TOOL_TYPE
The type of approaching tool. A lot of kernel drivers cannot distinguish
@@ -305,6 +327,17 @@ The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that
the device can distinguish between a finger along the Y axis (0) and a
finger along the X axis (1).
+For win8 devices with both T and C coordinates, the position mapping is
+
+ ABS_MT_POSITION_X := T_X
+ ABS_MT_POSITION_Y := T_Y
+ ABS_MT_APPROACH_X := C_X
+ ABS_MT_APPROACH_X := C_Y
+
+For win8 devices with Azimuth or Twist defined, the range max is the value
+for 90 degrees, and the orientation mapping is
+
+ ABS_MT_ORIENTATION := twist < 2 * max ? twist : twist - 4 * max
Finger Tracking
---------------
diff --git a/include/linux/input.h b/include/linux/input.h
index a816714..039234e 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -813,11 +813,13 @@ struct input_keymap_entry {
#define ABS_MT_TRACKING_ID 0x39 /* Unique ID of initiated contact */
#define ABS_MT_PRESSURE 0x3a /* Pressure on contact area */
#define ABS_MT_DISTANCE 0x3b /* Contact hover distance */
+#define ABS_MT_APPROACH_X 0x3c /* Center X approaching ellipse */
+#define ABS_MT_APPROACH_Y 0x3d /* Center Y approaching ellipse */
#ifdef __KERNEL__
/* Implementation details, userspace should not care about these */
#define ABS_MT_FIRST ABS_MT_TOUCH_MAJOR
-#define ABS_MT_LAST ABS_MT_DISTANCE
+#define ABS_MT_LAST ABS_MT_APPROACH_Y
#endif
#define ABS_MAX 0x3f
--
1.7.10
On 05/05/2012 08:08 AM, Henrik Rydberg wrote:
> The newly released HID protocol for win8 input devices is capable of
> transmitting the same information found in the Apple HID and Linux MT
> protocols. In addition, it includes an extension useful for touch
> alignment. This patch completes the MT protocol with the
> ABS_MT_APPROACH_X/Y events, and documents how to map win8 devices.
>
> Signed-off-by: Henrik Rydberg <[email protected]>
> ---
> Hi all,
>
> In response to the win8 HID protocol and Benjamin's work on this, here
> is a first draft of the needed extension to the MT protocol. I am
> cc:ing the usual suspects, as this will affect userland. Comments and
> criticism expected. :-)
>
> Cheers,
> Henrik
>
> Documentation/input/multi-touch-protocol.txt | 35 +++++++++++++++++++++++++-
> include/linux/input.h | 4 ++-
> 2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
> index 543101c..504ca6d 100644
> --- a/Documentation/input/multi-touch-protocol.txt
> +++ b/Documentation/input/multi-touch-protocol.txt
[snip]
> @@ -252,6 +254,9 @@ can distinguish between the two axis, but not (uniquely) any values in
> between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
> [4].
>
> +For devices capable of 360 degree orientation, the reported orientation
> +should be twice the given range.
I don't understand what this means. Can you elaborate?
-- Chase
Hi Henrik,
On Sat, May 5, 2012 at 5:08 PM, Henrik Rydberg <[email protected]> wrote:
> The newly released HID protocol for win8 input devices is capable of
> transmitting the same information found in the Apple HID and Linux MT
> protocols. In addition, it includes an extension useful for touch
> alignment. This patch completes the MT protocol with the
> ABS_MT_APPROACH_X/Y events, and documents how to map win8 devices.
>
> Signed-off-by: Henrik Rydberg <[email protected]>
> ---
> Hi all,
>
> In response to the win8 HID protocol and Benjamin's work on this, here
> is a first draft of the needed extension to the MT protocol. I am
> cc:ing the usual suspects, as this will affect userland. Comments and
> criticism expected. :-)
>
> Cheers,
> Henrik
>
> ?Documentation/input/multi-touch-protocol.txt | ? 35 +++++++++++++++++++++++++-
> ?include/linux/input.h ? ? ? ? ? ? ? ? ? ? ? ?| ? ?4 ++-
> ?2 files changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
> index 543101c..504ca6d 100644
> --- a/Documentation/input/multi-touch-protocol.txt
> +++ b/Documentation/input/multi-touch-protocol.txt
> @@ -168,7 +168,9 @@ The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
> ?looking through a window at someone gently holding a finger against the
> ?glass. ?You will see two regions, one inner region consisting of the part
> ?of the finger actually touching the glass, and one outer region formed by
> -the perimeter of the finger. The diameter of the inner region is the
> +the perimeter of the finger. The center of the inner region is
> +ABS_MT_POSITION_X/Y. The center of the outer region may be different,
> +denoted by ABS_MT_APPROACH_X/Y. The diameter of the inner region is the
> ?ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
> ?ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
> ?against the glass. The inner region will increase, and in general, the
> @@ -252,6 +254,9 @@ can distinguish between the two axis, but not (uniquely) any values in
> ?between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
> ?[4].
>
> +For devices capable of 360 degree orientation, the reported orientation
> +should be twice the given range.
Like Chase, I don't understand the necessity of that.
> +
> ?ABS_MT_POSITION_X
>
> ?The surface X coordinate of the center of the touching ellipse.
> @@ -260,6 +265,23 @@ ABS_MT_POSITION_Y
>
> ?The surface Y coordinate of the center of the touching ellipse.
>
> +ABS_MT_APPROACH_X
Honestly, I think that ABS_MT_APPROACH_* is really confusing for
end-users (Xorg, Wayland, Qt, ...). I know that the explanation are
given, but looking at the mess we had with the use of the MT events
before it has been documented, I don't think this is the right term to
use. Without the doc, and with a little bit of bad faith, I would say
that approach refers to the T coordinate in Win8 doc (the approximate
position where the user wants to touch), whereas the POSITION_* is
more the center of the ellipse of the touch.... But it's the invert...
;-)
Thanks,
Benjamin
> +
> +The surface X coordinate of the center of the approaching ellipse. Omit if
> +the device cannot distinguish between the intended touching point and the
> +center of the approaching contact.
> +
> +ABS_MT_APPROACH_Y
> +
> +The surface Y coordinate of the center of the approaching ellipse. Omit if
> +the device cannot distinguish between the intended touching point and the
> +center of the approaching contact.
> +
> +The four position values can be used to separate the intended touch point
> +from the center of the approaching object. The difference also yields an
> +approximation of the directed orientation of the approaching ellipse, with
> +ABS_MT_WIDTH_MAJOR pointing towards the touch center.
> +
> ?ABS_MT_TOOL_TYPE
>
> ?The type of approaching tool. A lot of kernel drivers cannot distinguish
> @@ -305,6 +327,17 @@ The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that
> ?the device can distinguish between a finger along the Y axis (0) and a
> ?finger along the X axis (1).
>
> +For win8 devices with both T and C coordinates, the position mapping is
> +
> + ? ABS_MT_POSITION_X := T_X
> + ? ABS_MT_POSITION_Y := T_Y
> + ? ABS_MT_APPROACH_X := C_X
> + ? ABS_MT_APPROACH_X := C_Y
> +
> +For win8 devices with Azimuth or Twist defined, the range max is the value
> +for 90 degrees, and the orientation mapping is
> +
> + ? ABS_MT_ORIENTATION := twist < 2 * max ? twist : twist - 4 * max
>
> ?Finger Tracking
> ?---------------
> diff --git a/include/linux/input.h b/include/linux/input.h
> index a816714..039234e 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -813,11 +813,13 @@ struct input_keymap_entry {
> ?#define ABS_MT_TRACKING_ID ? ? 0x39 ? ?/* Unique ID of initiated contact */
> ?#define ABS_MT_PRESSURE ? ? ? ? ? ? ? ?0x3a ? ?/* Pressure on contact area */
> ?#define ABS_MT_DISTANCE ? ? ? ? ? ? ? ?0x3b ? ?/* Contact hover distance */
> +#define ABS_MT_APPROACH_X ? ? ?0x3c ? ?/* Center X approaching ellipse */
> +#define ABS_MT_APPROACH_Y ? ? ?0x3d ? ?/* Center Y approaching ellipse */
>
> ?#ifdef __KERNEL__
> ?/* Implementation details, userspace should not care about these */
> ?#define ABS_MT_FIRST ? ? ? ? ? ABS_MT_TOUCH_MAJOR
> -#define ABS_MT_LAST ? ? ? ? ? ?ABS_MT_DISTANCE
> +#define ABS_MT_LAST ? ? ? ? ? ?ABS_MT_APPROACH_Y
> ?#endif
>
> ?#define ABS_MAX ? ? ? ? ? ? ? ? ? ? ? ?0x3f
> --
> 1.7.10
>
Hi,
to aid in the discussion, I have attached a drawing of the MT model
and the (supposed) win8 model.
> > @@ -168,7 +168,9 @@ The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
> > ?looking through a window at someone gently holding a finger against the
> > ?glass. ?You will see two regions, one inner region consisting of the part
> > ?of the finger actually touching the glass, and one outer region formed by
> > -the perimeter of the finger. The diameter of the inner region is the
> > +the perimeter of the finger. The center of the inner region is
> > +ABS_MT_POSITION_X/Y. The center of the outer region may be different,
> > +denoted by ABS_MT_APPROACH_X/Y. The diameter of the inner region is the
> > ?ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
> > ?ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
> > ?against the glass. The inner region will increase, and in general, the
> > @@ -252,6 +254,9 @@ can distinguish between the two axis, but not (uniquely) any values in
> > ?between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
> > ?[4].
> >
> > +For devices capable of 360 degree orientation, the reported orientation
> > +should be twice the given range.
>
> Like Chase, I don't understand the necessity of that.
The MT model supports the arbitrary orientation of an ellipse. The
angle is defined as a [-90,90] degree clockwise angle between the y
axis and the major axis of the ellipse (marked o in the figure). Only
180 degrees are specified due to the symmetry; rotating 135 degrees is
equivalent to -45 degrees.
In the win8 model, as in the windows surface model and most
implementations of FTIR, it is possible to distinguish the absolute
direction of a finger. This is equivalent to an ellipse with an arrow
(the angle is marked A in the figure).
To accomodate the directional angle in the MT model, one can simply
report the full [-180,180] range instead. That is, report 135 degrees
instead of -45.
>
> > +
> > ?ABS_MT_POSITION_X
> >
> > ?The surface X coordinate of the center of the touching ellipse.
> > @@ -260,6 +265,23 @@ ABS_MT_POSITION_Y
> >
> > ?The surface Y coordinate of the center of the touching ellipse.
> >
> > +ABS_MT_APPROACH_X
>
> Honestly, I think that ABS_MT_APPROACH_* is really confusing for
> end-users (Xorg, Wayland, Qt, ...). I know that the explanation are
> given, but looking at the mess we had with the use of the MT events
> before it has been documented, I don't think this is the right term to
> use. Without the doc, and with a little bit of bad faith, I would say
> that approach refers to the T coordinate in Win8 doc (the approximate
> position where the user wants to touch), whereas the POSITION_* is
> more the center of the ellipse of the touch.... But it's the invert...
> ;-)
Looking at the figure, it is clear that the MT model has two centers,
one for each ellipse. Thus, center is not discriminating
enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
> > +For win8 devices with Azimuth or Twist defined, the range max is the value
> > +for 90 degrees, and the orientation mapping is
> > +
> > + ? ABS_MT_ORIENTATION := twist < 2 * max ? twist : twist - 4 * max
Reading the HID spec again, it seems azimuth is the preferred value
for touch, so twist can be omitted here. Also, it seems the angle
should be counter-clockwise, thus the sign is wrong. On the other
hand, it is unclear what the reference point is, so maybe it can only
be used for differential updates... Also, the word "cursor" is not
further specified, it could be the orientation of the touch point or
the orientation of the whole area... This hopefully will become
clearer with time.
Thanks,
Henrik
(doh, trying again without attachment)
Hi,
to aid in the discussion, I have shared a drawing of the MT model
and the (supposed) win8 model.
https://docs.google.com/document/d/1KKu7kqPOsvE9tCmWhdGnmO8tgmN0Cd-Mv_crVaCZueY/view
> > @@ -168,7 +168,9 @@ The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
> > ?looking through a window at someone gently holding a finger against the
> > ?glass. ?You will see two regions, one inner region consisting of the part
> > ?of the finger actually touching the glass, and one outer region formed by
> > -the perimeter of the finger. The diameter of the inner region is the
> > +the perimeter of the finger. The center of the inner region is
> > +ABS_MT_POSITION_X/Y. The center of the outer region may be different,
> > +denoted by ABS_MT_APPROACH_X/Y. The diameter of the inner region is the
> > ?ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
> > ?ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
> > ?against the glass. The inner region will increase, and in general, the
> > @@ -252,6 +254,9 @@ can distinguish between the two axis, but not (uniquely) any values in
> > ?between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
> > ?[4].
> >
> > +For devices capable of 360 degree orientation, the reported orientation
> > +should be twice the given range.
>
> Like Chase, I don't understand the necessity of that.
The MT model supports the arbitrary orientation of an ellipse. The
angle is defined as a [-90,90] degree clockwise angle between the y
axis and the major axis of the ellipse (marked o in the figure). Only
180 degrees are specified due to the symmetry; rotating 135 degrees is
equivalent to -45 degrees.
In the win8 model, as in the windows surface model and most
implementations of FTIR, it is possible to distinguish the absolute
direction of a finger. This is equivalent to an ellipse with an arrow
(the angle is marked A in the figure).
To accomodate the directional angle in the MT model, one can simply
report the full [-180,180] range instead. That is, report 135 degrees
instead of -45.
>
> > +
> > ?ABS_MT_POSITION_X
> >
> > ?The surface X coordinate of the center of the touching ellipse.
> > @@ -260,6 +265,23 @@ ABS_MT_POSITION_Y
> >
> > ?The surface Y coordinate of the center of the touching ellipse.
> >
> > +ABS_MT_APPROACH_X
>
> Honestly, I think that ABS_MT_APPROACH_* is really confusing for
> end-users (Xorg, Wayland, Qt, ...). I know that the explanation are
> given, but looking at the mess we had with the use of the MT events
> before it has been documented, I don't think this is the right term to
> use. Without the doc, and with a little bit of bad faith, I would say
> that approach refers to the T coordinate in Win8 doc (the approximate
> position where the user wants to touch), whereas the POSITION_* is
> more the center of the ellipse of the touch.... But it's the invert...
> ;-)
Looking at the figure, it is clear that the MT model has two centers,
one for each ellipse. Thus, center is not discriminating
enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
> > +For win8 devices with Azimuth or Twist defined, the range max is the value
> > +for 90 degrees, and the orientation mapping is
> > +
> > + ? ABS_MT_ORIENTATION := twist < 2 * max ? twist : twist - 4 * max
Reading the HID spec again, it seems azimuth is the preferred value
for touch, so twist can be omitted here. Also, it seems the angle
should be counter-clockwise, thus the sign is wrong. On the other
hand, it is unclear what the reference point is, maybe it can only be
used for differential updates. Also, the word "cursor" is not further
specified, it could be the orientation of the touch point or the
orientation of the whole area. This hopefully will become clearer with
time.
Thanks,
Henrik
On Sun, May 06, 2012 at 08:28:35PM +0200, Henrik Rydberg wrote:
> (doh, trying again without attachment)
>
> Hi,
>
> to aid in the discussion, I have shared a drawing of the MT model
> and the (supposed) win8 model.
>
> https://docs.google.com/document/d/1KKu7kqPOsvE9tCmWhdGnmO8tgmN0Cd-Mv_crVaCZueY/view
having an asciiart version of this in Documentation/ would be quite useful,
IMO
> > > @@ -168,7 +168,9 @@ The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
> > > ?looking through a window at someone gently holding a finger against the
> > > ?glass. ?You will see two regions, one inner region consisting of the part
> > > ?of the finger actually touching the glass, and one outer region formed by
> > > -the perimeter of the finger. The diameter of the inner region is the
> > > +the perimeter of the finger. The center of the inner region is
> > > +ABS_MT_POSITION_X/Y. The center of the outer region may be different,
> > > +denoted by ABS_MT_APPROACH_X/Y. The diameter of the inner region is the
> > > ?ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
> > > ?ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
> > > ?against the glass. The inner region will increase, and in general, the
> > > @@ -252,6 +254,9 @@ can distinguish between the two axis, but not (uniquely) any values in
> > > ?between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1]
> > > ?[4].
> > >
> > > +For devices capable of 360 degree orientation, the reported orientation
> > > +should be twice the given range.
> >
> > Like Chase, I don't understand the necessity of that.
>
> The MT model supports the arbitrary orientation of an ellipse. The
> angle is defined as a [-90,90] degree clockwise angle between the y
> axis and the major axis of the ellipse (marked o in the figure). Only
> 180 degrees are specified due to the symmetry; rotating 135 degrees is
> equivalent to -45 degrees.
>
> In the win8 model, as in the windows surface model and most
> implementations of FTIR, it is possible to distinguish the absolute
> direction of a finger. This is equivalent to an ellipse with an arrow
> (the angle is marked A in the figure).
>
> To accomodate the directional angle in the MT model, one can simply
> report the full [-180,180] range instead. That is, report 135 degrees
> instead of -45.
Insert a paragraph into the actual documentation. I think that's more
helpful than tacking it on (if not quite as nice in a diff)
"The orientation of the ellipse. The value should describe a signed quarter
of a revolution clockwise around the touch center. The signed value range
is arbitrary, but zero should be returned for a finger aligned along the Y
axis of the surface, a negative value when finger is turned to the left, and
a positive value when finger turned to the right. When completely aligned
with the X axis, the range max should be returned.
Touch ellipsis are symmetrical by default. For devices capable of true 360
degree orientation, the reported orientation must exceed the range max to
indicate more than a quarter of a revolution. For an upside-down finger,
range max * 2 should be returned.
Orientation can be omitted if the touching object is circular, or if the
information is not available in the kernel driver. Partial orientation
support is possible if the device can distinguish between the two axis, but
not (uniquely) any values in between. In such cases, the range of
ABS_MT_ORIENTATION should be [0, 1] [4]."
Not a big fan of reporting values above absmin/absmax, tbh. It means we
can't rely on the axis values and have to special-case it. Plus, there's no
way to detect this before you actually get a value.
> > > +
> > > ?ABS_MT_POSITION_X
> > >
> > > ?The surface X coordinate of the center of the touching ellipse.
> > > @@ -260,6 +265,23 @@ ABS_MT_POSITION_Y
> > >
> > > ?The surface Y coordinate of the center of the touching ellipse.
> > >
> > > +ABS_MT_APPROACH_X
> >
> > Honestly, I think that ABS_MT_APPROACH_* is really confusing for
> > end-users (Xorg, Wayland, Qt, ...). I know that the explanation are
> > given, but looking at the mess we had with the use of the MT events
> > before it has been documented, I don't think this is the right term to
> > use. Without the doc, and with a little bit of bad faith, I would say
> > that approach refers to the T coordinate in Win8 doc (the approximate
> > position where the user wants to touch), whereas the POSITION_* is
> > more the center of the ellipse of the touch.... But it's the invert...
> > ;-)
>
> Looking at the figure, it is clear that the MT model has two centers,
> one for each ellipse. Thus, center is not discriminating
> enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
ABS_MT_OUTER_CENTER
Cheers,
Peter
>
> > > +For win8 devices with Azimuth or Twist defined, the range max is the value
> > > +for 90 degrees, and the orientation mapping is
> > > +
> > > + ? ABS_MT_ORIENTATION := twist < 2 * max ? twist : twist - 4 * max
>
> Reading the HID spec again, it seems azimuth is the preferred value
> for touch, so twist can be omitted here. Also, it seems the angle
> should be counter-clockwise, thus the sign is wrong. On the other
> hand, it is unclear what the reference point is, maybe it can only be
> used for differential updates. Also, the word "cursor" is not further
> specified, it could be the orientation of the touch point or the
> orientation of the whole area. This hopefully will become clearer with
> time.
>
> Thanks,
> Henrik
> > to aid in the discussion, I have shared a drawing of the MT model
> > and the (supposed) win8 model.
> >
> > https://docs.google.com/document/d/1KKu7kqPOsvE9tCmWhdGnmO8tgmN0Cd-Mv_crVaCZueY/view
>
> having an asciiart version of this in Documentation/ would be quite useful,
> IMO
Yep, that ought to be possible to arrange.
> Insert a paragraph into the actual documentation. I think that's more
> helpful than tacking it on (if not quite as nice in a diff)
>
> "The orientation of the ellipse. The value should describe a signed quarter
> of a revolution clockwise around the touch center. The signed value range
> is arbitrary, but zero should be returned for a finger aligned along the Y
> axis of the surface, a negative value when finger is turned to the left, and
> a positive value when finger turned to the right. When completely aligned
> with the X axis, the range max should be returned.
>
> Touch ellipsis are symmetrical by default. For devices capable of true 360
> degree orientation, the reported orientation must exceed the range max to
> indicate more than a quarter of a revolution. For an upside-down finger,
> range max * 2 should be returned.
>
> Orientation can be omitted if the touching object is circular, or if the
> information is not available in the kernel driver. Partial orientation
> support is possible if the device can distinguish between the two axis, but
> not (uniquely) any values in between. In such cases, the range of
> ABS_MT_ORIENTATION should be [0, 1] [4]."
Looks good, will copy that in its entirety. :-)
> Not a big fan of reporting values above absmin/absmax, tbh. It means we
> can't rely on the axis values and have to special-case it. Plus, there's no
> way to detect this before you actually get a value.
True, and I am open to other suggestions. However, I think the
proposal integrates pretty well with the existing model and is likely
to produce reasonable results without userland modifications.
> > Looking at the figure, it is clear that the MT model has two centers,
> > one for each ellipse. Thus, center is not discriminating
> > enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
>
> ABS_MT_OUTER_CENTER
I appreciate the suggestion, but along two-word combinations,
ABS_MT_OUTER_POSITION would integrate better with existing names. Both
seem awfully long, though.
Thanks for your input!
Henrik
On 05/05/2012 01:07 PM, Chase Douglas wrote:
>>
>> +For devices capable of 360 degree orientation, the reported orientation
>> +should be twice the given range.
>
> I don't understand what this means. Can you elaborate?
>
A guess is that it means that the value is encoded as a single byte with
a 2° granuarity?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Tue, May 08, 2012 at 11:50:23AM -0700, H. Peter Anvin wrote:
> On 05/05/2012 01:07 PM, Chase Douglas wrote:
> >>
> >> +For devices capable of 360 degree orientation, the reported orientation
> >> +should be twice the given range.
> >
> > I don't understand what this means. Can you elaborate?
> >
>
> A guess is that it means that the value is encoded as a single byte with
> a 2? granuarity?
Both Benjamin and Chase had the same question, and the reply is here:
http://www.spinics.net/lists/linux-input/msg20736.html
Hopefully that helps.
Thanks for chipping in,
Henrik
On Tue, May 08, 2012 at 08:40:52PM +0200, Henrik Rydberg wrote:
> > > to aid in the discussion, I have shared a drawing of the MT model
> > > and the (supposed) win8 model.
> > >
> > > https://docs.google.com/document/d/1KKu7kqPOsvE9tCmWhdGnmO8tgmN0Cd-Mv_crVaCZueY/view
> >
> > having an asciiart version of this in Documentation/ would be quite useful,
> > IMO
>
> Yep, that ought to be possible to arrange.
>
> > Insert a paragraph into the actual documentation. I think that's more
> > helpful than tacking it on (if not quite as nice in a diff)
> >
> > "The orientation of the ellipse. The value should describe a signed quarter
> > of a revolution clockwise around the touch center. The signed value range
> > is arbitrary, but zero should be returned for a finger aligned along the Y
> > axis of the surface, a negative value when finger is turned to the left, and
> > a positive value when finger turned to the right. When completely aligned
> > with the X axis, the range max should be returned.
> >
> > Touch ellipsis are symmetrical by default. For devices capable of true 360
> > degree orientation, the reported orientation must exceed the range max to
> > indicate more than a quarter of a revolution. For an upside-down finger,
> > range max * 2 should be returned.
> >
> > Orientation can be omitted if the touching object is circular, or if the
> > information is not available in the kernel driver. Partial orientation
> > support is possible if the device can distinguish between the two axis, but
> > not (uniquely) any values in between. In such cases, the range of
> > ABS_MT_ORIENTATION should be [0, 1] [4]."
>
> Looks good, will copy that in its entirety. :-)
>
> > Not a big fan of reporting values above absmin/absmax, tbh. It means we
> > can't rely on the axis values and have to special-case it. Plus, there's no
> > way to detect this before you actually get a value.
>
> True, and I am open to other suggestions. However, I think the
> proposal integrates pretty well with the existing model and is likely
> to produce reasonable results without userland modifications.
>
> > > Looking at the figure, it is clear that the MT model has two centers,
> > > one for each ellipse. Thus, center is not discriminating
> > > enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
> >
> > ABS_MT_OUTER_CENTER
>
> I appreciate the suggestion, but along two-word combinations,
> ABS_MT_OUTER_POSITION would integrate better with existing names. Both
> seem awfully long, though.
problem I see with "outer position" is that I'd associate it with the
top/left position of whatever "outer" is, not with the center of said
envelope. that's why I'd argue that "center" should be somewhere in the
name.
Cheers,
Peter
> > > > Looking at the figure, it is clear that the MT model has two centers,
> > > > one for each ellipse. Thus, center is not discriminating
> > > > enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
> > >
> > > ABS_MT_OUTER_CENTER
> >
> > I appreciate the suggestion, but along two-word combinations,
> > ABS_MT_OUTER_POSITION would integrate better with existing names. Both
> > seem awfully long, though.
>
> problem I see with "outer position" is that I'd associate it with the
> top/left position of whatever "outer" is, not with the center of said
> envelope. that's why I'd argue that "center" should be somewhere in the
> name.
Top-left does not apply to an ellipse, so that argument makes little
sense for someone looking only at the MT protocol. Given that position
is the actual protocol name for the center of the touching ellipse,
there is hardly any doubt what it means in this context.
How about ABS_MT_TOOL_X/Y?
Henrik
On Tue, May 8, 2012 at 10:35 PM, Henrik Rydberg <[email protected]> wrote:
>
> > > > > Looking at the figure, it is clear that the MT model has two
> > > > > centers,
> > > > > one for each ellipse. Thus, center is not discriminating
> > > > > enough. Perhaps ABS_MT_OUTER_X/Y is more appropriate, then?
> > > >
> > > > ABS_MT_OUTER_CENTER
> > >
> > > I appreciate the suggestion, but along two-word combinations,
> > > ABS_MT_OUTER_POSITION would integrate better with existing names. Both
> > > seem awfully long, though.
> >
> > problem I see with "outer position" is that I'd associate it with the
> > top/left position of whatever "outer" is, not with the center of said
> > envelope. that's why I'd argue that "center" should be somewhere in the
> > name.
>
> Top-left does not apply to an ellipse, so that argument makes little
> sense for someone looking only at the MT protocol. Given that position
> is the actual protocol name for the center of the touching ellipse,
> there is hardly any doubt what it means in this context.
>
> How about ABS_MT_TOOL_X/Y?
I am ok if we use any one of the suggested terms. The term is non
technical per se. Readers will have to look into the spec to
understand what exactly it means. But, I'd choose ABS_MT_CENTER_X/Y if
we can only pick one from the suggested ones.
MT_TOOL_X/Y is unique. But, it introduces TOOL to the term. That makes
me think about MT_TOOL_FINGER and MT_TOOL_PEN, which are irrelevant to
this context.
Ping
Hi Ping,
> > How about ABS_MT_TOOL_X/Y?
>
> I am ok if we use any one of the suggested terms. The term is non
> technical per se. Readers will have to look into the spec to
> understand what exactly it means. But, I'd choose ABS_MT_CENTER_X/Y if
> we can only pick one from the suggested ones.
>
> MT_TOOL_X/Y is unique. But, it introduces TOOL to the term. That makes
> me think about MT_TOOL_FINGER and MT_TOOL_PEN, which are irrelevant to
> this context.
On the contrary, tool as a base makes a lot of sense here. For the
single-pointer case, we have tool types and tool size already. If we
were to add a tool position, we would naturally think of
ABS_TOOL_X/Y. For the MT case, MT_TOOL_* are the tool types, and
ABS_MT_WIDTH_* is the tool size. It was chosen in analogy with
ABS_TOOL_WIDTH, although the TOOL part was dropped in favor of a
shorter name. In retrospect, ABS_MT_POSITION_X should have been named
ABS_MT_TOUCH_X and ABS_MT_WIDTH_MAJOR could have been named
ABS_MT_TOOL_MAJOR. This would more clearly have shown the events being
properties of two objects, tool and touch. With that in mind,
ABS_MT_TOOL_X is a natural choice.
Thanks,
Henrik