Re: [PATCH] input: mt: Add an envelope tool type

From: Henrik Rydberg <rydberg@euromail.se>
To: Chase Douglas <chase.douglas@canonical.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jiri Kosina <jkosina@suse.cz>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] input: mt: Add an envelope tool type
Date: Wed, 08 Dec 2010 19:52:46 +0100	[thread overview]
Message-ID: <4CFFD3FE.1090103@euromail.se> (raw)
In-Reply-To: <4CFFD0BF.2020601@canonical.com>

>> 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