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

[Chase Douglas]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/