diff options
author | Daniel Kurtz <djkurtz@chromium.org> | 2011-08-23 23:02:36 -0700 |
---|---|---|
committer | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2011-08-23 23:08:20 -0700 |
commit | a93bd154d8571f1be84b04d7451ec72a490636d8 (patch) | |
tree | 8bee3368ff8af1639ea4104bef9ee07f2be07767 /Documentation/input/multi-touch-protocol.txt | |
parent | a6ca40c11eb5d98e53176adf527e430f7037a8c9 (diff) |
Input: mt - document devices reporting more touches than slots
Some devices are capable of identifying and/or tracking more contacts than
they can report to the driver. Document how a driver should handle this,
and what userspace should expect.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Chase Douglas <chase.douglas@canonical.com>
Acked-by: Henrik Rydberg <rydberg@euromail.se>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Diffstat (limited to 'Documentation/input/multi-touch-protocol.txt')
-rw-r--r-- | Documentation/input/multi-touch-protocol.txt | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index 71536e78406..543101c5bf2 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -65,6 +65,20 @@ the full state of each initiated contact has to reside in the receiving end. Upon receiving an MT event, one simply updates the appropriate attribute of the current slot. +Some devices identify and/or track more contacts than they can report to the +driver. A driver for such a device should associate one type B slot with each +contact that is reported by the hardware. Whenever the identity of the +contact associated with a slot changes, the driver should invalidate that +slot by changing its ABS_MT_TRACKING_ID. If the hardware signals that it is +tracking more contacts than it is currently reporting, the driver should use +a BTN_TOOL_*TAP event to inform userspace of the total number of contacts +being tracked by the hardware at that moment. The driver should do this by +explicitly sending the corresponding BTN_TOOL_*TAP event and setting +use_count to false when calling input_mt_report_pointer_emulation(). +The driver should only advertise as many slots as the hardware can report. +Userspace can detect that a driver can report more total contacts than slots +by noting that the largest supported BTN_TOOL_*TAP event is larger than the +total number of type B slots reported in the absinfo for the ABS_MT_SLOT axis. Protocol Example A ------------------ |