Message-ID: <01992fa4-c982-49e8-9152-e6a716552a3b@infradead.org>
Date: Wed, 29 Oct 2025 18:35:28 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Peter Hutterer <peter.hutterer@...-t.net>,
 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>
Subject: Re: [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD
 to all pressure pads

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@...-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@...radead.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

Powered by blists - more mailing lists