linux-kernel - Re: [PATCH v3 03/11] Input: add 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-prev] [day] [month] [year] [list]

Message-ID: <20251024033045.GA48918@quokka>
Date: Fri, 24 Oct 2025 13:30:45 +1000
From: Peter Hutterer <peter.hutterer@...-t.net>
To: Jonathan Denose <jdenose@...gle.com>
Cc: 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>, 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 v3 03/11] Input: add INPUT_PROP_HAPTIC_TOUCHPAD

On Mon, Aug 18, 2025 at 11:08:44PM +0000, Jonathan Denose wrote:
> From: Angela Czubak <aczubak@...gle.com>
> 
> INPUT_PROP_HAPTIC_TOUCHPAD property is to be set for a device with simple
> haptic capabilities.
> 
> Signed-off-by: Angela Czubak <aczubak@...gle.com>
> Co-developed-by: Jonathan Denose <jdenose@...gle.com>
> Signed-off-by: Jonathan Denose <jdenose@...gle.com>
> ---
>  Documentation/input/event-codes.rst    | 14 ++++++++++++++
>  include/uapi/linux/input-event-codes.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> index b4557462edd7b3fef9e9cd6c2c3cb2d05bb531ab..1ead9bb8d9c6451a81426665baab643f9e50216a 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -400,6 +400,20 @@ 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
> +--------------------------
> +
> +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
> +
> +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.

I'm a bit late to the party here but I just had to deal with a related
bug and I'm wondering if you'd be open to loosening the definition of
INPUT_PROP_HAPTIC_TOUCHPAD to include touchpads that are *physically*
haptic touchpads but do not support userspace control of the
haptics (lack of driver support, usually).

We currently lack support for those "pressurepads" - in theory they
should report pressure resolution but the number of quirks we ship in
libinput indicates none or few of them do. Those devices *should*
report HID 0x0D usage 0x55 and identify them as pressurepads [1] because
otherwise Windows probably wouldn't work (unfortunately I don't have
access to any of those devices to verify).

By using this prop for all pressurepads including those not exposing
actual haptic effects the definition would become:

INPUT_PROP_HAPTIC_TOUCHPAD
--------------------------

The INPUT_PROP_HAPTIC_TOUCHPAD property indicates that device:
- can differentiate between at least 5 fingers
- uses correct resolution for the X/Y (units and value)
- follows the MT protocol type B
- may support simple haptic auto and manual triggering and if so:
  - reports correct force per touch, and correct units for them (newtons or grams)

And then we can hook up the 0x55 usage to set that property and leave it
up to the client to check if the FF_ bits are in place to verify it's a
haptic-haptic touchpad?

This would save us from needing a separate INPUT_PROP_PRESSUREPAD.

Cheers,
  Peter

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


> +
>  Guidelines
>  ==========
>  
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 3b2524e4b667d1e7cc02ff5cb674e7c2ac069a66..efe8c36d4ee9a938ffb1b0dd0ddd0ec6a3fcb8fe 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -27,6 +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_MAX			0x1f
>  #define INPUT_PROP_CNT			(INPUT_PROP_MAX + 1)
> 
> -- 
> 2.51.0.rc1.193.gad69d77794-goog
> 
>