Hi Henrik,
I am trying to link the protocol to the actual multi-touch devices in
my "mind". Hope it helps you to point out the mismatch between my
imagination and the protocol. Please see details in line.
Ping
On Tue, May 18, 2010 at 1:10 PM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote:
> This patch adds documentation for the SYN_MT_SLOT event and
> gives examples of how to use the event slot protocol.
Am I right in thinking that SYN_MT_SLOT represents to the actual touch
area/finger on the surface? There could be more than one (x,y) (a few
points that form an irregular shape) that represents one finger. The
following example shows that slot 0 (finger 1) touched three points on
the surface while slot 1 (finger 2) only has one point reported:
+ SYN_MT_SLOT 0
+ ABS_MT_TRACKING_ID 45
+ ABS_MT_POSITION_X x[0]
+ ABS_MT_POSITION_Y y[0]
+ ABS_MT_TRACKING_ID 46
+ ABS_MT_POSITION_X x[1]
+ ABS_MT_POSITION_Y y[1]
+ ABS_MT_TRACKING_ID 47
+ ABS_MT_POSITION_X x[2]
+ ABS_MT_POSITION_Y y[2]
+ SYN_MT_SLOT 1
+ ABS_MT_TRACKING_ID 30
+ ABS_MT_POSITION_X x[3]
+ ABS_MT_POSITION_Y y[3]
+ SYN_REPORT
If my assumption is correct, i.e., one slot can have more than one
point, I would think ABS_MT_TRACKING_ID may not have to be a required
entry inside SYN_MT_SLOT. To the user land clients/drivers,
SYN_MT_SLOT itself could serve as an ID. So, the following case is
also a type B ( we know there are two touch areas. But we don't keep
track of the points inside the areas):
+ SYN_MT_SLOT 0
+ ABS_MT_POSITION_X x[0]
+ ABS_MT_POSITION_Y y[0]
+ ABS_MT_POSITION_X x[1]
+ ABS_MT_POSITION_Y y[1]
+ ABS_MT_POSITION_X x[2]
+ ABS_MT_POSITION_Y y[2]
+ SYN_MT_SLOT 1
+ ABS_MT_POSITION_X x[3]
+ ABS_MT_POSITION_Y y[3]
+ SYN_REPORT
So, an EVIO for X driver to retrieve the number of SLOTs would be very
helpful. Something like the following would do the work:
input_set_abs_params(input_dev, ABS_MT_SLOT, 0, 12, 0, 0);
which tells the user land clients that they can expect up to 13 touch areas.
> +The main difference between the raw type A protocol and the higher level
> +type B slot protocol lies in the usage of identifiable contacts. The slot
> +protocol requires the use of the ABS_MT_TRACKING_ID,
With what I said above, I think ABS_MT_TRACKING_ID is not the unique
identifier for type B protocol. It is the fact that we can identify
individual touch areas and use ABS_MT_SLOT to report them that makes
it a type B event.
> ABS_MT_TRACKING_ID, either provided by the
> +hardware of computed from the raw data [5].
^^ or (is it?)
I agree with this ABS_MT_TRACKING_ID definition. I would think something like:
input_set_abs_params(input_dev, ABS_MT_TRACKING_ID, 0, 47, 0, 0);
which tells the clients that total of 48 points are tracked, would be helpful.
Another topic that may be irrelevant to this patch is the filter. With
the use of ABS_MT_TRACKING_ID, a filter can be applied to discard the
useless repeated points or less than a certain number of points
movement.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
