Network-connected controls for simulator rigs.
GhostInput routes joysticks, keyboards, mice, and audio across your local network using Raspberry Pis, then presents them to the computer running your game or simulator as standard USB or Bluetooth HID devices.
Put the controls at the rig, keep the computer somewhere sensible, and stop running USB cables across the room like tripwires.
Games and simulators do not need GhostInput-specific plugins. The Client Pi presents ordinary HID and USB audio devices, so applications continue using their normal input and audio interfaces.
GhostInput Studio currently runs on Windows, but the computer receiving the Client's virtual devices does not have to. It can be a Windows or Linux gaming system—including distributions such as SteamOS or Bazzite—provided the target OS and game support the standard HID or audio device being exposed. Studio can run on a separate Windows computer on the same trusted LAN.
Download GhostInput Studio | User Guide | Hardware | FAQ | Security | Troubleshooting
GhostInput normally uses three roles:
- Host: a Raspberry Pi near the physical controls and audio devices.
- Client: a Raspberry Pi connected to the target computer through USB OTG and/or Bluetooth.
- Studio: the Windows application used to provision, configure, monitor, and update the system.
| Component | Role |
|---|---|
| Host Pi | Reads physical USB and Bluetooth devices near the simulator rig and sends their state across the network. |
| Network | Carries low-latency HID, control, and optional audio traffic between GhostInput devices. |
| Client Pi | Presents virtual USB HID, supported Bluetooth LE HID, and optional USB audio devices to the target computer. |
| GhostInput Studio | Provisions Pis, builds routes, manages mappings, monitors devices, runs diagnostics, and installs updates. |
A typical installation keeps the realtime data path separate from Studio's management connection:
flowchart LR
controls["Physical controls<br/>USB / Bluetooth"]
host["Host Pi<br/>Capture and stream"]
client["Client Pi<br/>Virtual devices"]
target["Target computer<br/>Windows or Linux"]
studio["GhostInput Studio<br/>Configure and monitor"]
controls --> host
host -->|LAN / Wi-Fi| client
client -->|USB OTG / Bluetooth LE| target
studio -.->|Control API| host
studio -.->|Control API| client
GhostInput is not limited to one Host and one Client. A Host can serve routes to multiple Clients, and a Client can receive routes from multiple Hosts when the physical layout requires it.
Most installations should start with one Host near the simulator rig and one Client connected to the PC.
GhostInput supports device types including:
- Joysticks and game controllers
- Flight controls and throttles
- Button boxes and control panels
- Keyboards
- Mice
The Host reads each physical device locally and sends its changing state to the Client. The Client then presents a corresponding virtual device to the target computer.
Depending on the route, the Client can expose devices as:
- USB HID
- Bluetooth LE HID
- Grouped USB HID devices
- Virtual joysticks
- Virtual keyboards
This allows the target computer to treat GhostInput devices much like locally connected controllers.
Compatible direct routes can also forward HID output and feature reports back toward the physical device. This can support hardware features such as:
- LEDs and annunciators
- Rumble and force feedback
- Vendor-specific output reports
GhostInput forwards compatible reports but does not attempt to interpret every proprietary device protocol.
GhostInput Studio is the Windows management application for the complete system. It handles:
- Raspberry Pi provisioning
- Host and Client discovery
- Device routing
- Grouped controller configuration
- Virtual-device mappings
- Bluetooth configuration
- Audio Relay
- Diagnostics and network testing
- Device status
- Software updates
A route connects a physical source on a Host to a virtual destination on a Client:
flowchart LR
physical["Physical joystick"]
host["Host Pi<br/>Read HID reports"]
client["Client Pi<br/>Apply route"]
virtual["Virtual USB joystick"]
target["Target computer<br/>Game or simulator"]
physical --> host
host -->|InputReportBatch over UDP| client
client --> virtual
virtual -->|USB OTG| target
Routes can be configured through Studio without manually editing service configuration files.
Raspberry Pi USB gadget configurations have a limited number of available USB function lanes. GhostInput can combine several joystick-style routes into one grouped USB HID device so that multiple physical controllers share one Client USB lane.
flowchart LR
throttle["Throttle"]
panel["Button box"]
pedals["Pedals / trim panel"]
keyboard["Virtual keyboard"]
grouped["Grouped USB HID<br/>One Client USB lane"]
target["Target computer"]
throttle --> grouped
panel --> grouped
pedals --> grouped
keyboard -.->|Optional| grouped
grouped -->|USB OTG| target
The source devices remain separate logical routes inside GhostInput, while the target computer sees the combined grouped controller. Mapped virtual keyboards can also join a grouped USB HID function instead of consuming a dedicated keyboard lane.
Grouping is particularly useful for simulator rigs with many panels, button boxes, throttles, pedals, or secondary controllers.
Grouped routes do not preserve each member device's original USB VID, PID, or descriptor identity. Some games may therefore require control assignments to be configured again for the grouped device.
See Grouped Controllers and USB Lanes for configuration details.
GhostInput can create a custom virtual joystick rather than reproducing one physical controller directly. You choose the target-facing layout, including:
- Axes
- Buttons
- Hats
You can then create mapping rules from physical Host inputs. Examples include:
- Mapping a physical button box to virtual joystick buttons
- Converting a hat direction into an axis action
- Using buttons to increment or decrement a trim axis
- Combining controls from multiple physical devices into one virtual controller
This is useful when the physical hardware layout does not match the device shape expected by the simulator.
See Virtual Joysticks and Mapping Rules.
GhostInput can also create mapped virtual keyboard devices. Physical controller inputs can generate keyboard actions such as:
- Held keys
- Key combinations
- Key taps
- Repeat-while-held actions
- Threshold and detent actions
- Short bounded macros
Virtual keyboards can be exposed through:
- A dedicated USB keyboard function
- The Client's Bluetooth LE keyboard
- A grouped USB HID device
This is useful for simulators where some cockpit functions are easier to bind through keyboard commands than joystick buttons.
See Virtual Keyboards.
Supported keyboard and mouse routes, as well as mapped virtual keyboards, can use Bluetooth LE HID instead of consuming a USB gadget function. Bluetooth behavior depends on Client hardware, Bluetooth firmware, Windows pairing state, and operating-system support.
See the User Guide and Troubleshooting for Bluetooth setup and recovery guidance.
GhostInput can optionally move audio between the target computer and the simulator rig. Both directions use Opus encoding for efficient low-latency network transport.
flowchart LR
target["Target-computer audio"]
client["Client Pi<br/>USB audio capture and Opus encode"]
host["Host Pi<br/>Recover, decode, and play"]
output["Speakers / headphones"]
target -->|USB Audio| client
client -->|Opus over UDP| host
host -->|ALSA| output
The target OS sees a USB audio playback device provided by the Client. The Client captures that audio stream and sends it to the Host for playback. Volume and mute changes made through the standard USB audio controls are applied to the relayed stream.
flowchart LR
microphone["Microphone"]
host["Host Pi<br/>ALSA capture and Opus encode"]
client["Client Pi<br/>Decode and feed USB audio"]
target["Target-computer microphone input"]
microphone -->|ALSA| host
host -->|Opus over UDP| client
client -->|USB Audio| target
The Host captures microphone audio and sends it to the Client, which presents it to the target OS through the USB microphone endpoint.
Audio Relay consumes one Client USB lane. See Audio Relay for setup guidance.
Bluetooth audio note: Bluetooth headset playback normally uses classic Bluetooth A2DP through BlueALSA, not Bluetooth LE Audio. It typically adds more latency than a directly connected ALSA output because of codec, transport, and headset buffering. A larger Host playback buffer can improve stability when underruns occur, but it also increases latency.
GhostInput separates realtime traffic from management operations.
HID input uses compact, paced UDP batches designed for frequently changing controller state. The routing design includes:
- Session identifiers and sequence tracking
- Ordered button and hat transitions
- Coalescing of replaceable axis and mouse state
- Bounded queues and processing budgets
- Configurable input pacing
Audio also uses UDP, with Opus providing compressed transport. Speaker relay adds bounded, deadline-aware replay for missing frames while keeping newer audio ahead of recovery work; Opus FEC and packet-loss concealment remain the fallback when replay can no longer arrive in time.
Management, provisioning, diagnostics, and other control operations use separate HTTP APIs rather than sharing the realtime HID and audio paths. The goal is to keep latency-sensitive work small and predictable instead of carrying controller data through a heavy remote-control protocol.
A practical starting configuration is:
GhostInput Studio currently requires Windows. It can run on the same Windows PC as the simulator or on a separate Windows computer connected to the same trusted LAN.
The target computer connected to the Client may run Windows or a Linux gaming distribution such as SteamOS or Bazzite. It does not run Studio or any GhostInput-specific receiver: it consumes the standard USB/Bluetooth HID and USB audio devices presented by the Client. Windows remains the primary tested target, so verify device enumeration, game bindings, Bluetooth behavior, and audio support on the chosen Linux distribution.
Recommended examples include a Raspberry Pi 4, Raspberry Pi 5, or another suitable Linux SBC. The Host normally sits close to the physical USB and Bluetooth hardware. Wired Ethernet is preferred where practical.
A Raspberry Pi Zero 2 W is a good Client choice because its USB port supports the USB gadget/OTG role required to present virtual devices to the target computer. The Client can connect to the local network over Wi-Fi while its USB OTG connection provides the target-facing gadget interface.
GhostInput is designed for a local network. Good Wi-Fi signal strength by itself does not guarantee good realtime performance: packet loss, interference, airtime congestion, latency variation, and access-point behavior all affect HID and audio quality.
See Hardware and Environment for tested hardware and detailed guidance.
- Download the latest GhostInput Studio release.
- Extract the complete
.ziparchive to a normal Windows folder you control. - Keep the extracted files together.
- Run
GhostInput.Studio.exe.
GhostInput Studio is distributed as a self-contained Windows package. Preview builds are not currently code-signed, so Microsoft Defender SmartScreen may display a warning. If you downloaded the package from the official GhostInput GitHub release and trust it, choose More info and then Run anyway. Do not disable SmartScreen globally.
Release packages include checksums.txt, which can be used to verify the
downloaded archive.
Flash Raspberry Pi OS onto the devices that will become the Host and Client. Using Raspberry Pi Imager, configure the hostname, Wi-Fi, SSH, and login credentials before first boot where convenient.
Open Provisioning in GhostInput Studio and provision each Raspberry Pi as either a Host or Client. Studio installs and configures the appropriate GhostInput software for that role.
Open Devices in Studio and select the Client connected to the target gaming computer.
Select Add Input Source, choose the Host and physical source device, select the desired Client output, configure any route-specific options, and apply the updated Client profile.
The target OS should then see the resulting Client-side virtual device. For the complete workflow, see the User Guide.
GhostInput is particularly useful where simulator controls are physically separated from the computer. Typical applications include:
- Flight simulation
- Sim racing
- Cockpit builds
- Truck and farming simulation
- Heavy-equipment simulation
- Custom button panels
- Distributed simulator controls
- Remote equipment consoles on a trusted LAN
Because the target OS sees ordinary HID devices, GhostInput does not require simulator-specific network-input plugins. The same routing architecture can be used across different applications.
GhostInput is designed for a trusted private LAN.
Provisioned installations use an installation identity and authentication for protected management operations. Studio normally handles this automatically; there is no separate certificate or device-pairing workflow during normal use.
Protected operations include reading detailed configuration, changing routes and device settings, starting streams, managing Bluetooth, running diagnostics, and restarting or updating services.
GhostInput intentionally does not provide end-to-end encrypted realtime transport. Current limitations include:
- Control APIs use HTTP rather than HTTPS.
- HID UDP streams are not encrypted or cryptographically authenticated.
- Audio UDP streams are not encrypted or cryptographically authenticated.
The challenge-response authentication process avoids sending the installation secret directly over the network, but GhostInput is not intended to secure a hostile or monitored LAN.
Recommended deployment:
- Use GhostInput only on a private network you trust.
- Keep guest and untrusted IoT networks separate where practical.
- Do not create internet-facing port forwards for GhostInput.
- Use a trusted VPN rather than exposing GhostInput directly for remote access.
- Protect the Windows Studio account and Raspberry Pi SSH credentials.
See Security for the complete design and limitations.
- USB gadget lanes: the Client has a limited USB gadget-function budget. Grouped controllers, grouped virtual keyboards, and Bluetooth output can help make better use of those lanes.
- Grouped device identity: grouped routes do not preserve the original USB identity of every member. Games may need new assignments after switching to a grouped or custom virtual device.
- Vendor-specific output: compatible HID output and feature reports can be forwarded, but GhostInput does not understand every proprietary protocol.
- Bluetooth: behavior varies with adapters, drivers, firmware, operating-system state, and pairing history.
- Network quality: realtime HID and especially audio performance depend on packet loss, Wi-Fi interference, congestion, latency variation, and access-point behavior.
- Audio latency: Audio Relay adds capture, buffering, Opus, network, and playback latency. Bluetooth playback adds further buffering.
See Known Limitations for more detail.
GhostInput Studio manages software updates for provisioned Hosts and Clients. Studio and its bundled Host/Client payloads should normally be updated together so protocol and profile versions remain compatible.
Normal updates are designed to preserve GhostInput routes, Audio Relay configuration, installation identity, Bluetooth bonds, and other user-managed device state. The provisioning workflow also offers an explicit reset option when a clean configuration is wanted.
| Document | Purpose |
|---|---|
| FAQ | Quick answers about roles, routing, grouping, networking, audio, security, upgrades, and recovery. |
| User Guide | Complete end-user setup and configuration workflow. |
| Troubleshooting | Discovery, USB gadget, routing, firewall, Bluetooth, audio, microphone, throttling, and log checks. |
| Hardware and Environment | Tested hardware, role guidance, USB lanes, networking, Bluetooth, and audio notes. |
| Security | Installation identity, private-LAN protection, authentication, recovery, and limitations. |
| Build From Source | Developer build and deployment instructions. |
| Developer Documentation | Architecture, protocol, discovery, HID model, profiles, and implementation references. |
GhostInput is under active development. The project currently includes:
- Host and Client provisioning
- Device discovery
- USB HID routing
- Bluetooth LE HID output
- Grouped controllers
- Virtual joysticks and virtual keyboard mappings
- Downstream HID output
- Audio Relay
- Diagnostics and telemetry
- Device management and updates
Hardware behavior can still depend on the exact Raspberry Pi model, USB devices, Bluetooth hardware, Raspberry Pi OS image, target operating system, and network quality.
GhostInput began as a personal project for a specific simulator setup and was later made public in case it is useful to others. There is no guaranteed support response time, release schedule, feature implementation, compatibility update, or bug-fix timeline. Issues, ideas, and useful reports are still welcome.
GhostInput is free and source-available. It may be used, copied, forked, modified, built, and run for personal, hobby, educational, research, and internal business use.
Commercial resale, paid redistribution, paid hosting, paid bundling, or rebranding GhostInput as a commercial product is not allowed without prior written permission. See LICENSE.md for the complete terms.