[PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[Peter Hutterer]

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@who-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

Re: [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[Randy Dunlap]

Hi,

On 10/29/25 6:17 PM, Peter Hutterer wrote:
> 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@who-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

Looks reasonable to me. But the list above and the one below
are not rendered as lists in html. It would be nice to convert
them to lists.

Tested-by: Randy Dunlap <rdunlap@infradead.org>

>  
> +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
>  ==========

-- 
~Randy

[PATCH v2] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[Peter Hutterer]

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@who-t.net>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
---
Changes to v1: extra empty lines to render the lists as lists
Link to v1: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#u

Side-note: typo in my v1 comment, the HID usage ID that tells us whether
it's a clickpad or pressurepad is 0x59, not 0x55.

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

diff --git ./Documentation/input/event-codes.rst ../Documentation/input/event-codes.rst
index 1ead9bb8d9c6..bb4c68871e94 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -403,16 +403,27 @@ 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

Re: [PATCH v2] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[Dmitry Torokhov]

Hi Peter,

On Fri, Oct 31, 2025 at 02:12:45PM +1000, Peter Hutterer wrote:
> 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

Should we maybe rename it to INPUT_PROP_PRESSURE_TOUCHPAD? We are within
a release of introducing it, so we should be able to rename it without
much fallout.

Thanks.

-- 
Dmitry

Re: [PATCH v2] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[Peter Hutterer]

On Tue, Nov 04, 2025 at 09:09:09PM -0800, Dmitry Torokhov wrote:
> Hi Peter,
> 
> On Fri, Oct 31, 2025 at 02:12:45PM +1000, Peter Hutterer wrote:
> > 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
> 
> Should we maybe rename it to INPUT_PROP_PRESSURE_TOUCHPAD? We are within
> a release of introducing it, so we should be able to rename it without
> much fallout.

I'd be happy with a rename too. Want me to send a patch for that or do
you want to rename it locally during applying?

Cheers,
  Peter

Re: [PATCH v2] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads

[Dmitry Torokhov]

On Wed, Nov 05, 2025 at 04:03:33PM +1000, Peter Hutterer wrote:
> On Tue, Nov 04, 2025 at 09:09:09PM -0800, Dmitry Torokhov wrote:
> > Hi Peter,
> > 
> > On Fri, Oct 31, 2025 at 02:12:45PM +1000, Peter Hutterer wrote:
> > > 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
> > 
> > Should we maybe rename it to INPUT_PROP_PRESSURE_TOUCHPAD? We are within
> > a release of introducing it, so we should be able to rename it without
> > much fallout.
> 
> I'd be happy with a rename too. Want me to send a patch for that or do
> you want to rename it locally during applying?

Please send the updated patch for input.h along with updated
documentation.

Thanks.

-- 
Dmitry

[PATCH v3] Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPAD

[Peter Hutterer]

And expand it to encompass all pressure pads.

Definition: "pressure pad" as used here as includes 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 and rename
that definition to include all pressure pad touchpads 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_PRESSUREPAD
- pressurepad with configurable haptics:
  INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD + FF_HAPTIC

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
ftr, I picked PRESSUREPAD over Dmitry's PRESSURE_TOUCHPAD suggestion
because it matches better with the existing BUTTONPAD.

Changes to v1: extra empty lines to render the lists as lists
Changes to v2: rename to PRESSUREPAD and rename it in the instances
  where it's used in the code

v1: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#u
v2: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#m9504de27b02d00a55d540fd9fec9aed3edd0133c

 Documentation/input/event-codes.rst    | 25 ++++++++++++++++++-------
 drivers/hid/hid-haptic.c               |  2 +-
 include/uapi/linux/input-event-codes.h |  2 +-
 3 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
index 1ead9bb8d9c6..4424cbff251f 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -400,19 +400,30 @@ can report through the rotational axes (absolute and/or relative rx, ry, rz).
 All other axes retain their meaning. A device must not mix
 regular directional axes and accelerometer axes on the same event node.
 
-INPUT_PROP_HAPTIC_TOUCHPAD
---------------------------
+INPUT_PROP_PRESSUREPAD
+----------------------
+
+The INPUT_PROP_PRESSUREPAD 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:
 
-The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
-- supports simple haptic auto and manual triggering
 - 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
 ==========
diff --git a/drivers/hid/hid-haptic.c b/drivers/hid/hid-haptic.c
index aa090684c1f2..fc8a9997f815 100644
--- a/drivers/hid/hid-haptic.c
+++ b/drivers/hid/hid-haptic.c
@@ -86,7 +86,7 @@ int hid_haptic_input_configured(struct hid_device *hdev,
 	if (hi->application == HID_DG_TOUCHPAD) {
 		if (haptic->auto_trigger_report &&
 		    haptic->manual_trigger_report) {
-			__set_bit(INPUT_PROP_HAPTIC_TOUCHPAD, hi->input->propbit);
+			__set_bit(INPUT_PROP_PRESSUREPAD, hi->input->propbit);
 			return 1;
 		}
 		return 0;
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 8ba48590bd2c..d21172c6a266 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -27,7 +27,7 @@
 #define INPUT_PROP_TOPBUTTONPAD		0x04	/* softbuttons at top of pad */
 #define INPUT_PROP_POINTING_STICK	0x05	/* is a pointing stick */
 #define INPUT_PROP_ACCELEROMETER	0x06	/* has accelerometer */
-#define INPUT_PROP_HAPTIC_TOUCHPAD	0x07	/* is a haptic touchpad */
+#define INPUT_PROP_PRESSUREPAD		0x07	/* pressure triggers clicks */
 
 #define INPUT_PROP_MAX			0x1f
 #define INPUT_PROP_CNT			(INPUT_PROP_MAX + 1)
-- 
2.51.1

Re: [PATCH v3] Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPAD

[Benjamin Tissoires]

On Nov 06 2025, Peter Hutterer wrote:
> And expand it to encompass all pressure pads.
> 
> Definition: "pressure pad" as used here as includes 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 and rename
> that definition to include all pressure pad touchpads 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_PRESSUREPAD
> - pressurepad with configurable haptics:
>   INPUT_PROP_BUTTONPAD + INPUT_PROP_PRESSUREPAD + FF_HAPTIC
> 
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Acked-by: Benjamin Tissoires <bentiss@kernel.org>

Unless Jiri has any problem with it, I guess this would be fine going
through your tree Dmitry.

Cheers,
Benjamin


> ---
> ftr, I picked PRESSUREPAD over Dmitry's PRESSURE_TOUCHPAD suggestion
> because it matches better with the existing BUTTONPAD.
> 
> Changes to v1: extra empty lines to render the lists as lists
> Changes to v2: rename to PRESSUREPAD and rename it in the instances
>   where it's used in the code
> 
> v1: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#u
> v2: https://lore.kernel.org/linux-input/20251030011735.GA969565@quokka/T/#m9504de27b02d00a55d540fd9fec9aed3edd0133c
> 
>  Documentation/input/event-codes.rst    | 25 ++++++++++++++++++-------
>  drivers/hid/hid-haptic.c               |  2 +-
>  include/uapi/linux/input-event-codes.h |  2 +-
>  3 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> index 1ead9bb8d9c6..4424cbff251f 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -400,19 +400,30 @@ can report through the rotational axes (absolute and/or relative rx, ry, rz).
>  All other axes retain their meaning. A device must not mix
>  regular directional axes and accelerometer axes on the same event node.
>  
> -INPUT_PROP_HAPTIC_TOUCHPAD
> ---------------------------
> +INPUT_PROP_PRESSUREPAD
> +----------------------
> +
> +The INPUT_PROP_PRESSUREPAD 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:
>  
> -The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
> -- supports simple haptic auto and manual triggering
>  - 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
>  ==========
> diff --git a/drivers/hid/hid-haptic.c b/drivers/hid/hid-haptic.c
> index aa090684c1f2..fc8a9997f815 100644
> --- a/drivers/hid/hid-haptic.c
> +++ b/drivers/hid/hid-haptic.c
> @@ -86,7 +86,7 @@ int hid_haptic_input_configured(struct hid_device *hdev,
>  	if (hi->application == HID_DG_TOUCHPAD) {
>  		if (haptic->auto_trigger_report &&
>  		    haptic->manual_trigger_report) {
> -			__set_bit(INPUT_PROP_HAPTIC_TOUCHPAD, hi->input->propbit);
> +			__set_bit(INPUT_PROP_PRESSUREPAD, hi->input->propbit);
>  			return 1;
>  		}
>  		return 0;
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 8ba48590bd2c..d21172c6a266 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -27,7 +27,7 @@
>  #define INPUT_PROP_TOPBUTTONPAD		0x04	/* softbuttons at top of pad */
>  #define INPUT_PROP_POINTING_STICK	0x05	/* is a pointing stick */
>  #define INPUT_PROP_ACCELEROMETER	0x06	/* has accelerometer */
> -#define INPUT_PROP_HAPTIC_TOUCHPAD	0x07	/* is a haptic touchpad */
> +#define INPUT_PROP_PRESSUREPAD		0x07	/* pressure triggers clicks */
>  
>  #define INPUT_PROP_MAX			0x1f
>  #define INPUT_PROP_CNT			(INPUT_PROP_MAX + 1)
> -- 
> 2.51.1
>