linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Peter Hutterer <peter.hutterer@who-t.net>,
	Jonathan Denose <jdenose@google.com>,
	Jiri Kosina <jikos@kernel.org>,
	Benjamin Tissoires <bentiss@kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Henrik Rydberg <rydberg@bitmath.org>
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, Angela Czubak <aczubak@google.com>,
	Sean O'Brien <seobrien@google.com>
Subject: Re: [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads
Date: Wed, 29 Oct 2025 18:35:28 -0700	[thread overview]
Message-ID: <01992fa4-c982-49e8-9152-e6a716552a3b@infradead.org> (raw)
In-Reply-To: <20251030011735.GA969565@quokka>

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

  reply	other threads:[~2025-10-30  1:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-30  1:17 [PATCH] Documentation: input: expand INPUT_PROP_HAPTIC_TOUCHPAD to all pressure pads Peter Hutterer
2025-10-30  1:35 ` Randy Dunlap [this message]
2025-10-31  4:12 ` [PATCH v2] " Peter Hutterer
2025-11-05  5:09   ` Dmitry Torokhov
2025-11-05  6:03     ` Peter Hutterer
2025-11-05 21:50       ` Dmitry Torokhov
2025-11-06 11:45 ` [PATCH v3] Input: rename INPUT_PROP_HAPTIC_TOUCHPAD to INPUT_PROP_PRESSUREPAD Peter Hutterer
2025-11-06 14:32   ` Benjamin Tissoires

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01992fa4-c982-49e8-9152-e6a716552a3b@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=aczubak@google.com \
    --cc=bentiss@kernel.org \
    --cc=corbet@lwn.net \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jdenose@google.com \
    --cc=jikos@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.hutterer@who-t.net \
    --cc=rydberg@bitmath.org \
    --cc=seobrien@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).