linux-kernel - [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251030011735.GA969565@quokka>
Date: Thu, 30 Oct 2025 11:17:35 +1000
From: Peter Hutterer <peter.hutterer@...-t.net>
To: Jonathan Denose <jdenose@...gle.com>, Jiri Kosina <jikos@...nel.org>,
	Benjamin Tissoires <bentiss@...nel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jonathan Corbet <corbet@....net>,
	Henrik Rydberg <rydberg@...math.org>
Cc: linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, Angela Czubak <aczubak@...gle.com>,
	Sean O'Brien <seobrien@...gle.com>,
	Jonathan Denose <jdenose@...gle.com>
Subject: [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to
 all pressure pads

Definition: "pressure pad" used here as all touchpads that use physical
pressure to convert to click without physical hinges. Also called haptic
touchpads in general parlance, Synaptics calls them ForcePads.

Most (all?) pressure pads are currently advertised as
INPUT_PROP_BUTTONPAD. The suggestion to identify them as pressure pads
by defining the resolution on ABS_MT_PRESSURE has been in the docs since
commit 20ccc8dd38a3 ("Documentation: input: define
ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams") but few devices
provide this information.

In userspace it's thus impossible to determine whether a device is a
true pressure pad (pressure equals pressure) or a normal clickpad with
(pressure equals finger size).

Commit 7075ae4ac9db ("Input: add INPUT_PROP_HAPTIC_TOUCHPAD") introduces
INPUT_PROP_HAPTIC_TOUCHPAD but restricted it to those touchpads that
have support for userspace-controlled effects. Let's expand that
definition to include all haptic touchpads (pressure pads) since those
that do support FF effects can be identified by the presence of the
FF_HAPTIC bit.

This means:
- clickpad: INPUT_PROP_BUTTONPAD
- pressurepad: INPUT_PROP_BUTTONPAD + INPUT_PROP_HAPTIC_TOUCHPAD
- pressurepad with haptics:
  INPUT_PROP_BUTTONPAD + INPUT_PROP_HAPTIC_TOUCHPAD + FF_HAPTIC

Signed-off-by: Peter Hutterer <peter.hutterer@...-t.net>
---

Original patch series: https://lore.kernel.org/linux-input/20251024033045.GA48918@quokka/T/#m20ec992705f449f9d9758e0080622cfae1c90660
See my comment there: https://lore.kernel.org/linux-input/20251024033045.GA48918@quokka/T/#u

My motivation is that we need something to identify pressurepads that
do not expose actual haptic feedback configuration. Right now we're
adding quirks for each device in libinput but that doesn't scale and
HID defines Usage Page 0x0D Usage 0x55 [1] to tell us whether the form
factor is a pressurepad, we're just not using it (yet).

I don't think adding a separate INPUT_PROP_PRESSUREPAD is the right
thing to do - HAPTIC_TOUCHPAD is good enough since presence of the
FF_HAPTICS bit indicates that it is controllable.

[1] https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-windows-precision-touchpad-collection#device-capabilities-feature-report

 Documentation/input/event-codes.rst | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git ./Documentation/input/event-codes.rst ../Documentation/input/event-codes.rst
index 1ead9bb8d9c6..304d11297d3f 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -403,16 +403,25 @@ regular directional axes and accelerometer axes on the same event node.
 INPUT_PROP_HAPTIC_TOUCHPAD
 --------------------------

-The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
-- supports simple haptic auto and manual triggering
+The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that the device provides
+simulated haptic feedback (e.g. a vibrator motor situated below the surface)
+instead of physical haptic feedback (e.g. a hinge). This property is only set
+if the device:
 - can differentiate between at least 5 fingers
 - uses correct resolution for the X/Y (units and value)
-- reports correct force per touch, and correct units for them (newtons or grams)
 - follows the MT protocol type B

+If the simulated haptic feedback is controllable by userspace the device must:
+- support simple haptic auto and manual triggering, and
+- report correct force per touch, and correct units for them (newtons or grams), and
+- provide the EV_FF FF_HAPTIC force feedback effect.
+
 Summing up, such devices follow the MS spec for input devices in
-Win8 and Win8.1, and in addition support the Simple haptic controller HID table,
-and report correct units for the pressure.
+Win8 and Win8.1, and in addition may support the Simple haptic controller HID
+table, and report correct units for the pressure.
+
+Where applicable, this property is set in addition to INPUT_PROP_BUTTONPAD, it
+does not replace that property.

 Guidelines
 ==========
-- 
2.51.0