IPC feature to exchange data regardless of HID device mode

[nefarius]

For the longest time a common challenge with any HID driver that offloads work to HIDCLASS.SYS (and xinputhid.sys) is exchanging data with the device (driver) that is not defined in the report descriptor (e.g. custom feature requests, multiple collections and alike) and may cause compatibility issues.

A custom collection with multiple feature reports is not always possible; the XInput mode depends on a standard report descriptor that does not use Report IDs and therefore can not be modified without breaking compatibility.

We currently have a mixture of "reading from JSON" for data input and "writing to status properties" to fetch status, which works but is clunky, timing sensitive and gets verbose to extend and maintain fast.

I've started implementing a shared memory region in the driver that is accessible from any other user-mode application and acts as an IPC mechanism for pre-defined messages that get exchanged between app (client) and the driver in a HTTP-like request-response fashion. With this method, it does not matter which HID device mode is active; the data exchange bypasses the HID stack and happens via shared memory and synchronization objects (events, mutexes) and allows for write operations from non-elevated processes.

IPC use-cases

A collection of command ideas to use this mechanism with:

• On-demand Bluetooth pairing to any custom address (similar to the legacy "SIXAXIS Pair Tool") at any point during runtime
• Toggle volatile runtime settings (like alternate rumble switching)
• Allow any non-HID app to read the raw unmodified HID input report
  • Due to the protection level a user-mode driver runs under it currently is sadly not possible to use this feature on non-elevated processes, maybe I find a better way later 🤞
• Allow any non-HID app to update LEDs and send rumble commands
  • Allows for overriding the XInput player ID with whatever value matches best
• Allow any non-HID app to submit custom USB control requests (great for motion calibration R&D)
• Allow for any app to send pairing requests to arbitrary MAC addresses (to offer the same feature as the old SixaxisPairTool)