Commit | Line | Data |
---|---|---|
eacaad01 HR |
1 | Multi-touch (MT) Protocol |
2 | ------------------------- | |
3 | Copyright (C) 2009 Henrik Rydberg <rydberg@euromail.se> | |
4 | ||
5 | ||
6 | Introduction | |
7 | ------------ | |
8 | ||
72c8a94a HR |
9 | In order to utilize the full power of the new multi-touch and multi-user |
10 | devices, a way to report detailed data from multiple contacts, i.e., | |
11 | objects in direct contact with the device surface, is needed. This | |
12 | document describes the multi-touch (MT) protocol which allows kernel | |
13 | drivers to report details for an arbitrary number of contacts. | |
14 | ||
15 | The protocol is divided into two types, depending on the capabilities of the | |
16 | hardware. For devices handling anonymous contacts (type A), the protocol | |
17 | describes how to send the raw data for all contacts to the receiver. For | |
18 | devices capable of tracking identifiable contacts (type B), the protocol | |
19 | describes how to send updates for individual contacts via event slots. | |
20 | ||
21 | ||
22 | Protocol Usage | |
23 | -------------- | |
24 | ||
25 | Contact details are sent sequentially as separate packets of ABS_MT | |
26 | events. Only the ABS_MT events are recognized as part of a contact | |
27 | packet. Since these events are ignored by current single-touch (ST) | |
28 | applications, the MT protocol can be implemented on top of the ST protocol | |
29 | in an existing driver. | |
30 | ||
31 | Drivers for type A devices separate contact packets by calling | |
32 | input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT | |
33 | event, which instructs the receiver to accept the data for the current | |
34 | contact and prepare to receive another. | |
35 | ||
36 | Drivers for type B devices separate contact packets by calling | |
37 | input_mt_slot(), with a slot as argument, at the beginning of each packet. | |
38 | This generates an ABS_MT_SLOT event, which instructs the receiver to | |
39 | prepare for updates of the given slot. | |
40 | ||
41 | All drivers mark the end of a multi-touch transfer by calling the usual | |
42 | input_sync() function. This instructs the receiver to act upon events | |
43 | accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set | |
44 | of events/packets. | |
45 | ||
46 | The main difference between the stateless type A protocol and the stateful | |
47 | type B slot protocol lies in the usage of identifiable contacts to reduce | |
48 | the amount of data sent to userspace. The slot protocol requires the use of | |
49 | the ABS_MT_TRACKING_ID, either provided by the hardware or computed from | |
50 | the raw data [5]. | |
51 | ||
52 | For type A devices, the kernel driver should generate an arbitrary | |
53 | enumeration of the full set of anonymous contacts currently on the | |
54 | surface. The order in which the packets appear in the event stream is not | |
55 | important. Event filtering and finger tracking is left to user space [3]. | |
56 | ||
57 | For type B devices, the kernel driver should associate a slot with each | |
58 | identified contact, and use that slot to propagate changes for the contact. | |
59 | Creation, replacement and destruction of contacts is achieved by modifying | |
60 | the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id | |
61 | is interpreted as a contact, and the value -1 denotes an unused slot. A | |
62 | tracking id not previously present is considered new, and a tracking id no | |
63 | longer present is considered removed. Since only changes are propagated, | |
64 | the full state of each initiated contact has to reside in the receiving | |
65 | end. Upon receiving an MT event, one simply updates the appropriate | |
66 | attribute of the current slot. | |
67 | ||
68 | ||
69 | Protocol Example A | |
70 | ------------------ | |
71 | ||
72 | Here is what a minimal event sequence for a two-contact touch would look | |
73 | like for a type A device: | |
74 | ||
75 | ABS_MT_POSITION_X x[0] | |
76 | ABS_MT_POSITION_Y y[0] | |
77 | SYN_MT_REPORT | |
78 | ABS_MT_POSITION_X x[1] | |
79 | ABS_MT_POSITION_Y y[1] | |
80 | SYN_MT_REPORT | |
81 | SYN_REPORT | |
eacaad01 | 82 | |
72c8a94a HR |
83 | The sequence after moving one of the contacts looks exactly the same; the |
84 | raw data for all present contacts are sent between every synchronization | |
85 | with SYN_REPORT. | |
eacaad01 | 86 | |
72c8a94a | 87 | Here is the sequence after lifting the first contact: |
eacaad01 | 88 | |
72c8a94a HR |
89 | ABS_MT_POSITION_X x[1] |
90 | ABS_MT_POSITION_Y y[1] | |
91 | SYN_MT_REPORT | |
92 | SYN_REPORT | |
93 | ||
94 | And here is the sequence after lifting the second contact: | |
95 | ||
96 | SYN_MT_REPORT | |
97 | SYN_REPORT | |
98 | ||
99 | If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the | |
100 | ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the | |
101 | last SYN_REPORT will be dropped by the input core, resulting in no | |
102 | zero-contact event reaching userland. | |
103 | ||
104 | ||
105 | Protocol Example B | |
106 | ------------------ | |
107 | ||
108 | Here is what a minimal event sequence for a two-contact touch would look | |
109 | like for a type B device: | |
110 | ||
111 | ABS_MT_SLOT 0 | |
112 | ABS_MT_TRACKING_ID 45 | |
113 | ABS_MT_POSITION_X x[0] | |
114 | ABS_MT_POSITION_Y y[0] | |
115 | ABS_MT_SLOT 1 | |
116 | ABS_MT_TRACKING_ID 46 | |
117 | ABS_MT_POSITION_X x[1] | |
118 | ABS_MT_POSITION_Y y[1] | |
119 | SYN_REPORT | |
120 | ||
121 | Here is the sequence after moving contact 45 in the x direction: | |
122 | ||
123 | ABS_MT_SLOT 0 | |
124 | ABS_MT_POSITION_X x[0] | |
125 | SYN_REPORT | |
126 | ||
127 | Here is the sequence after lifting the contact in slot 0: | |
128 | ||
129 | ABS_MT_TRACKING_ID -1 | |
130 | SYN_REPORT | |
131 | ||
132 | The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The | |
133 | message removes the association of slot 0 with contact 45, thereby | |
134 | destroying contact 45 and freeing slot 0 to be reused for another contact. | |
135 | ||
136 | Finally, here is the sequence after lifting the second contact: | |
137 | ||
138 | ABS_MT_SLOT 1 | |
139 | ABS_MT_TRACKING_ID -1 | |
140 | SYN_REPORT | |
141 | ||
142 | ||
143 | Event Usage | |
144 | ----------- | |
eacaad01 HR |
145 | |
146 | A set of ABS_MT events with the desired properties is defined. The events | |
147 | are divided into categories, to allow for partial implementation. The | |
f6bdc230 | 148 | minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which |
72c8a94a | 149 | allows for multiple contacts to be tracked. If the device supports it, the |
f6bdc230 | 150 | ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size |
72c8a94a | 151 | of the contact area and approaching contact, respectively. |
f6bdc230 HR |
152 | |
153 | The TOUCH and WIDTH parameters have a geometrical interpretation; imagine | |
154 | looking through a window at someone gently holding a finger against the | |
155 | glass. You will see two regions, one inner region consisting of the part | |
156 | of the finger actually touching the glass, and one outer region formed by | |
157 | the perimeter of the finger. The diameter of the inner region is the | |
158 | ABS_MT_TOUCH_MAJOR, the diameter of the outer region is | |
159 | ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder | |
160 | against the glass. The inner region will increase, and in general, the | |
161 | ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than | |
72c8a94a | 162 | unity, is related to the contact pressure. For pressure-based devices, |
f6bdc230 HR |
163 | ABS_MT_PRESSURE may be used to provide the pressure on the contact area |
164 | instead. | |
165 | ||
72c8a94a | 166 | In addition to the MAJOR parameters, the oval shape of the contact can be |
f6bdc230 HR |
167 | described by adding the MINOR parameters, such that MAJOR and MINOR are the |
168 | major and minor axis of an ellipse. Finally, the orientation of the oval | |
169 | shape can be describe with the ORIENTATION parameter. | |
170 | ||
171 | The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a | |
72c8a94a | 172 | contact or a pen or something else. Devices with more granular information |
f9fcfc3b HR |
173 | may specify general shapes as blobs, i.e., as a sequence of rectangular |
174 | shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices | |
175 | that currently support it, the ABS_MT_TRACKING_ID event may be used to | |
72c8a94a | 176 | report contact tracking from hardware [5]. |
f9fcfc3b | 177 | |
eacaad01 HR |
178 | |
179 | Event Semantics | |
180 | --------------- | |
181 | ||
eacaad01 HR |
182 | ABS_MT_TOUCH_MAJOR |
183 | ||
184 | The length of the major axis of the contact. The length should be given in | |
185 | surface units. If the surface has an X times Y resolution, the largest | |
f9fcfc3b | 186 | possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal [4]. |
eacaad01 HR |
187 | |
188 | ABS_MT_TOUCH_MINOR | |
189 | ||
190 | The length, in surface units, of the minor axis of the contact. If the | |
f9fcfc3b | 191 | contact is circular, this event can be omitted [4]. |
eacaad01 HR |
192 | |
193 | ABS_MT_WIDTH_MAJOR | |
194 | ||
195 | The length, in surface units, of the major axis of the approaching | |
196 | tool. This should be understood as the size of the tool itself. The | |
197 | orientation of the contact and the approaching tool are assumed to be the | |
f9fcfc3b | 198 | same [4]. |
eacaad01 HR |
199 | |
200 | ABS_MT_WIDTH_MINOR | |
201 | ||
202 | The length, in surface units, of the minor axis of the approaching | |
f9fcfc3b | 203 | tool. Omit if circular [4]. |
eacaad01 HR |
204 | |
205 | The above four values can be used to derive additional information about | |
206 | the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates | |
207 | the notion of pressure. The fingers of the hand and the palm all have | |
208 | different characteristic widths [1]. | |
209 | ||
f6bdc230 HR |
210 | ABS_MT_PRESSURE |
211 | ||
212 | The pressure, in arbitrary units, on the contact area. May be used instead | |
213 | of TOUCH and WIDTH for pressure-based devices or any device with a spatial | |
214 | signal intensity distribution. | |
215 | ||
eacaad01 HR |
216 | ABS_MT_ORIENTATION |
217 | ||
f9fcfc3b HR |
218 | The orientation of the ellipse. The value should describe a signed quarter |
219 | of a revolution clockwise around the touch center. The signed value range | |
220 | is arbitrary, but zero should be returned for a finger aligned along the Y | |
221 | axis of the surface, a negative value when finger is turned to the left, and | |
222 | a positive value when finger turned to the right. When completely aligned with | |
223 | the X axis, the range max should be returned. Orientation can be omitted | |
224 | if the touching object is circular, or if the information is not available | |
225 | in the kernel driver. Partial orientation support is possible if the device | |
226 | can distinguish between the two axis, but not (uniquely) any values in | |
227 | between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1] | |
228 | [4]. | |
eacaad01 HR |
229 | |
230 | ABS_MT_POSITION_X | |
231 | ||
232 | The surface X coordinate of the center of the touching ellipse. | |
233 | ||
234 | ABS_MT_POSITION_Y | |
235 | ||
236 | The surface Y coordinate of the center of the touching ellipse. | |
237 | ||
238 | ABS_MT_TOOL_TYPE | |
239 | ||
240 | The type of approaching tool. A lot of kernel drivers cannot distinguish | |
241 | between different tool types, such as a finger or a pen. In such cases, the | |
242 | event should be omitted. The protocol currently supports MT_TOOL_FINGER and | |
243 | MT_TOOL_PEN [2]. | |
244 | ||
245 | ABS_MT_BLOB_ID | |
246 | ||
247 | The BLOB_ID groups several packets together into one arbitrarily shaped | |
72c8a94a HR |
248 | contact. This is a low-level anonymous grouping for type A devices, and |
249 | should not be confused with the high-level trackingID [5]. Most type A | |
250 | devices do not have blob capability, so drivers can safely omit this event. | |
f9fcfc3b HR |
251 | |
252 | ABS_MT_TRACKING_ID | |
253 | ||
254 | The TRACKING_ID identifies an initiated contact throughout its life cycle | |
72c8a94a HR |
255 | [5]. This event is mandatory for type B devices. The value range of the |
256 | TRACKING_ID should be large enough to ensure unique identification of a | |
257 | contact maintained over an extended period of time. | |
f9fcfc3b HR |
258 | |
259 | ||
260 | Event Computation | |
261 | ----------------- | |
262 | ||
263 | The flora of different hardware unavoidably leads to some devices fitting | |
264 | better to the MT protocol than others. To simplify and unify the mapping, | |
265 | this section gives recipes for how to compute certain events. | |
266 | ||
267 | For devices reporting contacts as rectangular shapes, signed orientation | |
268 | cannot be obtained. Assuming X and Y are the lengths of the sides of the | |
269 | touching rectangle, here is a simple formula that retains the most | |
270 | information possible: | |
271 | ||
272 | ABS_MT_TOUCH_MAJOR := max(X, Y) | |
273 | ABS_MT_TOUCH_MINOR := min(X, Y) | |
274 | ABS_MT_ORIENTATION := bool(X > Y) | |
275 | ||
276 | The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that | |
277 | the device can distinguish between a finger along the Y axis (0) and a | |
278 | finger along the X axis (1). | |
eacaad01 HR |
279 | |
280 | ||
281 | Finger Tracking | |
282 | --------------- | |
283 | ||
f9fcfc3b | 284 | The process of finger tracking, i.e., to assign a unique trackingID to each |
72c8a94a HR |
285 | initiated contact on the surface, is a Euclidian Bipartite Matching |
286 | problem. At each event synchronization, the set of actual contacts is | |
287 | matched to the set of contacts from the previous synchronization. A full | |
288 | implementation can be found in [3]. | |
f9fcfc3b HR |
289 | |
290 | ||
f6bdc230 HR |
291 | Gestures |
292 | -------- | |
293 | ||
294 | In the specific application of creating gesture events, the TOUCH and WIDTH | |
295 | parameters can be used to, e.g., approximate finger pressure or distinguish | |
296 | between index finger and thumb. With the addition of the MINOR parameters, | |
297 | one can also distinguish between a sweeping finger and a pointing finger, | |
298 | and with ORIENTATION, one can detect twisting of fingers. | |
299 | ||
300 | ||
eacaad01 HR |
301 | Notes |
302 | ----- | |
303 | ||
304 | In order to stay compatible with existing applications, the data | |
305 | reported in a finger packet must not be recognized as single-touch | |
306 | events. In addition, all finger data must bypass input filtering, | |
307 | since subsequent events of the same type refer to different fingers. | |
308 | ||
309 | The first kernel driver to utilize the MT protocol is the bcm5974 driver, | |
310 | where examples can be found. | |
311 | ||
312 | [1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the | |
313 | difference between the contact position and the approaching tool position | |
314 | could be used to derive tilt. | |
315 | [2] The list can of course be extended. | |
13bad37b | 316 | [3] Multitouch X driver project: http://bitmath.org/code/multitouch/. |
f9fcfc3b HR |
317 | [4] See the section on event computation. |
318 | [5] See the section on finger tracking. |