Commit | Line | Data |
---|---|---|
eba31a3a MCC |
1 | .. include:: <isonum.txt> |
2 | ||
3 | ========================= | |
eacaad01 | 4 | Multi-touch (MT) Protocol |
eba31a3a MCC |
5 | ========================= |
6 | ||
7 | :Copyright: |copy| 2009-2010 Henrik Rydberg <rydberg@euromail.se> | |
eacaad01 HR |
8 | |
9 | ||
10 | Introduction | |
11 | ------------ | |
12 | ||
72c8a94a HR |
13 | In order to utilize the full power of the new multi-touch and multi-user |
14 | devices, a way to report detailed data from multiple contacts, i.e., | |
15 | objects in direct contact with the device surface, is needed. This | |
16 | document describes the multi-touch (MT) protocol which allows kernel | |
17 | drivers to report details for an arbitrary number of contacts. | |
18 | ||
19 | The protocol is divided into two types, depending on the capabilities of the | |
20 | hardware. For devices handling anonymous contacts (type A), the protocol | |
21 | describes how to send the raw data for all contacts to the receiver. For | |
22 | devices capable of tracking identifiable contacts (type B), the protocol | |
23 | describes how to send updates for individual contacts via event slots. | |
24 | ||
6c6d5752 DT |
25 | .. note:: |
26 | MT potocol type A is obsolete, all kernel drivers have been | |
27 | converted to use type B. | |
72c8a94a HR |
28 | |
29 | Protocol Usage | |
30 | -------------- | |
31 | ||
32 | Contact details are sent sequentially as separate packets of ABS_MT | |
33 | events. Only the ABS_MT events are recognized as part of a contact | |
34 | packet. Since these events are ignored by current single-touch (ST) | |
35 | applications, the MT protocol can be implemented on top of the ST protocol | |
36 | in an existing driver. | |
37 | ||
38 | Drivers for type A devices separate contact packets by calling | |
39 | input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT | |
40 | event, which instructs the receiver to accept the data for the current | |
41 | contact and prepare to receive another. | |
42 | ||
43 | Drivers for type B devices separate contact packets by calling | |
44 | input_mt_slot(), with a slot as argument, at the beginning of each packet. | |
45 | This generates an ABS_MT_SLOT event, which instructs the receiver to | |
46 | prepare for updates of the given slot. | |
47 | ||
48 | All drivers mark the end of a multi-touch transfer by calling the usual | |
49 | input_sync() function. This instructs the receiver to act upon events | |
50 | accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set | |
51 | of events/packets. | |
52 | ||
53 | The main difference between the stateless type A protocol and the stateful | |
54 | type B slot protocol lies in the usage of identifiable contacts to reduce | |
55 | the amount of data sent to userspace. The slot protocol requires the use of | |
56 | the ABS_MT_TRACKING_ID, either provided by the hardware or computed from | |
eba31a3a | 57 | the raw data [#f5]_. |
72c8a94a HR |
58 | |
59 | For type A devices, the kernel driver should generate an arbitrary | |
60 | enumeration of the full set of anonymous contacts currently on the | |
61 | surface. The order in which the packets appear in the event stream is not | |
eba31a3a | 62 | important. Event filtering and finger tracking is left to user space [#f3]_. |
72c8a94a HR |
63 | |
64 | For type B devices, the kernel driver should associate a slot with each | |
65 | identified contact, and use that slot to propagate changes for the contact. | |
66 | Creation, replacement and destruction of contacts is achieved by modifying | |
67 | the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id | |
68 | is interpreted as a contact, and the value -1 denotes an unused slot. A | |
69 | tracking id not previously present is considered new, and a tracking id no | |
70 | longer present is considered removed. Since only changes are propagated, | |
71 | the full state of each initiated contact has to reside in the receiving | |
72 | end. Upon receiving an MT event, one simply updates the appropriate | |
73 | attribute of the current slot. | |
74 | ||
a93bd154 DK |
75 | Some devices identify and/or track more contacts than they can report to the |
76 | driver. A driver for such a device should associate one type B slot with each | |
77 | contact that is reported by the hardware. Whenever the identity of the | |
78 | contact associated with a slot changes, the driver should invalidate that | |
79 | slot by changing its ABS_MT_TRACKING_ID. If the hardware signals that it is | |
80 | tracking more contacts than it is currently reporting, the driver should use | |
81 | a BTN_TOOL_*TAP event to inform userspace of the total number of contacts | |
82 | being tracked by the hardware at that moment. The driver should do this by | |
83 | explicitly sending the corresponding BTN_TOOL_*TAP event and setting | |
84 | use_count to false when calling input_mt_report_pointer_emulation(). | |
85 | The driver should only advertise as many slots as the hardware can report. | |
86 | Userspace can detect that a driver can report more total contacts than slots | |
87 | by noting that the largest supported BTN_TOOL_*TAP event is larger than the | |
88 | total number of type B slots reported in the absinfo for the ABS_MT_SLOT axis. | |
72c8a94a | 89 | |
257867dc PH |
90 | The minimum value of the ABS_MT_SLOT axis must be 0. |
91 | ||
72c8a94a HR |
92 | Protocol Example A |
93 | ------------------ | |
94 | ||
95 | Here is what a minimal event sequence for a two-contact touch would look | |
eba31a3a | 96 | like for a type A device:: |
72c8a94a HR |
97 | |
98 | ABS_MT_POSITION_X x[0] | |
99 | ABS_MT_POSITION_Y y[0] | |
100 | SYN_MT_REPORT | |
101 | ABS_MT_POSITION_X x[1] | |
102 | ABS_MT_POSITION_Y y[1] | |
103 | SYN_MT_REPORT | |
104 | SYN_REPORT | |
eacaad01 | 105 | |
72c8a94a HR |
106 | The sequence after moving one of the contacts looks exactly the same; the |
107 | raw data for all present contacts are sent between every synchronization | |
108 | with SYN_REPORT. | |
eacaad01 | 109 | |
eba31a3a | 110 | Here is the sequence after lifting the first contact:: |
eacaad01 | 111 | |
72c8a94a HR |
112 | ABS_MT_POSITION_X x[1] |
113 | ABS_MT_POSITION_Y y[1] | |
114 | SYN_MT_REPORT | |
115 | SYN_REPORT | |
116 | ||
eba31a3a | 117 | And here is the sequence after lifting the second contact:: |
72c8a94a HR |
118 | |
119 | SYN_MT_REPORT | |
120 | SYN_REPORT | |
121 | ||
122 | If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the | |
123 | ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the | |
124 | last SYN_REPORT will be dropped by the input core, resulting in no | |
125 | zero-contact event reaching userland. | |
126 | ||
127 | ||
128 | Protocol Example B | |
129 | ------------------ | |
130 | ||
131 | Here is what a minimal event sequence for a two-contact touch would look | |
eba31a3a | 132 | like for a type B device:: |
72c8a94a HR |
133 | |
134 | ABS_MT_SLOT 0 | |
135 | ABS_MT_TRACKING_ID 45 | |
136 | ABS_MT_POSITION_X x[0] | |
137 | ABS_MT_POSITION_Y y[0] | |
138 | ABS_MT_SLOT 1 | |
139 | ABS_MT_TRACKING_ID 46 | |
140 | ABS_MT_POSITION_X x[1] | |
141 | ABS_MT_POSITION_Y y[1] | |
142 | SYN_REPORT | |
143 | ||
eba31a3a | 144 | Here is the sequence after moving contact 45 in the x direction:: |
72c8a94a HR |
145 | |
146 | ABS_MT_SLOT 0 | |
147 | ABS_MT_POSITION_X x[0] | |
148 | SYN_REPORT | |
149 | ||
eba31a3a | 150 | Here is the sequence after lifting the contact in slot 0:: |
72c8a94a HR |
151 | |
152 | ABS_MT_TRACKING_ID -1 | |
153 | SYN_REPORT | |
154 | ||
155 | The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The | |
156 | message removes the association of slot 0 with contact 45, thereby | |
157 | destroying contact 45 and freeing slot 0 to be reused for another contact. | |
158 | ||
eba31a3a | 159 | Finally, here is the sequence after lifting the second contact:: |
72c8a94a HR |
160 | |
161 | ABS_MT_SLOT 1 | |
162 | ABS_MT_TRACKING_ID -1 | |
163 | SYN_REPORT | |
164 | ||
165 | ||
166 | Event Usage | |
167 | ----------- | |
eacaad01 HR |
168 | |
169 | A set of ABS_MT events with the desired properties is defined. The events | |
170 | are divided into categories, to allow for partial implementation. The | |
f6bdc230 | 171 | minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which |
72c8a94a | 172 | allows for multiple contacts to be tracked. If the device supports it, the |
f6bdc230 | 173 | ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size |
cab7faca | 174 | of the contact area and approaching tool, respectively. |
f6bdc230 HR |
175 | |
176 | The TOUCH and WIDTH parameters have a geometrical interpretation; imagine | |
177 | looking through a window at someone gently holding a finger against the | |
178 | glass. You will see two regions, one inner region consisting of the part | |
179 | of the finger actually touching the glass, and one outer region formed by | |
cab7faca HR |
180 | the perimeter of the finger. The center of the touching region (a) is |
181 | ABS_MT_POSITION_X/Y and the center of the approaching finger (b) is | |
182 | ABS_MT_TOOL_X/Y. The touch diameter is ABS_MT_TOUCH_MAJOR and the finger | |
183 | diameter is ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger | |
184 | harder against the glass. The touch region will increase, and in general, | |
185 | the ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller | |
186 | than unity, is related to the contact pressure. For pressure-based devices, | |
f6bdc230 | 187 | ABS_MT_PRESSURE may be used to provide the pressure on the contact area |
e42a98b5 HR |
188 | instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to |
189 | indicate the distance between the contact and the surface. | |
f6bdc230 | 190 | |
eba31a3a MCC |
191 | :: |
192 | ||
cab7faca HR |
193 | |
194 | Linux MT Win8 | |
195 | __________ _______________________ | |
196 | / \ | | | |
197 | / \ | | | |
198 | / ____ \ | | | |
199 | / / \ \ | | | |
200 | \ \ a \ \ | a | | |
201 | \ \____/ \ | | | |
202 | \ \ | | | |
203 | \ b \ | b | | |
204 | \ \ | | | |
205 | \ \ | | | |
206 | \ \ | | | |
207 | \ / | | | |
208 | \ / | | | |
209 | \ / | | | |
210 | \__________/ |_______________________| | |
211 | ||
212 | ||
213 | In addition to the MAJOR parameters, the oval shape of the touch and finger | |
214 | regions can be described by adding the MINOR parameters, such that MAJOR | |
215 | and MINOR are the major and minor axis of an ellipse. The orientation of | |
216 | the touch ellipse can be described with the ORIENTATION parameter, and the | |
217 | direction of the finger ellipse is given by the vector (a - b). | |
f6bdc230 | 218 | |
22f075a8 HR |
219 | For type A devices, further specification of the touch shape is possible |
220 | via ABS_MT_BLOB_ID. | |
221 | ||
f6bdc230 | 222 | The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a |
22f075a8 | 223 | finger or a pen or something else. Finally, the ABS_MT_TRACKING_ID event |
eba31a3a | 224 | may be used to track identified contacts over time [#f5]_. |
22f075a8 HR |
225 | |
226 | In the type B protocol, ABS_MT_TOOL_TYPE and ABS_MT_TRACKING_ID are | |
227 | implicitly handled by input core; drivers should instead call | |
228 | input_mt_report_slot_state(). | |
f9fcfc3b | 229 | |
eacaad01 HR |
230 | |
231 | Event Semantics | |
232 | --------------- | |
233 | ||
eacaad01 | 234 | ABS_MT_TOUCH_MAJOR |
eba31a3a MCC |
235 | The length of the major axis of the contact. The length should be given in |
236 | surface units. If the surface has an X times Y resolution, the largest | |
237 | possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal [#f4]_. | |
eacaad01 HR |
238 | |
239 | ABS_MT_TOUCH_MINOR | |
eba31a3a MCC |
240 | The length, in surface units, of the minor axis of the contact. If the |
241 | contact is circular, this event can be omitted [#f4]_. | |
eacaad01 HR |
242 | |
243 | ABS_MT_WIDTH_MAJOR | |
eba31a3a MCC |
244 | The length, in surface units, of the major axis of the approaching |
245 | tool. This should be understood as the size of the tool itself. The | |
246 | orientation of the contact and the approaching tool are assumed to be the | |
247 | same [#f4]_. | |
eacaad01 HR |
248 | |
249 | ABS_MT_WIDTH_MINOR | |
eba31a3a MCC |
250 | The length, in surface units, of the minor axis of the approaching |
251 | tool. Omit if circular [#f4]_. | |
eacaad01 | 252 | |
eba31a3a MCC |
253 | The above four values can be used to derive additional information about |
254 | the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates | |
255 | the notion of pressure. The fingers of the hand and the palm all have | |
256 | different characteristic widths. | |
eacaad01 | 257 | |
f6bdc230 | 258 | ABS_MT_PRESSURE |
eba31a3a MCC |
259 | The pressure, in arbitrary units, on the contact area. May be used instead |
260 | of TOUCH and WIDTH for pressure-based devices or any device with a spatial | |
261 | signal intensity distribution. | |
f6bdc230 | 262 | |
e42a98b5 | 263 | ABS_MT_DISTANCE |
eba31a3a MCC |
264 | The distance, in surface units, between the contact and the surface. Zero |
265 | distance means the contact is touching the surface. A positive number means | |
266 | the contact is hovering above the surface. | |
e42a98b5 | 267 | |
eacaad01 | 268 | ABS_MT_ORIENTATION |
eba31a3a MCC |
269 | The orientation of the touching ellipse. The value should describe a signed |
270 | quarter of a revolution clockwise around the touch center. The signed value | |
271 | range is arbitrary, but zero should be returned for an ellipse aligned with | |
00720277 WNH |
272 | the Y axis (north) of the surface, a negative value when the ellipse is |
273 | turned to the left, and a positive value when the ellipse is turned to the | |
274 | right. When aligned with the X axis in the positive direction, the range | |
275 | max should be returned; when aligned with the X axis in the negative | |
276 | direction, the range -max should be returned. | |
eba31a3a MCC |
277 | |
278 | Touch ellipsis are symmetrical by default. For devices capable of true 360 | |
279 | degree orientation, the reported orientation must exceed the range max to | |
280 | indicate more than a quarter of a revolution. For an upside-down finger, | |
281 | range max * 2 should be returned. | |
282 | ||
283 | Orientation can be omitted if the touch area is circular, or if the | |
284 | information is not available in the kernel driver. Partial orientation | |
285 | support is possible if the device can distinguish between the two axis, but | |
286 | not (uniquely) any values in between. In such cases, the range of | |
287 | ABS_MT_ORIENTATION should be [0, 1] [#f4]_. | |
eacaad01 HR |
288 | |
289 | ABS_MT_POSITION_X | |
eba31a3a | 290 | The surface X coordinate of the center of the touching ellipse. |
eacaad01 HR |
291 | |
292 | ABS_MT_POSITION_Y | |
eba31a3a | 293 | The surface Y coordinate of the center of the touching ellipse. |
eacaad01 | 294 | |
cab7faca | 295 | ABS_MT_TOOL_X |
eba31a3a MCC |
296 | The surface X coordinate of the center of the approaching tool. Omit if |
297 | the device cannot distinguish between the intended touch point and the | |
298 | tool itself. | |
cab7faca HR |
299 | |
300 | ABS_MT_TOOL_Y | |
eba31a3a MCC |
301 | The surface Y coordinate of the center of the approaching tool. Omit if the |
302 | device cannot distinguish between the intended touch point and the tool | |
303 | itself. | |
cab7faca | 304 | |
eba31a3a MCC |
305 | The four position values can be used to separate the position of the touch |
306 | from the position of the tool. If both positions are present, the major | |
307 | tool axis points towards the touch point [#f1]_. Otherwise, the tool axes are | |
308 | aligned with the touch axes. | |
cab7faca | 309 | |
eacaad01 | 310 | ABS_MT_TOOL_TYPE |
eba31a3a MCC |
311 | The type of approaching tool. A lot of kernel drivers cannot distinguish |
312 | between different tool types, such as a finger or a pen. In such cases, the | |
b875a5a5 BT |
313 | event should be omitted. The protocol currently mainly supports |
314 | MT_TOOL_FINGER, MT_TOOL_PEN, and MT_TOOL_PALM [#f2]_. | |
315 | For type B devices, this event is handled by input core; drivers should | |
316 | instead use input_mt_report_slot_state(). A contact's ABS_MT_TOOL_TYPE may | |
317 | change over time while still touching the device, because the firmware may | |
318 | not be able to determine which tool is being used when it first appears. | |
eacaad01 HR |
319 | |
320 | ABS_MT_BLOB_ID | |
eba31a3a MCC |
321 | The BLOB_ID groups several packets together into one arbitrarily shaped |
322 | contact. The sequence of points forms a polygon which defines the shape of | |
323 | the contact. This is a low-level anonymous grouping for type A devices, and | |
324 | should not be confused with the high-level trackingID [#f5]_. Most type A | |
325 | devices do not have blob capability, so drivers can safely omit this event. | |
f9fcfc3b HR |
326 | |
327 | ABS_MT_TRACKING_ID | |
eba31a3a MCC |
328 | The TRACKING_ID identifies an initiated contact throughout its life cycle |
329 | [#f5]_. The value range of the TRACKING_ID should be large enough to ensure | |
330 | unique identification of a contact maintained over an extended period of | |
331 | time. For type B devices, this event is handled by input core; drivers | |
332 | should instead use input_mt_report_slot_state(). | |
f9fcfc3b HR |
333 | |
334 | ||
335 | Event Computation | |
336 | ----------------- | |
337 | ||
338 | The flora of different hardware unavoidably leads to some devices fitting | |
339 | better to the MT protocol than others. To simplify and unify the mapping, | |
340 | this section gives recipes for how to compute certain events. | |
341 | ||
342 | For devices reporting contacts as rectangular shapes, signed orientation | |
343 | cannot be obtained. Assuming X and Y are the lengths of the sides of the | |
344 | touching rectangle, here is a simple formula that retains the most | |
eba31a3a | 345 | information possible:: |
f9fcfc3b HR |
346 | |
347 | ABS_MT_TOUCH_MAJOR := max(X, Y) | |
348 | ABS_MT_TOUCH_MINOR := min(X, Y) | |
349 | ABS_MT_ORIENTATION := bool(X > Y) | |
350 | ||
351 | The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that | |
352 | the device can distinguish between a finger along the Y axis (0) and a | |
353 | finger along the X axis (1). | |
eacaad01 | 354 | |
eba31a3a | 355 | For win8 devices with both T and C coordinates, the position mapping is:: |
cab7faca HR |
356 | |
357 | ABS_MT_POSITION_X := T_X | |
358 | ABS_MT_POSITION_Y := T_Y | |
359 | ABS_MT_TOOL_X := C_X | |
b1452723 | 360 | ABS_MT_TOOL_Y := C_Y |
cab7faca HR |
361 | |
362 | Unfortunately, there is not enough information to specify both the touching | |
363 | ellipse and the tool ellipse, so one has to resort to approximations. One | |
eba31a3a | 364 | simple scheme, which is compatible with earlier usage, is:: |
cab7faca HR |
365 | |
366 | ABS_MT_TOUCH_MAJOR := min(X, Y) | |
367 | ABS_MT_TOUCH_MINOR := <not used> | |
368 | ABS_MT_ORIENTATION := <not used> | |
369 | ABS_MT_WIDTH_MAJOR := min(X, Y) + distance(T, C) | |
370 | ABS_MT_WIDTH_MINOR := min(X, Y) | |
371 | ||
372 | Rationale: We have no information about the orientation of the touching | |
373 | ellipse, so approximate it with an inscribed circle instead. The tool | |
df5cbb27 | 374 | ellipse should align with the vector (T - C), so the diameter must |
cab7faca HR |
375 | increase with distance(T, C). Finally, assume that the touch diameter is |
376 | equal to the tool thickness, and we arrive at the formulas above. | |
eacaad01 HR |
377 | |
378 | Finger Tracking | |
379 | --------------- | |
380 | ||
f9fcfc3b | 381 | The process of finger tracking, i.e., to assign a unique trackingID to each |
72c8a94a HR |
382 | initiated contact on the surface, is a Euclidian Bipartite Matching |
383 | problem. At each event synchronization, the set of actual contacts is | |
384 | matched to the set of contacts from the previous synchronization. A full | |
eba31a3a | 385 | implementation can be found in [#f3]_. |
f9fcfc3b HR |
386 | |
387 | ||
f6bdc230 HR |
388 | Gestures |
389 | -------- | |
390 | ||
391 | In the specific application of creating gesture events, the TOUCH and WIDTH | |
392 | parameters can be used to, e.g., approximate finger pressure or distinguish | |
393 | between index finger and thumb. With the addition of the MINOR parameters, | |
394 | one can also distinguish between a sweeping finger and a pointing finger, | |
395 | and with ORIENTATION, one can detect twisting of fingers. | |
396 | ||
397 | ||
eacaad01 HR |
398 | Notes |
399 | ----- | |
400 | ||
22f075a8 HR |
401 | In order to stay compatible with existing applications, the data reported |
402 | in a finger packet must not be recognized as single-touch events. | |
403 | ||
404 | For type A devices, all finger data bypasses input filtering, since | |
405 | subsequent events of the same type refer to different fingers. | |
eacaad01 | 406 | |
eba31a3a MCC |
407 | .. [#f1] Also, the difference (TOOL_X - POSITION_X) can be used to model tilt. |
408 | .. [#f2] The list can of course be extended. | |
409 | .. [#f3] The mtdev project: http://bitmath.org/code/mtdev/. | |
410 | .. [#f4] See the section on event computation. | |
411 | .. [#f5] See the section on finger tracking. |