aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/input
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/input')
-rw-r--r--Documentation/input/multi-touch-protocol.txt44
1 files changed, 26 insertions, 18 deletions
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 07215fa0c588..71536e78406f 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -1,6 +1,6 @@
1Multi-touch (MT) Protocol 1Multi-touch (MT) Protocol
2------------------------- 2-------------------------
3 Copyright (C) 2009 Henrik Rydberg <rydberg@euromail.se> 3 Copyright (C) 2009-2010 Henrik Rydberg <rydberg@euromail.se>
4 4
5 5
6Introduction 6Introduction
@@ -169,12 +169,16 @@ described by adding the MINOR parameters, such that MAJOR and MINOR are the
169major and minor axis of an ellipse. Finally, the orientation of the oval 169major and minor axis of an ellipse. Finally, the orientation of the oval
170shape can be describe with the ORIENTATION parameter. 170shape can be describe with the ORIENTATION parameter.
171 171
172For type A devices, further specification of the touch shape is possible
173via ABS_MT_BLOB_ID.
174
172The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a 175The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
173contact or a pen or something else. Devices with more granular information 176finger or a pen or something else. Finally, the ABS_MT_TRACKING_ID event
174may specify general shapes as blobs, i.e., as a sequence of rectangular 177may be used to track identified contacts over time [5].
175shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices 178
176that currently support it, the ABS_MT_TRACKING_ID event may be used to 179In the type B protocol, ABS_MT_TOOL_TYPE and ABS_MT_TRACKING_ID are
177report contact tracking from hardware [5]. 180implicitly handled by input core; drivers should instead call
181input_mt_report_slot_state().
178 182
179 183
180Event Semantics 184Event Semantics
@@ -247,21 +251,24 @@ ABS_MT_TOOL_TYPE
247The type of approaching tool. A lot of kernel drivers cannot distinguish 251The type of approaching tool. A lot of kernel drivers cannot distinguish
248between different tool types, such as a finger or a pen. In such cases, the 252between different tool types, such as a finger or a pen. In such cases, the
249event should be omitted. The protocol currently supports MT_TOOL_FINGER and 253event should be omitted. The protocol currently supports MT_TOOL_FINGER and
250MT_TOOL_PEN [2]. 254MT_TOOL_PEN [2]. For type B devices, this event is handled by input core;
255drivers should instead use input_mt_report_slot_state().
251 256
252ABS_MT_BLOB_ID 257ABS_MT_BLOB_ID
253 258
254The BLOB_ID groups several packets together into one arbitrarily shaped 259The BLOB_ID groups several packets together into one arbitrarily shaped
255contact. This is a low-level anonymous grouping for type A devices, and 260contact. The sequence of points forms a polygon which defines the shape of
261the contact. This is a low-level anonymous grouping for type A devices, and
256should not be confused with the high-level trackingID [5]. Most type A 262should not be confused with the high-level trackingID [5]. Most type A
257devices do not have blob capability, so drivers can safely omit this event. 263devices do not have blob capability, so drivers can safely omit this event.
258 264
259ABS_MT_TRACKING_ID 265ABS_MT_TRACKING_ID
260 266
261The TRACKING_ID identifies an initiated contact throughout its life cycle 267The TRACKING_ID identifies an initiated contact throughout its life cycle
262[5]. This event is mandatory for type B devices. The value range of the 268[5]. The value range of the TRACKING_ID should be large enough to ensure
263TRACKING_ID should be large enough to ensure unique identification of a 269unique identification of a contact maintained over an extended period of
264contact maintained over an extended period of time. 270time. For type B devices, this event is handled by input core; drivers
271should instead use input_mt_report_slot_state().
265 272
266 273
267Event Computation 274Event Computation
@@ -308,18 +315,19 @@ and with ORIENTATION, one can detect twisting of fingers.
308Notes 315Notes
309----- 316-----
310 317
311In order to stay compatible with existing applications, the data 318In order to stay compatible with existing applications, the data reported
312reported in a finger packet must not be recognized as single-touch 319in a finger packet must not be recognized as single-touch events.
313events. In addition, all finger data must bypass input filtering, 320
314since subsequent events of the same type refer to different fingers. 321For type A devices, all finger data bypasses input filtering, since
322subsequent events of the same type refer to different fingers.
315 323
316The first kernel driver to utilize the MT protocol is the bcm5974 driver, 324For example usage of the type A protocol, see the bcm5974 driver. For
317where examples can be found. 325example usage of the type B protocol, see the hid-egalax driver.
318 326
319[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the 327[1] With the extension ABS_MT_APPROACH_X and ABS_MT_APPROACH_Y, the
320difference between the contact position and the approaching tool position 328difference between the contact position and the approaching tool position
321could be used to derive tilt. 329could be used to derive tilt.
322[2] The list can of course be extended. 330[2] The list can of course be extended.
323[3] Multitouch X driver project: http://bitmath.org/code/multitouch/. 331[3] The mtdev project: http://bitmath.org/code/mtdev/.
324[4] See the section on event computation. 332[4] See the section on event computation.
325[5] See the section on finger tracking. 333[5] See the section on finger tracking.