[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CFFCD10.5030202@euromail.se>
Date: Wed, 08 Dec 2010 19:23:12 +0100
From: Henrik Rydberg <rydberg@...omail.se>
To: Chase Douglas <chase.douglas@...onical.com>
CC: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jiri Kosina <jkosina@...e.cz>, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: mt: Add an envelope tool type
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists