This RFC series sits on top of Jingyuan's "[PATCH v7 00/11] Add spi-hid
transport driver" [1]. It adds support for digitizers that speak the
pre-release revision of the HID over SPI protocol, the one Microsoft's
original 2022 spi-hid driver targeted. The motivating device is the
Microsoft Surface Pro X (Qualcomm sc8180x), whose touch/pen digitizer
(045E:0996) ships this way.
With v7 as posted, the Pro X digitizer binds (via the g6 compatible), but
every input report is rejected with "Unknown input report version (v 0x2)".
The differences go beyond the version nibble:
- input header: report type in the high nibble of byte 0, a fragment id,
and a 12-bit length across bytes 1-2
- input body: a 3-byte body header (length, content id), no report type
- output: a 6-byte header (opcode, register address, version + 12-bit
length) followed by a 4-byte body header (content type, length, id)
- requests are addressed to per-function registers: device descriptor at
a fixed register, report descriptor at wReportDescRegister,
features/output reports at wOutputRegister
- a 28-byte device descriptor carrying those registers, bcdVersion 0x0100
- SET_FEATURE and output reports are not acknowledged
Patch 2 keeps all of this behind a per-device "protocol" field in
struct spi_hid_conf, in small helpers, so the v3 paths (g6, ACPI) are
unchanged. Patch 3 adds the Pro X match data. Patch 1 adds its compatible.
Tested on two Surface Pro X SQ1 (LTE) units on top of v7 (plus an
out-of-tree sc8180x DT): the device and report descriptors are accepted,
the HID device is created, iptsd's GET_FEATURE/SET_FEATURE succeed, and
multitouch works (5 simultaneous contacts, no driver errors).
Questions, which are why this is an RFC:
- Would you take support for the pre-release protocol revision at all,
given it's in shipping hardware? If so, is a per-device protocol field
in spi_hid_conf the right shape, or would you prefer something else?
- The compatible is named after the product
("microsoft,surface-pro-x-touch-digitizer"), since Microsoft publishes
no part number or generation for this digitizer. Is that acceptable?
Known gaps / observations:
- Fragmented input reports are not supported in the v2 path (fragment id
ignored); I have not seen this device send fragments.
- COMMAND (e.g. SET_POWER), output reports and suspend/resume are not
exercised by my testing yet.
- Once, on the first boot after installing a new kernel, the boot-time
probe saw no interrupt at all (IRQ count stayed 0); unbind/bind fixed it
and later boots were fine. That looks like a reset-response edge lost
at probe. v7 has no timeout/retry for that case; I'm not sure yet
whether it's specific to this device.
- Around a rebind, one "Unknown input report version" from the power-up
window can appear, because the version check runs before the
reset-pending check. Harmless, but noisy.
The matching sc8180x DT change will go via the Surface Pro X DT work.
[1] https://lore.kernel.org/r/20261024-send-upstream-v7-0-abad13174b43@chromium.org (local)
Tawheed Makhdoomi (3):
dt-bindings: input: hid-over-spi: add the Surface Pro X touch
digitizer
HID: spi-hid: support the pre-release HID over SPI protocol revision
HID: spi-hid-of: add the Surface Pro X touch digitizer
.../bindings/input/hid-over-spi.yaml | 1 +
drivers/hid/spi-hid/spi-hid-core.c | 327 +++++++++++++++---
drivers/hid/spi-hid/spi-hid-core.h | 4 +
drivers/hid/spi-hid/spi-hid-of.c | 26 ++
drivers/hid/spi-hid/spi-hid.h | 27 +-
5 files changed, 344 insertions(+), 41 deletions(-)
base-commit: 04fd628c5c27c93b623b5b6b88fd52d4444d5a7b
--
2.43.0