Identity and fidelity
- Exact hardware identity
- Profile-driven VID/PID, product strings, HID descriptors, axis and button layout, and bus type. A Bluetooth controller reports as Bluetooth, not as a USB device wearing its name. SDL3's controller database matches it, Steam recognizes it, Chrome identifies it, joy.cpl shows the right name.
- Valve personas Steam recognizes
- Three composite personas present the whole USB device a real Valve controller presents: the Steam Deck's controller (five interfaces, reproduced from a real unit's lsusb dump), the wired 2015 Steam Controller (every descriptor verbatim from a real unit), and the 2026 Steam Controller. Steam files them under its own hardware rather than Generic DirectInput, answers arrive for the GET_REPORT interrogation Steam performs before claiming a device, and each packs its own wire format cross-checked against SDL's decoders.
- A Switch Pro that answers back
- The Switch Pro Controller is not a passive device: hosts drive a Nintendo subcommand handshake and stall without a device that answers. HIDMaestro's driver answers it over the real Bluetooth wire, with a descriptor extracted byte-exact from a live Pro's SDP cache: SPI calibration reads, input-mode switch, 60 Hz full-mode streaming with gyro and accel. SDL3 and Steam Input bind it as a real Bluetooth Pro Controller with motion and rumble.
- Controller audio and haptics
- A real USB DualSense is a four-interface composite, and three profiles present all four. Windows gets the pad's own Speakers and Headset Microphone endpoints, and the 4-channel stream behind them carries the speaker on channels 1 and 2 and the voice-coil actuators on 3 and 4. That stream is the only path on Windows by which a game hands a controller its authored haptic waveforms. It reaches your code as UsbAudio.Output with each channel's role named. Nothing extra to install: the USB transport ships inside the DLL and deploys itself the first time you create one.
- Capture a controller you own
- Point HMDeviceExtractor at any controller you have plugged in and get a ready-to-deploy profile back. Clone a DualSense and ship a 16-button variant that Windows, Steam, and games still see as a DualSense. Build a flight stick, racing wheel, or arcade panel from scratch with arbitrary VID/PID, axis count, button count, and resolution.
The catalog
- 231 device profiles
- Embedded profiles across 46 vendors: Xbox 360, Xbox Series, DualSense, Thrustmaster, Logitech, flight sticks, racing wheels, and more. Every controller is a JSON file. Adding support for a new one means writing JSON, not modifying code.
- Devices are JSON
- Add a controller by writing a data-only JSON profile or by capturing one you already own. No per-device source code, no recompile, no hardcoded device classes. Adding a controller to a code-per-device emulator means writing and compiling a new device implementation. That difference is the whole point of the profile system.
Latency and transport
- ~35 µs measured input latency
- The input number is real propagation, measured over 10,000 single-press iterations and reproducible with one command. The methodology is published in the repository at docs/testing/latency.md.
- Event-driven output at 0.15 ms
- Rumble, force feedback, and LED packets are signaled to the consumer per captured packet at ~0.18 ms median, roughly 50x faster than the 9.4 ms poll-quantized path it replaced, with idle controllers costing zero measurable CPU.
- No socket, no batching cap
- Standard profiles use shared memory between the SDK and UMDF2 drivers. Input and output are signaled per frame or packet. Composite profiles use the bundled USB/IP transport over a loopback connection.
- The comparison, honestly
- VIIPER's published Windows figure, 168 µs, is localhost-only. Running it over an actual network, the thing the project is named for, adds roughly 1 to 5 ms on wired LAN or 10 to 50 ms over Wi-Fi on top of that figure, a caveat its docs mention only in passing. It also batches reports every millisecond, capping the update rate at 1000 Hz. HIDMaestro's input is event-driven with no fixed cap.
- Networking at the right layer
- Standard profiles keep controller traffic in shared memory. Composite profiles use a local loopback USB/IP connection. Applications can build network sharing above the SDK, as PadForge does with Remote Link.
- Fast to start, fast to recover
- When the installed driver already matches, InstallDriver() completes in ~40-60 ms and a consumer goes from process start to a live controller in about a second. If the consuming app is force-closed mid-session, the next launch evicts the orphaned devices and has the first controller live again in ~2.3 s, measured with an Xbox Series BT profile in the mix, the deepest teardown stack.
APIs and consumers
- Every gaming API at once
- DirectInput sees correct axes and buttons. XInput sees separate triggers in one slot. SDL3/HIDAPI sees the right identity and bus type. The browser sees a STANDARD GAMEPAD with separate triggers. WGI sees one Gamepad. RawInput sees the same device as all of them, at the same time.
- Multi-controller
- No hard limit on simultaneous virtual controllers. Tested with 6 mixed types, correct per-controller ordering across every API. XInput caps Xbox-family profiles at its own 4 slots; non-Xbox profiles run beyond it.
- Hot-plug
- Create and remove controllers on the fly, about 200 ms for a single controller. Live-swap a controller's profile mid-session. No reboots, no leftover devices.
- Force feedback answered
- HID PID 1.0 answers for DirectInput force-feedback games, plus rumble and haptic output events the consumer routes to real hardware. The driver accepts the writes and raises them to your application in real time.
VR
- Virtual VR controllers
- An embedded OpenVR driver presents a left and a right hand to SteamVR. The hands hold real SteamVR hand roles, serve the modern input system through a full input profile, and serve legacy GetControllerState readers through a shipped legacy binding. Controllers exist only while a consumer is live, so an idle machine shows no phantom devices. SteamVR is the one dependency, and it installs Steam-client-free and account-free via Valve's own steamcmd.
The SDK
- One DLL
- HIDMaestro.Core.dll contains the 231-profile catalog, a driver and helper payload for x64 and one for ARM64, the signing tools, and the signed USB/IP installers for both. It picks the set matching the machine. The OpenVR plugin is x64 for its SteamVR host.
- Self-bootstrapping install
- InstallDriver() creates a locally trusted certificate, signs the driver, and installs it. No EV certificate, no test-signing mode, no reboot. When the installed driver already matches, the call completes in ~40-60 ms.
- A UI instead of code
- If you want to use HIDMaestro through a UI instead of code, install PadForge. It wraps this SDK with a full input-mapping app.
Validation
- Regression coverage
- The battery has 60 scenarios covering lifecycle, encoders, consumer APIs, USB/IP, VR, the battery reply a pad gives XInput, and device identity across nine lives per family. The last full run was 60/60 on a 16-core Ryzen 9 Windows 11 desktop. Production signing and the full HIDMaestro integration gate remain pending.
- Judged by the real consumers
- The battery does not only check HIDMaestro's own decode of its own encode. A stock upstream SDL3 build reads the Valve personas and must bind each with its own Valve driver, and a scenario starts the actual Steam client and asserts it claims and classifies them. The decoders Steam Input is built on are the judges.
Platform and licensing
- Native on ARM64 Windows
- From v1.9.0 the HID driver, the XInput companion and the device helper are built for ARM64 as well as x64, and the INFs carry an NTARM64 section. HIDMaestro.Core.dll holds both sets and installs the one matching the operating system. Composite personas use a Microsoft-signed ARM64 build of the USB transport. The release has an ARM64 ZIP with an ARM64 test app and profile extractor. No ARM64 machine has run the regression battery yet.
- Windows 10 and 11
- Windows 10/11 on x64 and Windows 11 on ARM64, with .NET 10 and a 64-bit consumer. v1.9.0 publishes a ZIP for each.
- UMDF2 standard profiles
- Standard profiles run through the Windows UMDF2 stack and a locally trusted signing certificate. Composite profiles use the bundled Microsoft-signed USB/IP transport. The installation does not enable Windows test-signing mode.
- The composite exception, stated
- Composite Sony and Valve profiles use the bundled usbip-win2 0.9.7.5 kernel transport, redistributed unmodified and verified against the upstream SHA256 at build and again before execution. The SDK installs it silently on a machine that has none and never invokes the vendor uninstaller. A machine HIDMaestro put on 0.9.7.7 is moved to 0.9.7.5 automatically, through one Windows driver update that leaves the root-hub filter alone, in a session where the controller is still unused.
- MIT licensed
- Free and open source. Use it in your own projects, commercial or otherwise, with no restrictions.
Full comparison
Every capability, against the tools people usually reach for. The product page carries a shortened version of this table.
| Capability | HIDMaestro | VIIPER | ViGEmBus | vJoy | WinUHid |
|---|---|---|---|---|---|
| Kernel driver required | No, except the composite USB personas | Yes (USBIP) | Yes | Yes | No (on VHF) |
| Installs without test-signing | Yes | Yes | Yes | Yes | No |
| Network play | App layer via consumers (PadForge Remote Link) | In the driver: +1-5 ms wired, +10-50 ms Wi-Fi | No | No | No |
| Exact identity, incl. Bluetooth bus | Yes, 231 profiles | USB only | 2 fixed types | Fixed identity | 4 presets, USB only |
| Add a new device | JSON, or capture one you own | Write Go per device | N/A | N/A | Write C, or raw descriptor |
| Local single-press latency | ~35 µs measured | 168 µs published | N/A | N/A | Not published |
| Status | Active | Active | Retired | Stale | Active |
Questions, answered plainly
Is it really free?
Yes. MIT licensed, free and open source, commercial use welcome with no restrictions. HIDMaestro will never become paid, freemium, or Patreon early-access paywalled.
Do I need to enable test-signing mode?
No. Standard profiles use UMDF2 with a locally trusted certificate. The bundled USB/IP kernel packages retain their upstream Microsoft signatures. The SDK does not enable Windows test-signing mode.
Does anything kernel-mode get installed?
Composite Sony and Valve profiles install the bundled usbip-win2 0.9.7.5 transport on a machine that has none. Standard profiles use the Windows UMDF2 stack. A machine HIDMaestro put on 0.9.7.7 is moved to 0.9.7.5 automatically, with no window and no USB device dropping, so there is nothing to do when updating.
Can I add a controller you don't ship?
Yes, without touching code. Write a data-only JSON profile, or point HMDeviceExtractor at a controller you have plugged in and get a ready-to-deploy profile back.
How is this different from ViGEmBus, vJoy, or VIIPER?
Those tools install kernel drivers and present a small set of fixed device types. HIDMaestro runs in user mode and presents the exact identity of the profile you pick, 231 of them, down to the bus type, and adding a device means writing JSON rather than driver code. VIIPER additionally routes input through a network stack even for local play. The full comparison table above puts the tools side by side.
Does it work with Steam?
Yes. Steam recognizes the virtual controllers as the hardware their profiles declare, and the Valve personas go further: Steam files them under its own hardware, with the regression battery starting the actual Steam client to prove it claims and classifies all three.
Does HIDMaestro support ARM64?
Yes, from v1.9.0. One HIDMaestro.Core.dll serves x64 and ARM64 and carries a native driver payload for each, and the release has an ARM64 ZIP with an ARM64 test app and profile extractor. The ARM64 payload builds and is signed, and no ARM64 machine has run the regression battery yet.