You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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)
The text was updated successfully, but these errors were encountered:
For the longest time a common challenge with any HID driver that offloads work to
HIDCLASS.SYS
(andxinputhid.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:
The text was updated successfully, but these errors were encountered: