Some touch devices are capable of detecting the envelope or hull
of the touches, but not the touches themselves. This patch adds
the MT_TOOL_ENVELOPE touch type to be used for such devices.
Signed-off-by: Henrik Rydberg <[email protected]>
---
Hi all,
This patch represents an MT solution for those devices that can detect
and report some effects of dual touch, but cannot report individual
contacts. Synaptics and elantech are two examples. Having the drivers
report the bounding rectangle of the touches is useful in userland,
since the information makes it possible to implement zooming
gestures. At the same time, it would be confusing to send these
envelope points as fingers, since they clearly are not. As a remedy,
introduce MT_TOOL_ENVELOPE, which tells applications that care about
details that these are not real fingers, at the same time as it allows
gesture applications based on MT data to function without
modification.
Thanks,
Henrik
Documentation/input/multi-touch-protocol.txt | 5 +++--
include/linux/input.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index bdcba15..690dd11 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -240,7 +240,7 @@ 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 [2].
+MT_TOOL_PEN and MT_TOOL_ENVELOPE [2].
ABS_MT_BLOB_ID
@@ -312,7 +312,8 @@ where examples can be found.
[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the
difference between the contact position and the approaching tool position
could be used to derive tilt.
-[2] The list can of course be extended.
+[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/.
[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 dd7c0fc..329dc0e 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -848,6 +848,8 @@ struct input_keymap_entry {
*/
#define MT_TOOL_FINGER 0
#define MT_TOOL_PEN 1
+#define MT_TOOL_ENVELOPE 2
+#define MT_TOOL_MAX 2
/*
* Values describing the status of a force-feedback effect
--
1.7.1
On 12/07/2010 03:29 AM, Henrik Rydberg wrote:
> Some touch devices are capable of detecting the envelope or hull
> of the touches, but not the touches themselves. This patch adds
> the MT_TOOL_ENVELOPE touch type to be used for such devices.
>
> Signed-off-by: Henrik Rydberg <[email protected]>
> ---
> Hi all,
>
> This patch represents an MT solution for those devices that can detect
> and report some effects of dual touch, but cannot report individual
> contacts. Synaptics and elantech are two examples. Having the drivers
> report the bounding rectangle of the touches is useful in userland,
> since the information makes it possible to implement zooming
> gestures. At the same time, it would be confusing to send these
> envelope points as fingers, since they clearly are not. As a remedy,
> introduce MT_TOOL_ENVELOPE, which tells applications that care about
> details that these are not real fingers, at the same time as it allows
> gesture applications based on MT data to function without
> modification.
Is it assumed that the envelop has only two touches comprising it? Or is
it any number of touches? If it's any number of touches, how does one
know how many touches it is?
How are the envelop shape and position determined?
I think the idea is good, I just don't have enough information to
understand how the tool type is supposed to be used. This has been an
issue with many evdev properties, so I'm hoping we can provide more
detailed documentation this time around :).
-- Chase
>> This patch represents an MT solution for those devices that can detect
>> and report some effects of dual touch, but cannot report individual
>> contacts. Synaptics and elantech are two examples. Having the drivers
>> report the bounding rectangle of the touches is useful in userland,
>> since the information makes it possible to implement zooming
>> gestures. At the same time, it would be confusing to send these
>> envelope points as fingers, since they clearly are not. As a remedy,
>> introduce MT_TOOL_ENVELOPE, which tells applications that care about
>> details that these are not real fingers, at the same time as it allows
>> gesture applications based on MT data to function without
>> modification.
>
> Is it assumed that the envelop has only two touches comprising it? Or is
> it any number of touches? If it's any number of touches, how does one
> know how many touches it is?
It could be any number of points, although, as you say, the exact semantics of
multiple points have not yet been defined/documented. Traditionally, a convex
hull is defined as a sequence of points, such that the last links to the first.
It makes sense to define the envelope points similarly. However, we can pass
that bridge as we get there. Right now, we have use for the two-point case. The
number is determined the same was as for fingers - count the number of active slots.
> How are the envelop shape and position determined?
I was imagining a convex polygon shape, but frankly, I see no immediate use for
anything but the bounding rectangle.
> I think the idea is good, I just don't have enough information to
> understand how the tool type is supposed to be used. This has been an
> issue with many evdev properties, so I'm hoping we can provide more
> detailed documentation this time around :).
Yes, it is a good point. The current patch at least documents the intended use,
and seems apt for the moment. We can always add more as the concept matures.
Thanks,
Henrik
On 12/08/2010 10:23 AM, Henrik Rydberg wrote:
>>> This patch represents an MT solution for those devices that can detect
>
>>> and report some effects of dual touch, but cannot report individual
>>> contacts. Synaptics and elantech are two examples. Having the drivers
>>> report the bounding rectangle of the touches is useful in userland,
>>> since the information makes it possible to implement zooming
>>> gestures. At the same time, it would be confusing to send these
>>> envelope points as fingers, since they clearly are not. As a remedy,
>>> introduce MT_TOOL_ENVELOPE, which tells applications that care about
>>> details that these are not real fingers, at the same time as it allows
>>> gesture applications based on MT data to function without
>>> modification.
>>
>> Is it assumed that the envelop has only two touches comprising it? Or is
>> it any number of touches? If it's any number of touches, how does one
>> know how many touches it is?
>
>
> It could be any number of points, although, as you say, the exact semantics of
> multiple points have not yet been defined/documented. Traditionally, a convex
> hull is defined as a sequence of points, such that the last links to the first.
> It makes sense to define the envelope points similarly. However, we can pass
> that bridge as we get there. Right now, we have use for the two-point case. The
> number is determined the same was as for fingers - count the number of active slots.
Ahh. That leaves me with two thoughts:
1. A real convex hull would imply that the points given are correct.
This is the fundamental issue with these touchpads though, and I feel
envelope semantics would only help solve a different problem: touch
object shape.
As you noted, what we are really interested here is a bounding
rectangle. I think Ping has said that Wacom could provide something that
is similar to a real convex hull, and mixing the two concepts together
could cause another ambiguity like BTN_TOOL_DOUBLETAP :).
I suggest merely renaming this to MT_TOOL_RECT to avoid confusion.
2. We could provide for multiple simultaneous rects by using the value
of the MT_TOOL_RECT property. The first rect would have value 0, the
second would have value 1, etc. I don't know if this will ever be used
since most devices will have real MT soon enough, but it wouldn't hurt
to define this.
-- Chase
>> It could be any number of points, although, as you say, the exact semantics
>> of multiple points have not yet been defined/documented. Traditionally, a
>> convex hull is defined as a sequence of points, such that the last links to
>> the first. It makes sense to define the envelope points similarly. However,
>> we can pass that bridge as we get there. Right now, we have use for the
>> two-point case. The number is determined the same was as for fingers - count
>> the number of active slots.
>
> Ahh. That leaves me with two thoughts:
>
> 1. A real convex hull would imply that the points given are correct.
> This is the fundamental issue with these touchpads though, and I feel
> envelope semantics would only help solve a different problem: touch
> object shape.
We have blobs for this case, which is a question in itself. Touch shape has some
basic properties, but common to them all is that all events apply to one touch
id. The envelope points, on the other hand, have different touch ids. Hence, I
think the chance of eventual mixup is still remote. Also, I am not necessarily
thinking of blobs as the first step towards more general shapes. (A pole
expansion might be more useful to applications, for instance.)
> As you noted, what we are really interested here is a bounding
> rectangle. I think Ping has said that Wacom could provide something that
> is similar to a real convex hull, and mixing the two concepts together
> could cause another ambiguity like BTN_TOOL_DOUBLETAP :).
True, we should work towards avoiding such ambiguities.
> I suggest merely renaming this to MT_TOOL_RECT to avoid confusion.
>
> 2. We could provide for multiple simultaneous rects by using the value
> of the MT_TOOL_RECT property. The first rect would have value 0, the
> second would have value 1, etc. I don't know if this will ever be used
> since most devices will have real MT soon enough, but it wouldn't hurt
> to define this.
I do think this is an unnecessary complication.
Thanks,
Henrik
On 12/08/2010 10:52 AM, Henrik Rydberg wrote:
>> As you noted, what we are really interested here is a bounding
>> rectangle. I think Ping has said that Wacom could provide something that
>> is similar to a real convex hull, and mixing the two concepts together
>> could cause another ambiguity like BTN_TOOL_DOUBLETAP :).
>
>
> True, we should work towards avoiding such ambiguities.
>
>> I suggest merely renaming this to MT_TOOL_RECT to avoid confusion.
This is really the main point I wanted to make, even though it was
hidden among other things :). Do you have thoughts here?
>> 2. We could provide for multiple simultaneous rects by using the value
>> of the MT_TOOL_RECT property. The first rect would have value 0, the
>> second would have value 1, etc. I don't know if this will ever be used
>> since most devices will have real MT soon enough, but it wouldn't hurt
>> to define this.
>
> I do think this is an unnecessary complication.
It's not really any complication. I think we should define what the
valid values are for MT_TOOL_{RECT,ENVELOPE} even if only one envelope
is supported. Thus, I don't see why we shouldn't allow for multiple
values for multiple rects.
Hardware manufacturers always seem to surprise us with what they come up
with too :).
-- Chase
>>> I suggest merely renaming this to MT_TOOL_RECT to avoid confusion.
>
> This is really the main point I wanted to make, even though it was
> hidden among other things :). Do you have thoughts here?
I think envelope works fine - it is easier to associate with a single point that
the notion of a rectangle.
>>> 2. We could provide for multiple simultaneous rects by using the value
>>> of the MT_TOOL_RECT property. The first rect would have value 0, the
>>> second would have value 1, etc. I don't know if this will ever be used
>>> since most devices will have real MT soon enough, but it wouldn't hurt
>>> to define this.
>>
>> I do think this is an unnecessary complication.
>
> It's not really any complication. I think we should define what the
> valid values are for MT_TOOL_{RECT,ENVELOPE} even if only one envelope
> is supported. Thus, I don't see why we shouldn't allow for multiple
> values for multiple rects.
>
> Hardware manufacturers always seem to surprise us with what they come up
> with too :).
Yes, which is exciting per se. However, hardware seems to be moving towards more
individual (and tracked) contacts, and more granularity per contact. The idea of
supporting complex, non-connected boundaries (implication of your proposal),
which by construction contains less information that the individual contacts,
seems to be going against that trend. Since there are no current need for it,
and the indications point in a different direction, I suggest we put that in the
bag of possible "I told you so", and leave it open for now. ;-)
Cheers,
Henrik
I have seen this touchless touchpad hardware?(huh?)
it detects finger/hand and it's better explained by a video:
http://www.youtube.com/watch?v=6SjMdtdhXlA
How it fit in the convex notion?
i
On 12/08/2010 08:51 PM, Mohamed Ikbel Boulabiar wrote:
> I have seen this touchless touchpad hardware (huh?)
> it detects finger/hand and it's better explained by a video:
> http://www.youtube.com/watch?v=6SjMdtdhXlA
>
> How it fit in the convex notion?
This is precisely what the patch for ABS_MT_DISTANCE is for. Perhaps you meant
to comment on that email. This one is about support for hardware without
individual finger detection capabilities.
Henrik
On Wed, Dec 8, 2010 at 9:02 PM, Henrik Rydberg <[email protected]> wrote:
> This is precisely what the patch for ABS_MT_DISTANCE is for. Perhaps you meant
> to comment on that email. This one is about support for hardware without
> individual finger detection capabilities.
yes, I mixed up mails :)
i
On 12/08/2010 11:23 AM, Henrik Rydberg wrote:
>>>> I suggest merely renaming this to MT_TOOL_RECT to avoid confusion.
>
>>
>> This is really the main point I wanted to make, even though it was
>> hidden among other things :). Do you have thoughts here?
>
>
> I think envelope works fine - it is easier to associate with a single point that
> the notion of a rectangle.
I thought we were talking specifically about two points? If I'm wrong,
the following won't make any sense either :).
There would be two slots with MT_TOOL_ENVELOPE set to 1. These define
the two possible combinations of touch points. I can't see how this
concept could be expanded any further than a rectangle without switcing
to full MT, thus I think it would be clearer to define it as such.
This all drives at the heart of the frustrations felt about evdev
property naming and documentation. The envelope tool, as you've
proposed, is only useful for defining rectangles. I think leaving it
named envelope is just begging for misuse, just as BTN_TOOL_DOUBLETAP
has been misused.
Perhaps it will be clearer to me why you like the name envelope if I
could read the formal documentation that would be merged along with the
new property name. The documentation added by the patch just isn't
enough to understand what it's for or how to use it, and the discussion
so far hasn't left me with the feeling that MT_TOOL_ENVELOPE is the best
name.
-- Chase
On Wed, Dec 8, 2010 at 9:43 AM, Chase Douglas
<[email protected]> wrote:
> On 12/07/2010 03:29 AM, Henrik Rydberg wrote:
>> Some touch devices are capable of detecting the envelope or hull
>> of the touches, but not the touches themselves. This patch adds
>> the MT_TOOL_ENVELOPE touch type to be used for such devices.
>>
>> Signed-off-by: Henrik Rydberg <[email protected]>
>> ---
>> Hi all,
>>
>> This patch represents an MT solution for those devices that can detect
>> and report some effects of dual touch, but cannot report individual
>> contacts. Synaptics and elantech are two examples. Having the drivers
>> report the bounding rectangle of the touches is useful in userland,
>> since the information makes it possible to implement zooming
>> gestures. At the same time, it would be confusing to send these
>> envelope points as fingers, since they clearly are not. As a remedy,
>> introduce MT_TOOL_ENVELOPE, which tells applications that care about
>> details that these are not real fingers, at the same time as it allows
>> gesture applications based on MT data to function without
>> modification.
>
> Is it assumed that the envelop has only two touches comprising it? Or is
> it any number of touches? If it's any number of touches, how does one
> know how many touches it is?
Those are good questions. Specifying how many touches are in the
envelop makes sense. It also covers rectangle as a special case of
envelop.
Ping
> How are the envelop shape and position determined?
>
> I think the idea is good, I just don't have enough information to
> understand how the tool type is supposed to be used. This has been an
> issue with many evdev properties, so I'm hoping we can provide more
> detailed documentation this time around :).
>
> -- 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
>
On Wed, Dec 08, 2010 at 03:43:51PM -0800, Ping Cheng wrote:
> On Wed, Dec 8, 2010 at 9:43 AM, Chase Douglas
> <[email protected]> wrote:
> > On 12/07/2010 03:29 AM, Henrik Rydberg wrote:
> >> Some touch devices are capable of detecting the envelope or hull
> >> of the touches, but not the touches themselves. This patch adds
> >> the MT_TOOL_ENVELOPE touch type to be used for such devices.
> >>
> >> Signed-off-by: Henrik Rydberg <[email protected]>
> >> ---
> >> Hi all,
> >>
> >> This patch represents an MT solution for those devices that can detect
> >> and report some effects of dual touch, but cannot report individual
> >> contacts. Synaptics and elantech are two examples. Having the drivers
> >> report the bounding rectangle of the touches is useful in userland,
> >> since the information makes it possible to implement zooming
> >> gestures. At the same time, it would be confusing to send these
> >> envelope points as fingers, since they clearly are not. As a remedy,
> >> introduce MT_TOOL_ENVELOPE, which tells applications that care about
> >> details that these are not real fingers, at the same time as it allows
> >> gesture applications based on MT data to function without
> >> modification.
> >
> > Is it assumed that the envelop has only two touches comprising it? Or is
> > it any number of touches? If it's any number of touches, how does one
> > know how many touches it is?
>
> Those are good questions. Specifying how many touches are in the
> envelop makes sense. It also covers rectangle as a special case of
> envelop.
I have a feeling that trying to accomodate non-rectangular, more than 2
point shapes without using native MT data is over-engineering the
problem... Do we have examples other than older generation Elantechs and
Synaptics that need envelope notion?
--
Dmitry
On Wed, Dec 8, 2010 at 3:58 PM, Dmitry Torokhov
<[email protected]> wrote:
> On Wed, Dec 08, 2010 at 03:43:51PM -0800, Ping Cheng wrote:
>> On Wed, Dec 8, 2010 at 9:43 AM, Chase Douglas
>> <[email protected]> wrote:
>> > On 12/07/2010 03:29 AM, Henrik Rydberg wrote:
>> >> Some touch devices are capable of detecting the envelope or hull
>> >> of the touches, but not the touches themselves. This patch adds
>> >> the MT_TOOL_ENVELOPE touch type to be used for such devices.
>> >>
>> >> Signed-off-by: Henrik Rydberg <[email protected]>
>> >> ---
>> >> Hi all,
>> >>
>> >> This patch represents an MT solution for those devices that can detect
>> >> and report some effects of dual touch, but cannot report individual
>> >> contacts. Synaptics and elantech are two examples. Having the drivers
>> >> report the bounding rectangle of the touches is useful in userland,
>> >> since the information makes it possible to implement zooming
>> >> gestures. At the same time, it would be confusing to send these
>> >> envelope points as fingers, since they clearly are not. As a remedy,
>> >> introduce MT_TOOL_ENVELOPE, which tells applications that care about
>> >> details that these are not real fingers, at the same time as it allows
>> >> gesture applications based on MT data to function without
>> >> modification.
>> >
>> > Is it assumed that the envelop has only two touches comprising it? Or is
>> > it any number of touches? If it's any number of touches, how does one
>> > know how many touches it is?
>>
>> Those are good questions. Specifying how many touches are in the
>> envelop makes sense. It also covers rectangle as a special case of
>> envelop.
>
> I have a feeling that trying to accomodate non-rectangular,
No, we are not talking about non-rectangular shape here. Envelop is
always a rectangle. By rectangle above, I meant 2 touches.
An envelop that includes number of touches offers us more information
than a rectangle does.
Ping
> more than 2 point shapes without using native MT data is over-engineering the
> problem... Do we have examples other than older generation Elantechs and
> Synaptics that need envelope notion?
>
> --
> Dmitry
>
>>>
>>> Is it assumed that the envelop has only two touches comprising it? Or is
>>> it any number of touches? If it's any number of touches, how does one
>>> know how many touches it is?
>>
>> Those are good questions. Specifying how many touches are in the
>> envelop makes sense. It also covers rectangle as a special case of
>> envelop.
>
> I have a feeling that trying to accomodate non-rectangular, more than 2
> point shapes without using native MT data is over-engineering the
> problem... Do we have examples other than older generation Elantechs and
> Synaptics that need envelope notion?
>
Those are the ones targeted so far. Maybe appletouch could be added to the list
as well. I imagine all drivers will end up using zero, one and two envelope points.
Henrik
On Thu, Dec 09, 2010 at 02:12:08AM +0100, Henrik Rydberg wrote:
> >>>
>
> >>> Is it assumed that the envelop has only two touches comprising it? Or is
> >>> it any number of touches? If it's any number of touches, how does one
> >>> know how many touches it is?
> >>
> >> Those are good questions. Specifying how many touches are in the
> >> envelop makes sense. It also covers rectangle as a special case of
> >> envelop.
> >
> > I have a feeling that trying to accomodate non-rectangular, more than 2
> > point shapes without using native MT data is over-engineering the
> > problem... Do we have examples other than older generation Elantechs and
> > Synaptics that need envelope notion?
> >
>
>
> Those are the ones targeted so far. Maybe appletouch could be added to the list
> as well. I imagine all drivers will end up using zero, one and two envelope points.
Even ones that fully support independent finger tracking?
--
Dmitry
>>> Those are good questions. Specifying how many touches are in the
>>> envelop makes sense. It also covers rectangle as a special case of
>>> envelop.
>>
>> I have a feeling that trying to accomodate non-rectangular,
>
> No, we are not talking about non-rectangular shape here. Envelop is
> always a rectangle. By rectangle above, I meant 2 touches.
>
> An envelop that includes number of touches offers us more information
> than a rectangle does.
All you need to do to know how many points there are is to count them. :-)
Henrik
On Wed, Dec 8, 2010 at 5:12 PM, Henrik Rydberg <[email protected]> wrote:
>>>>
>
>>>> Is it assumed that the envelop has only two touches comprising it? Or is
>>>> it any number of touches? If it's any number of touches, how does one
>>>> know how many touches it is?
>>>
>>> Those are good questions. Specifying how many touches are in the
>>> envelop makes sense. It also covers rectangle as a special case of
>>> envelop.
>>
>> I have a feeling that trying to accomodate non-rectangular, more than 2
>> point shapes without using native MT data is over-engineering the
>> problem... Do we have examples other than older generation Elantechs and
>> Synaptics that need envelope notion?
>>
>
>
> Those are the ones targeted so far. Maybe appletouch could be added to the list
> as well. I imagine all drivers will end up using zero, one and two envelope points.
What are the "points" here? Do you mean the points inside the envelope
or number of envelopes?
Ping
On Wed, Dec 8, 2010 at 5:18 PM, Henrik Rydberg <[email protected]> wrote:
>>>> Those are good questions. Specifying how many touches are in the
>
>>>> envelop makes sense. It also covers rectangle as a special case of
>>>> envelop.
>>>
>>> I have a feeling that trying to accomodate non-rectangular,
>>
>> No, we are not talking about non-rectangular shape here. Envelop is
>> always a rectangle. By rectangle above, I meant 2 touches.
>>
>> An envelop that includes number of touches offers us more information
>> than a rectangle does.
>
>
> All you need to do to know how many points there are is to count them. :-)
Yeah, you are right. What if the client does not have the information
to count them if we do not pass them over?
Ping
On 12/09/2010 02:17 AM, Dmitry Torokhov wrote:
> On Thu, Dec 09, 2010 at 02:12:08AM +0100, Henrik Rydberg wrote:
>>>>>
>>
>>>>> Is it assumed that the envelop has only two touches comprising it? Or is
>>>>> it any number of touches? If it's any number of touches, how does one
>>>>> know how many touches it is?
>>>>
>>>> Those are good questions. Specifying how many touches are in the
>>>> envelop makes sense. It also covers rectangle as a special case of
>>>> envelop.
>>>
>>> I have a feeling that trying to accomodate non-rectangular, more than 2
>>> point shapes without using native MT data is over-engineering the
>>> problem... Do we have examples other than older generation Elantechs and
>>> Synaptics that need envelope notion?
>>>
>>
>>
>> Those are the ones targeted so far. Maybe appletouch could be added to the list
>> as well. I imagine all drivers will end up using zero, one and two envelope points.
>
> Even ones that fully support independent finger tracking?
>
No, sorry, that should read "all drivers in that list". The ones that can detect
individual fingers in space are fine as they are.
On Thu, Dec 9, 2010 at 1:06 AM, Ping Cheng <[email protected]> wrote:
> No, we are not talking about non-rectangular shape here. Envelop is
> always a rectangle. By rectangle above, I meant 2 touches.
>
> An envelop that includes number of touches offers us more information
> than a rectangle does
Can we have more information that just a rect ? An ellipse for exemple.
Can we get this information at least from synaptics touchpads?
i
On 12/09/2010 02:38 AM, Mohamed Ikbel Boulabiar wrote:
> On Thu, Dec 9, 2010 at 1:06 AM, Ping Cheng <[email protected]> wrote:
>> No, we are not talking about non-rectangular shape here. Envelop is
>> always a rectangle. By rectangle above, I meant 2 touches.
>>
>> An envelop that includes number of touches offers us more information
>> than a rectangle does
>
> Can we have more information that just a rect ? An ellipse for exemple.
> Can we get this information at least from synaptics touchpads?
Unfortunately not. Chris Bagwell and myself have been experimenting with quite a
few different approaches to extract touch information from the synaptics pads.
The present approach, to extract the bounding rectangle, is the best we can do,
I am afraid - at least with the information unveiled in Takashi's original
patch. In particular, rotation information is not reliably extractable.
Henrik
>
> What are the "points" here? Do you mean the points inside the envelope
> or number of envelopes?
Oh well, I take this and Chase's comments as a hint that the documentation
should have a section of MT_TOOL types, and each tool type should be explained,
in particular the new MT_TOOL_ENVELOPE. It should also help when/if converting
the Pen&Touch logic to MT.
Thanks.
Henrik