Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPC feature to exchange data regardless of HID device mode #379

Open
2 of 5 tasks
nefarius opened this issue Aug 14, 2024 · 0 comments · Fixed by #380
Open
2 of 5 tasks

IPC feature to exchange data regardless of HID device mode #379

nefarius opened this issue Aug 14, 2024 · 0 comments · Fixed by #380
Assignees
Labels
Core Core/Common Driver Topic enhancement New feature or request
Milestone

Comments

@nefarius
Copy link
Owner

nefarius commented Aug 14, 2024

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)
@nefarius nefarius added enhancement New feature or request Core Core/Common Driver Topic labels Aug 14, 2024
@nefarius nefarius added this to the Version 3 milestone Aug 14, 2024
@nefarius nefarius self-assigned this Aug 14, 2024
@nefarius nefarius reopened this Oct 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Core/Common Driver Topic enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant