Root/
1 | Multi-touch (MT) Protocol |
2 | ------------------------- |
3 | Copyright (C) 2009-2010 Henrik Rydberg <rydberg@euromail.se> |
4 | |
5 | |
6 | Introduction |
7 | ------------ |
8 | |
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 |
82 | |
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. |
86 | |
87 | Here is the sequence after lifting the first contact: |
88 | |
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 | ----------- |
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 |
148 | minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which |
149 | allows for multiple contacts to be tracked. If the device supports it, the |
150 | ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size |
151 | of the contact area and approaching contact, respectively. |
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 |
162 | unity, is related to the contact pressure. For pressure-based devices, |
163 | ABS_MT_PRESSURE may be used to provide the pressure on the contact area |
164 | instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to |
165 | indicate the distance between the contact and the surface. |
166 | |
167 | In addition to the MAJOR parameters, the oval shape of the contact can be |
168 | described by adding the MINOR parameters, such that MAJOR and MINOR are the |
169 | major and minor axis of an ellipse. Finally, the orientation of the oval |
170 | shape can be describe with the ORIENTATION parameter. |
171 | |
172 | For type A devices, further specification of the touch shape is possible |
173 | via ABS_MT_BLOB_ID. |
174 | |
175 | The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a |
176 | finger or a pen or something else. Finally, the ABS_MT_TRACKING_ID event |
177 | may be used to track identified contacts over time [5]. |
178 | |
179 | In the type B protocol, ABS_MT_TOOL_TYPE and ABS_MT_TRACKING_ID are |
180 | implicitly handled by input core; drivers should instead call |
181 | input_mt_report_slot_state(). |
182 | |
183 | |
184 | Event Semantics |
185 | --------------- |
186 | |
187 | ABS_MT_TOUCH_MAJOR |
188 | |
189 | The length of the major axis of the contact. The length should be given in |
190 | surface units. If the surface has an X times Y resolution, the largest |
191 | possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal [4]. |
192 | |
193 | ABS_MT_TOUCH_MINOR |
194 | |
195 | The length, in surface units, of the minor axis of the contact. If the |
196 | contact is circular, this event can be omitted [4]. |
197 | |
198 | ABS_MT_WIDTH_MAJOR |
199 | |
200 | The length, in surface units, of the major axis of the approaching |
201 | tool. This should be understood as the size of the tool itself. The |
202 | orientation of the contact and the approaching tool are assumed to be the |
203 | same [4]. |
204 | |
205 | ABS_MT_WIDTH_MINOR |
206 | |
207 | The length, in surface units, of the minor axis of the approaching |
208 | tool. Omit if circular [4]. |
209 | |
210 | The above four values can be used to derive additional information about |
211 | the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates |
212 | the notion of pressure. The fingers of the hand and the palm all have |
213 | different characteristic widths [1]. |
214 | |
215 | ABS_MT_PRESSURE |
216 | |
217 | The pressure, in arbitrary units, on the contact area. May be used instead |
218 | of TOUCH and WIDTH for pressure-based devices or any device with a spatial |
219 | signal intensity distribution. |
220 | |
221 | ABS_MT_DISTANCE |
222 | |
223 | The distance, in surface units, between the contact and the surface. Zero |
224 | distance means the contact is touching the surface. A positive number means |
225 | the contact is hovering above the surface. |
226 | |
227 | ABS_MT_ORIENTATION |
228 | |
229 | The orientation of the ellipse. The value should describe a signed quarter |
230 | of a revolution clockwise around the touch center. The signed value range |
231 | is arbitrary, but zero should be returned for a finger aligned along the Y |
232 | axis of the surface, a negative value when finger is turned to the left, and |
233 | a positive value when finger turned to the right. When completely aligned with |
234 | the X axis, the range max should be returned. Orientation can be omitted |
235 | if the touching object is circular, or if the information is not available |
236 | in the kernel driver. Partial orientation support is possible if the device |
237 | can distinguish between the two axis, but not (uniquely) any values in |
238 | between. In such cases, the range of ABS_MT_ORIENTATION should be [0, 1] |
239 | [4]. |
240 | |
241 | ABS_MT_POSITION_X |
242 | |
243 | The surface X coordinate of the center of the touching ellipse. |
244 | |
245 | ABS_MT_POSITION_Y |
246 | |
247 | The surface Y coordinate of the center of the touching ellipse. |
248 | |
249 | ABS_MT_TOOL_TYPE |
250 | |
251 | The type of approaching tool. A lot of kernel drivers cannot distinguish |
252 | between different tool types, such as a finger or a pen. In such cases, the |
253 | event should be omitted. The protocol currently supports MT_TOOL_FINGER and |
254 | MT_TOOL_PEN [2]. For type B devices, this event is handled by input core; |
255 | drivers should instead use input_mt_report_slot_state(). |
256 | |
257 | ABS_MT_BLOB_ID |
258 | |
259 | The BLOB_ID groups several packets together into one arbitrarily shaped |
260 | contact. The sequence of points forms a polygon which defines the shape of |
261 | the contact. This is a low-level anonymous grouping for type A devices, and |
262 | should not be confused with the high-level trackingID [5]. Most type A |
263 | devices do not have blob capability, so drivers can safely omit this event. |
264 | |
265 | ABS_MT_TRACKING_ID |
266 | |
267 | The TRACKING_ID identifies an initiated contact throughout its life cycle |
268 | [5]. The value range of the TRACKING_ID should be large enough to ensure |
269 | unique identification of a contact maintained over an extended period of |
270 | time. For type B devices, this event is handled by input core; drivers |
271 | should instead use input_mt_report_slot_state(). |
272 | |
273 | |
274 | Event Computation |
275 | ----------------- |
276 | |
277 | The flora of different hardware unavoidably leads to some devices fitting |
278 | better to the MT protocol than others. To simplify and unify the mapping, |
279 | this section gives recipes for how to compute certain events. |
280 | |
281 | For devices reporting contacts as rectangular shapes, signed orientation |
282 | cannot be obtained. Assuming X and Y are the lengths of the sides of the |
283 | touching rectangle, here is a simple formula that retains the most |
284 | information possible: |
285 | |
286 | ABS_MT_TOUCH_MAJOR := max(X, Y) |
287 | ABS_MT_TOUCH_MINOR := min(X, Y) |
288 | ABS_MT_ORIENTATION := bool(X > Y) |
289 | |
290 | The range of ABS_MT_ORIENTATION should be set to [0, 1], to indicate that |
291 | the device can distinguish between a finger along the Y axis (0) and a |
292 | finger along the X axis (1). |
293 | |
294 | |
295 | Finger Tracking |
296 | --------------- |
297 | |
298 | The process of finger tracking, i.e., to assign a unique trackingID to each |
299 | initiated contact on the surface, is a Euclidian Bipartite Matching |
300 | problem. At each event synchronization, the set of actual contacts is |
301 | matched to the set of contacts from the previous synchronization. A full |
302 | implementation can be found in [3]. |
303 | |
304 | |
305 | Gestures |
306 | -------- |
307 | |
308 | In the specific application of creating gesture events, the TOUCH and WIDTH |
309 | parameters can be used to, e.g., approximate finger pressure or distinguish |
310 | between index finger and thumb. With the addition of the MINOR parameters, |
311 | one can also distinguish between a sweeping finger and a pointing finger, |
312 | and with ORIENTATION, one can detect twisting of fingers. |
313 | |
314 | |
315 | Notes |
316 | ----- |
317 | |
318 | In order to stay compatible with existing applications, the data reported |
319 | in a finger packet must not be recognized as single-touch events. |
320 | |
321 | For type A devices, all finger data bypasses input filtering, since |
322 | subsequent events of the same type refer to different fingers. |
323 | |
324 | For example usage of the type A protocol, see the bcm5974 driver. For |
325 | example usage of the type B protocol, see the hid-egalax driver. |
326 | |
327 | [1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the |
328 | difference between the contact position and the approaching tool position |
329 | could be used to derive tilt. |
330 | [2] The list can of course be extended. |
331 | [3] The mtdev project: http://bitmath.org/code/mtdev/. |
332 | [4] See the section on event computation. |
333 | [5] See the section on finger tracking. |
334 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9