aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorCharlie Mooney <charliemooney@chromium.org>2015-03-20 12:40:17 -0400
committerDmitry Torokhov <dmitry.torokhov@gmail.com>2015-03-20 12:45:28 -0400
commita736775db683174269c65c7c5cc8e5ee534e7681 (patch)
tree7771241d9f3e0eb75125ea5f16c1877a8cd78995
parent09d042a2eb90ee2c86d80c48ad096ae3f5776cef (diff)
Input: add MT_TOOL_PALM
Currently there are only two "tools" that can be specified by a multi-touch driver: MT_TOOL_FINGER and MT_TOOL_PEN. In working with Elan (The touch vendor) and discussing their next-gen devices it seems that it will be useful to have more tools so that their devices can give the upper layers of the stack hints as to what is touching the sensor. In particular they have new experimental firmware that can better differentiate between palms vs fingertips and would like to plumb a patch so that we can use their hints in higher-level gesture soft- ware. The firmware on the device can reasonably do a better job of palm detection because it has access to all of the raw sensor readings as opposed to just the width/pressure/etc that are exposed by the driver. As such, the firmware can characterize what a palm looks like in much finer-grained detail and this change would allow such a device to share its findings with the kernel. Signed-off-by: Charlie Mooney <charliemooney@chromium.org> Acked-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
-rw-r--r--Documentation/input/multi-touch-protocol.txt9
-rw-r--r--include/uapi/linux/input.h3
2 files changed, 8 insertions, 4 deletions
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 7b4f59c09ee2..b85d000faeb4 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -312,9 +312,12 @@ ABS_MT_TOOL_TYPE
312 312
313The type of approaching tool. A lot of kernel drivers cannot distinguish 313The type of approaching tool. A lot of kernel drivers cannot distinguish
314between different tool types, such as a finger or a pen. In such cases, the 314between different tool types, such as a finger or a pen. In such cases, the
315event should be omitted. The protocol currently supports MT_TOOL_FINGER and 315event should be omitted. The protocol currently supports MT_TOOL_FINGER,
316MT_TOOL_PEN [2]. For type B devices, this event is handled by input core; 316MT_TOOL_PEN, and MT_TOOL_PALM [2]. For type B devices, this event is handled
317drivers should instead use input_mt_report_slot_state(). 317by input core; drivers should instead use input_mt_report_slot_state().
318A contact's ABS_MT_TOOL_TYPE may change over time while still touching the
319device, because the firmware may not be able to determine which tool is being
320used when it first appears.
318 321
319ABS_MT_BLOB_ID 322ABS_MT_BLOB_ID
320 323
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index a1d7e931ab72..2320b0ce7579 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -972,7 +972,8 @@ struct input_keymap_entry {
972 */ 972 */
973#define MT_TOOL_FINGER 0 973#define MT_TOOL_FINGER 0
974#define MT_TOOL_PEN 1 974#define MT_TOOL_PEN 1
975#define MT_TOOL_MAX 1 975#define MT_TOOL_PALM 2
976#define MT_TOOL_MAX 2
976 977
977/* 978/*
978 * Values describing the status of a force-feedback effect 979 * Values describing the status of a force-feedback effect