This is effectively already in force through input_mt_init_slots, and uinput too ignores the actual minimum.
Since slots are a kernel-genenerated axis only, non-zero minimums make little sense and are likely to cause errors. Better to treat a non-zero minimum as kernel bug if it ever happens. Signed-off-by: Peter Hutterer <[email protected]> --- I admit that sentence looks a bit lost there, if you want to move this elsewhere to have more exposure I'm happy to do so once I figure out where. Documentation/input/multi-touch-protocol.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index 2c17961..de139b1 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -80,6 +80,8 @@ 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. +The minimum value of the ABS_MT_SLOT axis must be 0. + Protocol Example A ------------------ -- 1.8.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
