The recent input-mt interface changes together with
recent discussions about pen and touch and support
for legacy multitouch pads suggest that the documentation
on MT tool types be expanded. This patch adds references
to the new interface, and adds a section for MT_TOOL types,
in particular documenting the use of MT_TOOL_ENVELOPE.
Signed-off-by: Henrik Rydberg <[email protected]>
---
Documentation/input/multi-touch-protocol.txt | 39 ++++++++++++++++++--------
include/linux/input.h | 6 ++--
2 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 351fab8..5ab352e 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -169,12 +169,14 @@ described by adding the MINOR parameters, such that MAJOR and MINOR are the
major and minor axis of an ellipse. Finally, the orientation of the oval
shape can be describe with the ORIENTATION parameter.
+For type A devices, further specification of the touch shape is possible
+via ABS_MT_BLOB_ID.
+
The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
-contact or a pen or something else. Devices with more granular information
-may specify general shapes as blobs, i.e., as a sequence of rectangular
-shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
-that currently support it, the ABS_MT_TRACKING_ID event may be used to
-report contact tracking from hardware [5].
+contact or a pen or something else. Finally, the ABS_MT_TRACKING_ID event
+may be used to track identified contacts over time [5]. In the type B
+protocol, the use of ABS_MT_TOOL_TYPE and ABS_MT_TRACKING_ID is implicit
+via the input_mt_report_slot_state() function.
Event Semantics
@@ -246,22 +248,35 @@ ABS_MT_TOOL_TYPE
The type of approaching tool. A lot of kernel drivers cannot distinguish
between different tool types, such as a finger or a pen. In such cases, the
-event should be omitted. The protocol currently supports MT_TOOL_FINGER and
-MT_TOOL_PEN and MT_TOOL_ENVELOPE [2].
+event should be omitted. The protocol currently supports MT_TOOL_FINGER,
+MT_TOOL_PEN and MT_TOOL_ENVELOPE [2]. For type B devices, this event is
+handled by input core, via the input_mt interface.
+
+- The MT_TOOL_FINGER type is the default, and represents a finger touch.
+
+- The MT_TOOL_PEN type represents a pen, and the list of related tools is
+expected to grow with time.
+
+- The MT_TOOL_ENVELOPE type is used to indicate that the contact position
+is not well-defined, and is only used for legacy hardware. The real contact
+positions are to be found within the bounding rectangle formed by the
+envelope contact positions.
ABS_MT_BLOB_ID
The BLOB_ID groups several packets together into one arbitrarily shaped
-contact. This is a low-level anonymous grouping for type A devices, and
+contact. The sequence of points forms a polygon which defines the shape of
+the contact. This is a low-level anonymous grouping for type A devices, and
should not be confused with the high-level trackingID [5]. Most type A
devices do not have blob capability, so drivers can safely omit this event.
ABS_MT_TRACKING_ID
The TRACKING_ID identifies an initiated contact throughout its life cycle
-[5]. This event is mandatory for type B devices. The value range of the
-TRACKING_ID should be large enough to ensure unique identification of a
-contact maintained over an extended period of time.
+[5]. The value range of the TRACKING_ID should be large enough to ensure
+unique identification of a contact maintained over an extended period of
+time. For type B devices, this event is handled by input core, via the
+input_mt interface.
Event Computation
@@ -321,6 +336,6 @@ difference between the contact position and the approaching tool position
could be used to derive tilt.
[2] ABS_MT_ENVELOPE contacts represent an envelope of the contacts rather
than the actual contacts. Used with older, not fully MT capable, devices.
-[3] Multitouch X driver project: http://bitmath.org/code/multitouch/.
+[3] The mtdev project: http://bitmath.org/code/mtdev/.
[4] See the section on event computation.
[5] See the section on finger tracking.
diff --git a/include/linux/input.h b/include/linux/input.h
index 65f7799..6b36e34 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -847,9 +847,9 @@ struct input_keymap_entry {
/*
* MT_TOOL types
*/
-#define MT_TOOL_FINGER 0
-#define MT_TOOL_PEN 1
-#define MT_TOOL_ENVELOPE 2
+#define MT_TOOL_FINGER 0 /* normal finger */
+#define MT_TOOL_PEN 1 /* pen tool */
+#define MT_TOOL_ENVELOPE 2 /* rectangle corner - legacy use only */
#define MT_TOOL_MAX 2
/*
--
1.7.1
On Fri, Dec 10, 2010 at 06:24:02PM +0100, Henrik Rydberg wrote:
> +#define MT_TOOL_ENVELOPE 2 /* rectangle corner - legacy use only */
Legacy to me implies we can upgrade, but this is hardware limitation.
Can we say "rectangle corner - used by older hardware"?
--
Dmitry
On 12/10/2010 06:36 PM, Dmitry Torokhov wrote:
> On Fri, Dec 10, 2010 at 06:24:02PM +0100, Henrik Rydberg wrote:
>> +#define MT_TOOL_ENVELOPE 2 /* rectangle corner - legacy use only */
>
> Legacy to me implies we can upgrade, but this is hardware limitation.
> Can we say "rectangle corner - used by older hardware"?
>
How about "- older hw only", to stay within a single line?
Henrik
On Fri, Dec 10, 2010 at 9:41 AM, Henrik Rydberg <[email protected]> wrote:
> On 12/10/2010 06:36 PM, Dmitry Torokhov wrote:
>
>> On Fri, Dec 10, 2010 at 06:24:02PM +0100, Henrik Rydberg wrote:
>>> +#define MT_TOOL_ENVELOPE ? ?2 ? ? ? /* rectangle corner - legacy use only */
>>
>> Legacy to me implies we can upgrade, but this is hardware limitation.
>> Can we say "rectangle corner - used by older hardware"?
>>
> How about "- older hw only", to stay within a single line?
Why do we suggest it will only be used by older hardware?
Ping
>>> Legacy to me implies we can upgrade, but this is hardware limitation.
>>> Can we say "rectangle corner - used by older hardware"?
>>>
>> How about "- older hw only", to stay within a single line?
>
> Why do we suggest it will only be used by older hardware?
To limit its use - we really do not want to use anything but good contact data
anywhere, but we do not want to leave abundant (= old) hardware out, either.
Why, is there some case where it would be useful, you think?
Henrik
On 12/10/2010 09:24 AM, Henrik Rydberg wrote:
> +- The MT_TOOL_ENVELOPE type is used to indicate that the contact position
> +is not well-defined, and is only used for legacy hardware. The real contact
> +positions are to be found within the bounding rectangle formed by the
> +envelope contact positions.
By definition, this only covers rectangles with two coordinates to
define the shape and location. Why do we want to call it envelope? It's
just extra confusion to me. Why not call it MT_TOOL_RECT?
Please describe how to use this tool type. Its usage is different than
any tool type usage before, so an explanation would be helpful. Must the
value of the tool on the first touch be 0 until a second touch can
define the rect? Or, can touches always default the value to 1 since
we're talking about devices that only support two fingers?
If this is really to remedy only poor two finger devices, would it be
better to flag the device itself somehow to say "don't trust this
device's coordinate positions" (or something more elegant)? This would
prevent an extrapolation of tool types to multiple fingers at a time.
Lastly, using tool types for this seems odd since this does not signify
a physical tool. It merely signifies that the device coordinates cannot
be trusted literally. Maybe we should use some other namespace for
binding information across multiple touches, like MT_BIND_RECT?
-- Chase
On 12/13/2010 06:46 PM, Chase Douglas wrote:
> On 12/10/2010 09:24 AM, Henrik Rydberg wrote:
>> +- The MT_TOOL_ENVELOPE type is used to indicate that the contact position
>> +is not well-defined, and is only used for legacy hardware. The real contact
>> +positions are to be found within the bounding rectangle formed by the
>> +envelope contact positions.
>
> By definition, this only covers rectangles with two coordinates to
> define the shape and location. Why do we want to call it envelope? It's
> just extra confusion to me. Why not call it MT_TOOL_RECT?
The envelope contacts serve as a way to detect a small area of fingers or a
large area of fingers. There is nothing inherently problematic with having one
or three or more such contacts.
> Please describe how to use this tool type. Its usage is different than
> any tool type usage before, so an explanation would be helpful. Must the
> value of the tool on the first touch be 0 until a second touch can
> define the rect? Or, can touches always default the value to 1 since
> we're talking about devices that only support two fingers?
For a dual-touch driver sending the lower-left and upper-right corners as
contacts, nothing really has to be done in user space. The contacts will look
weird in a drawing program, because the actual fingers and the ones on the
screen may diverge. The tool type indicates that this may be the case, so the
application can take measures if it wants to. This is the primary intended usage.
A driver can use MT_TOOL_ENVELOPE also for one finger.
> If this is really to remedy only poor two finger devices, would it be
> better to flag the device itself somehow to say "don't trust this
> device's coordinate positions" (or something more elegant)? This would
> prevent an extrapolation of tool types to multiple fingers at a time.
Maybe the device also has a pen, for which the coordinates should be trusted.
> Lastly, using tool types for this seems odd since this does not signify
> a physical tool. It merely signifies that the device coordinates cannot
> be trusted literally. Maybe we should use some other namespace for
> binding information across multiple touches, like MT_BIND_RECT?
The envelope coordinates can be trusted to yield a smoothly moving bounding
area, similar to tracked contacts. Completely untrusted contacts would first
have to be processed somewhere in order to be useful, which is less desirable.
Henrik
On 12/13/2010 01:21 PM, Henrik Rydberg wrote:
> On 12/13/2010 06:46 PM, Chase Douglas wrote:
>> On 12/10/2010 09:24 AM, Henrik Rydberg wrote:
>>> +- The MT_TOOL_ENVELOPE type is used to indicate that the contact position
>>> +is not well-defined, and is only used for legacy hardware. The real contact
>>> +positions are to be found within the bounding rectangle formed by the
>>> +envelope contact positions.
>>
>> By definition, this only covers rectangles with two coordinates to
>> define the shape and location. Why do we want to call it envelope? It's
>> just extra confusion to me. Why not call it MT_TOOL_RECT?
>
>
> The envelope contacts serve as a way to detect a small area of fingers or a
> large area of fingers. There is nothing inherently problematic with having one
> or three or more such contacts.
Then I'm more confused :).
I see one problem: devices that report two touch points, (X1, Y1) and
(X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
instead. Using a rectangle helps resolve this issue for panning and
pinching, though not for rotation.
Now, you're telling me that the envelope tool may be used for more
points than two. If I had more than two touch points, wouldn't it be on
a device that had full MT capabilities, and thus did not need envelope/rect?
The only purpose I can think of for this would be if you had up to four
fingers down that the device reported as (X1, Y1) through (X4, Y4). If
you can trust the coordinate pairs as they are, then you have full MT
and don't need this. Or, you can find the bounding rectangle defined as
the min and max of each axis. You could provide that bounding rectangle
by providing all the coordinates, but that includes potentially
incorrect data. A cleaner approach would tell userspace of the bounding
rectangle and how many fingers are down.
I'm beginning to feel that this isn't really MT at all. Instead of
fitting this into MT slots, we could define ABS_RECT_MIN and
ABS_RECT_MAX to provide the min and max X and Y values, and then use
BTN_TOOL_*TAP as usual to tell how many touches are within the
rectangle. I think this will mirror what userspace would have to
extrapolate from the MT_TOOL_ENVELOPE data anyways, so why not provide
it up front, without any MT protocol complications?
>> Please describe how to use this tool type. Its usage is different than
>> any tool type usage before, so an explanation would be helpful. Must the
>> value of the tool on the first touch be 0 until a second touch can
>> define the rect? Or, can touches always default the value to 1 since
>> we're talking about devices that only support two fingers?
>
>
> For a dual-touch driver sending the lower-left and upper-right corners as
> contacts, nothing really has to be done in user space. The contacts will look
> weird in a drawing program, because the actual fingers and the ones on the
> screen may diverge. The tool type indicates that this may be the case, so the
> application can take measures if it wants to. This is the primary intended usage.
Is it a requirement that the coordinates will be lower-left and
upper-right? If so, that needs to be documented somewhere. If it's not a
requirement, then userspace will likely transform the data to be
uniform, in which case we might as well make it a requirement in evdev.
This still hasn't answered the question though. Suppose I have a device
that supports two finger touches, but only in this rectangular fashion.
Can I leave MT_TOOL_ENVELOPE as 1 all the time? Or does it need to turn
on and off when two touches go down and up?
We're going to be adding support for all this to X and other display
managers. The lack of documentation for even simple things like
BTN_TOOL_DOUBLETAP has been an issue in the past. Let's do it right this
time by providing real documentation for a complex issue like this.
> A driver can use MT_TOOL_ENVELOPE also for one finger.
Isn't this what blobs are for?
>> If this is really to remedy only poor two finger devices, would it be
>> better to flag the device itself somehow to say "don't trust this
>> device's coordinate positions" (or something more elegant)? This would
>> prevent an extrapolation of tool types to multiple fingers at a time.
>
>
> Maybe the device also has a pen, for which the coordinates should be trusted.
The driver could specify which tools are accurate and which tools are
not, if this was the route taken to resolve this issue. However, I like
the approach outlined above better.
>> Lastly, using tool types for this seems odd since this does not signify
>> a physical tool. It merely signifies that the device coordinates cannot
>> be trusted literally. Maybe we should use some other namespace for
>> binding information across multiple touches, like MT_BIND_RECT?
>
>
> The envelope coordinates can be trusted to yield a smoothly moving bounding
> area, similar to tracked contacts. Completely untrusted contacts would first
> have to be processed somewhere in order to be useful, which is less desirable.
We're not talking about completely untrusted contacts. I'm also not sure
how this answers the question :).
-- Chase
>> The envelope contacts serve as a way to detect a small area of fingers or a
>> large area of fingers. There is nothing inherently problematic with having one
>> or three or more such contacts.
>
> Then I'm more confused :).
>
> I see one problem: devices that report two touch points, (X1, Y1) and
> (X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
> instead. Using a rectangle helps resolve this issue for panning and
> pinching, though not for rotation.
If panning and pinching and rotation could all be recovered properly, then the
individual contacts could actually have been reconstructed properly in the first
place. This is the whole point - there is not enough information available for
rotation to be recovered properly.
Thanks.
Henrik
On Fri, Dec 10, 2010 at 06:47:18PM +0100, Henrik Rydberg wrote:
> >>> Legacy to me implies we can upgrade, but this is hardware limitation.
>
> >>> Can we say "rectangle corner - used by older hardware"?
> >>>
> >> How about "- older hw only", to stay within a single line?
> >
> > Why do we suggest it will only be used by older hardware?
>
>
> To limit its use - we really do not want to use anything but good contact data
> anywhere, but we do not want to leave abundant (= old) hardware out, either.
> Why, is there some case where it would be useful, you think?
"old" implies a timeline but for all we know some new hardware may come out
tomorrow that requires the use of this field. so it's new old hardware then
:)
"limited capabilities hw" maybe? my bikeshed is green, btw.
Cheers,
Peter
On Tue, Dec 14, 2010 at 12:25:26AM +0100, Henrik Rydberg wrote:
> >> The envelope contacts serve as a way to detect a small area of fingers or a
>
> >> large area of fingers. There is nothing inherently problematic with having one
> >> or three or more such contacts.
> >
> > Then I'm more confused :).
> >
> > I see one problem: devices that report two touch points, (X1, Y1) and
> > (X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
> > instead. Using a rectangle helps resolve this issue for panning and
> > pinching, though not for rotation.
>
>
> If panning and pinching and rotation could all be recovered properly, then the
> individual contacts could actually have been reconstructed properly in the first
> place. This is the whole point - there is not enough information available for
> rotation to be recovered properly.
can you post an example event stream of the MT_ENVELOPE tool? I'm having
trouble wrapping my head around it.
Cheers,
Peter
On 12/14/2010 05:36 AM, Peter Hutterer wrote:
> On Tue, Dec 14, 2010 at 12:25:26AM +0100, Henrik Rydberg wrote:
>>>> The envelope contacts serve as a way to detect a small area of fingers or a
>>
>>>> large area of fingers. There is nothing inherently problematic with having one
>>>> or three or more such contacts.
>>>
>>> Then I'm more confused :).
>>>
>>> I see one problem: devices that report two touch points, (X1, Y1) and
>>> (X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
>>> instead. Using a rectangle helps resolve this issue for panning and
>>> pinching, though not for rotation.
>>
>>
>> If panning and pinching and rotation could all be recovered properly, then the
>> individual contacts could actually have been reconstructed properly in the first
>> place. This is the whole point - there is not enough information available for
>> rotation to be recovered properly.
>
> can you post an example event stream of the MT_ENVELOPE tool? I'm having
> trouble wrapping my head around it.
Here is an example for you: You sit in a car. You turn your steering wheel left
or right to follow the road. Now, imagine that 40% of the time, when you turn
left, the car actually turns right. This is the behavior you get from the raw
data. Now, instead soak your gloves in soap. At least now you know that your car
will go straight 100% of the time. The MT_ENVELOPE tool is the soapy glove.
That's all there is to it.
The synaptics driver patch sent recently contains an example event stream
generator, in case you want to dwell on more details.
Personally, I am done bending myself backwards to support "old" or "semi-mt"
hardware I never use myself. If somebody cares deeply enough, send a patch. Or
forever hold your peace.
Thanks.
Henrik
On Mon, Dec 13, 2010 at 10:36 PM, Peter Hutterer
<[email protected]> wrote:
> On Tue, Dec 14, 2010 at 12:25:26AM +0100, Henrik Rydberg wrote:
>> >> The envelope contacts serve as a way to detect a small area of fingers or a
>>
>> >> large area of fingers. There is nothing inherently problematic with having one
>> >> or three or more such contacts.
>> >
>> > Then I'm more confused :).
>> >
>> > I see one problem: devices that report two touch points, (X1, Y1) and
>> > (X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
>> > instead. Using a rectangle helps resolve this issue for panning and
>> > pinching, though not for rotation.
>>
>>
>> If panning and pinching and rotation could all be recovered properly, then the
>> individual contacts could actually have been reconstructed properly in the first
>> place. This is the whole point - there is not enough information available for
>> rotation to be recovered properly.
>
> can you post an example event stream of the MT_ENVELOPE tool? I'm having
> trouble wrapping my head around it.
>
Patch 2/2 of synaptics patches from Henrik show this in code form but
here is text form.
Its sets up 2 MT slots and start out at (x,y)=(0,0) for both slots
with no fingers touching. When 1 finger touches, slot 0 shows (x,y)
as reported by hardware and keeps slot 1 at (0,0). When 2 fingers
touch, slot 0 shows lower left of rectangle and slot 1 shows upper
right corner. When 3 fingers touch, same thing as 2 fingers.
For 1 finger case, we could send duplicate values of slot 0 into slot
1 but (0,0) is more efficient for more typical 1 finger usage.
The 3 finger case helps show that hardware itself really wants to talk
in terms of rectangles as well, even if they give half hearted
attempts at real multi-touch points.
Since these slots need to be treated as a whole, no tracking id or similar.
Chris
On Mon, Dec 13, 2010 at 5:02 PM, Chase Douglas
<[email protected]> wrote:
> On 12/13/2010 01:21 PM, Henrik Rydberg wrote:
>> On 12/13/2010 06:46 PM, Chase Douglas wrote:
>>> On 12/10/2010 09:24 AM, Henrik Rydberg wrote:
>>>> +- The MT_TOOL_ENVELOPE type is used to indicate that the contact position
>>>> +is not well-defined, and is only used for legacy hardware. The real contact
>>>> +positions are to be found within the bounding rectangle formed by the
>>>> +envelope contact positions.
>>>
>>> By definition, this only covers rectangles with two coordinates to
>>> define the shape and location. Why do we want to call it envelope? It's
>>> just extra confusion to me. Why not call it MT_TOOL_RECT?
>>
>>
>> The envelope contacts serve as a way to detect a small area of fingers or a
>> large area of fingers. There is nothing inherently problematic with having one
>> or three or more such contacts.
>
> Then I'm more confused :).
>
> I see one problem: devices that report two touch points, (X1, Y1) and
> (X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
> instead. Using a rectangle helps resolve this issue for panning and
> pinching, though not for rotation.
Just a note that I'm sure we can do synaptic's version of rotation. 1
finger fixed and other finger drawing an arc around fixed finger.
>
> Now, you're telling me that the envelope tool may be used for more
> points than two. If I had more than two touch points, wouldn't it be on
> a device that had full MT capabilities, and thus did not need envelope/rect?
>
> The only purpose I can think of for this would be if you had up to four
> fingers down that the device reported as (X1, Y1) through (X4, Y4). If
> you can trust the coordinate pairs as they are, then you have full MT
> and don't need this. Or, you can find the bounding rectangle defined as
> the min and max of each axis. You could provide that bounding rectangle
> by providing all the coordinates, but that includes potentially
> incorrect data. A cleaner approach would tell userspace of the bounding
> rectangle and how many fingers are down.
>
> I'm beginning to feel that this isn't really MT at all. Instead of
> fitting this into MT slots, we could define ABS_RECT_MIN and
> ABS_RECT_MAX to provide the min and max X and Y values, and then use
> BTN_TOOL_*TAP as usual to tell how many touches are within the
> rectangle. I think this will mirror what userspace would have to
> extrapolate from the MT_TOOL_ENVELOPE data anyways, so why not provide
> it up front, without any MT protocol complications?
How would you do it this have? Do you mean
ABS_RECT_MIN_X/ABS_RECT_MIN_Y/ABS_RECT_MAX_X/ABS_RECT_MAX_Y? That
would be possible. If we are talking about a form of tool changing
though I'd prefer to use MT because its nice and isolated from ST tool
changing.
BTW, in the patches so far, we've not listed a finger count report
have we? So as of now BTN_TOOL_*TAP is still required with
MT_TOOL_ENVELOPE to get finger count (I know topic came up so may have
missed in patch).
>
>>> Please describe how to use this tool type. Its usage is different than
>>> any tool type usage before, so an explanation would be helpful. Must the
>>> value of the tool on the first touch be 0 until a second touch can
>>> define the rect? Or, can touches always default the value to 1 since
>>> we're talking about devices that only support two fingers?
>>
>>
>> For a dual-touch driver sending the lower-left and upper-right corners as
>> contacts, nothing really has to be done in user space. The contacts will look
>> weird in a drawing program, because the actual fingers and the ones on the
>> screen may diverge. The tool type indicates that this may be the case, so the
>> application can take measures if it wants to. This is the primary intended usage.
>
> Is it a requirement that the coordinates will be lower-left and
> upper-right? If so, that needs to be documented somewhere. If it's not a
> requirement, then userspace will likely transform the data to be
> uniform, in which case we might as well make it a requirement in evdev.
Probably should enforce some rule. Sample usage in synaptics does it
this way. There are a few variation possible then sample usage.
>
> This still hasn't answered the question though. Suppose I have a device
> that supports two finger touches, but only in this rectangular fashion.
> Can I leave MT_TOOL_ENVELOPE as 1 all the time? Or does it need to turn
> on and off when two touches go down and up?
I think MT_TOOL_ENVELOPE=0 when no touches. For 1 touch case we need
to decide if we still create a rectangle by duplicating values, set on
corner of rectangle to (0,0), or stop reporting the rectangle and
require user to look at either BTN_TOOL_FINGER's ABS_X/ABS_Y or
alternatively report a MT_TOOL_FINGER in slot 0 with its POSITION_X/Y.
The (0,0) in slot 1 of tool MT_TOOL_ENVELOPE is easiest I think for
kernel side and user side to process but reads a little strange.
>
> We're going to be adding support for all this to X and other display
> managers. The lack of documentation for even simple things like
> BTN_TOOL_DOUBLETAP has been an issue in the past. Let's do it right this
> time by providing real documentation for a complex issue like this.
>
>> A driver can use MT_TOOL_ENVELOPE also for one finger.
>
> Isn't this what blobs are for?
>
>>> If this is really to remedy only poor two finger devices, would it be
>>> better to flag the device itself somehow to say "don't trust this
>>> device's coordinate positions" (or something more elegant)? This would
>>> prevent an extrapolation of tool types to multiple fingers at a time.
>>
>>
>> Maybe the device also has a pen, for which the coordinates should be trusted.
>
> The driver could specify which tools are accurate and which tools are
> not, if this was the route taken to resolve this issue. However, I like
> the approach outlined above better.
I see this as what we are doing. MT_TOOL_PEN is accurate.
MT_TOOL_FINGER is accurate. MT_TOOL_ENVELOPE is not but is special
and requires 2 slots to be bound together. We could create
MT_TOOL_FUZZY_FINGER as well and send raw data to userland and let
them do their own rectangle logic but I'm not sure we should.
Rectangles seem pretty simple solution to iffy hardware. I'm not
caught up in doing this threw MT reports but is pretty nice way to
isolate it.
Chris
>
>>> Lastly, using tool types for this seems odd since this does not signify
>>> a physical tool. It merely signifies that the device coordinates cannot
>>> be trusted literally. Maybe we should use some other namespace for
>>> binding information across multiple touches, like MT_BIND_RECT?
>>
>>
>> The envelope coordinates can be trusted to yield a smoothly moving bounding
>> area, similar to tracked contacts. Completely untrusted contacts would first
>> have to be processed somewhere in order to be useful, which is less desirable.
>
> We're not talking about completely untrusted contacts. I'm also not sure
> how this answers the question :).
>
> -- Chase
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
[sorry, got stuck in my outbox for some reason]
On Tue, Dec 14, 2010 at 10:10:10AM +0100, Henrik Rydberg wrote:
> On 12/14/2010 05:36 AM, Peter Hutterer wrote:
>
> > On Tue, Dec 14, 2010 at 12:25:26AM +0100, Henrik Rydberg wrote:
> >>>> The envelope contacts serve as a way to detect a small area of fingers or a
> >>
> >>>> large area of fingers. There is nothing inherently problematic with having one
> >>>> or three or more such contacts.
> >>>
> >>> Then I'm more confused :).
> >>>
> >>> I see one problem: devices that report two touch points, (X1, Y1) and
> >>> (X2, Y2), but in reality the touches could be at (X1, Y2) and (X2, Y1)
> >>> instead. Using a rectangle helps resolve this issue for panning and
> >>> pinching, though not for rotation.
> >>
> >>
> >> If panning and pinching and rotation could all be recovered properly, then the
> >> individual contacts could actually have been reconstructed properly in the first
> >> place. This is the whole point - there is not enough information available for
> >> rotation to be recovered properly.
> >
> > can you post an example event stream of the MT_ENVELOPE tool? I'm having
> > trouble wrapping my head around it.
>
>
> Here is an example for you: You sit in a car. You turn your steering wheel left
> or right to follow the road. Now, imagine that 40% of the time, when you turn
> left, the car actually turns right. This is the behavior you get from the raw
> data. Now, instead soak your gloves in soap. At least now you know that your car
> will go straight 100% of the time. The MT_ENVELOPE tool is the soapy glove.
> That's all there is to it.
>
> The synaptics driver patch sent recently contains an example event stream
> generator, in case you want to dwell on more details.
>
> Personally, I am done bending myself backwards to support "old" or "semi-mt"
> hardware I never use myself. If somebody cares deeply enough, send a patch. Or
> forever hold your peace.
thanks, I understood the concept but I was trying to get the actual event
stream out of this patch set. I missed the synaptics one, makes sense now.
Cheers,
Peter