User-mode virtual controllers for Windows. No kernel driver, no network, no reboot. DirectInput, XInput, SDL3, the browser Gamepad API, and WGI all see the exact identity of real hardware, down to the bus type.
HIDMaestro talks to its driver through shared memory on the same machine. No socket, no USBIP stack, no kernel transport driver in the path. Input is event-driven, with no batching cap. The number above is real propagation, measured over 10,000 single-press iterations and reproducible with one command. See the methodology. VIIPER's 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.
Networking belongs in the application, not in the device driver. Tools built on USB/IP put a kernel USBIP driver and a listening socket in front of every user, even for purely local play. USB/IP can also only present USB devices, so a controller paired over Bluetooth shows up with the wrong bus type. HIDMaestro keeps the device layer local and sets bus type per profile, so a Bluetooth controller presents as Bluetooth. Network play still happens, at the right layer: PadForge, built on HIDMaestro, shares controllers across PCs with its Remote Link feature, both directions with feedback returning to the real device, at no cost to local play.
| HIDMaestro | VIIPER | ViGEmBus | vJoy | WinUHid | |
|---|---|---|---|---|---|
| Kernel driver required | No | 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, 225 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 |
HIDMaestro is Windows optimized and focused on game controllers and HID game devices. Within that scope it gives you exact hardware identity with no kernel driver, no network layer, and no per-device code.
Runs entirely in user mode via UMDF2, loaded by a locally trusted self-signed certificate. No test-signing mode, no purchased certificate, no reboot. It installs on a normal PC, not just a developer box, and a bug cannot blue-screen the machine.
Input travels through shared memory on the same machine. No socket, no USBIP stack, no kernel transport driver between your application and the device.
Profile-driven VID/PID, product strings, HID descriptors, and bus type. A Bluetooth controller reports as Bluetooth, not as a USB device wearing its name.
Embedded profiles across 32 vendors: Xbox 360, Xbox Series, DualSense, Thrustmaster, Logitech, flight sticks, racing wheels, and more.
DirectInput, XInput, SDL3/HIDAPI, browser Gamepad, WGI/GameInput, and RawInput all see the same real controller at once.
A 41-scenario regression battery checks DirectInput, XInput, SDL3, the browser Gamepad API, and WGI on every change, passing on both a 16-core Windows 11 desktop and a low-power Intel Atom Windows 10 machine.
Add a controller by writing a data-only JSON profile or capturing one you already own. No per-device source code, no recompile, no hardcoded device classes.
Create and remove controllers on the fly. About 200 ms for a single controller. No reboots, no leftover devices.
No hard limit on simultaneous virtual controllers. Tested with 6 mixed types, correct ordering across every API.
Free and open source. Use it in your own projects, commercial or otherwise, with no restrictions.
HIDMaestro is a developer platform. Clone the repo or grab a release to get started.
Prerequisites: