This page answers common questions about what GhostInput does, how the pieces fit together, and what to expect from a typical simulator setup. For detailed instructions, see the User Guide. For problems with an existing setup, see Troubleshooting.
GhostInput lets physical joysticks, throttles, button boxes, keyboards, mice, and audio hardware live away from the simulator PC. A Host Pi reads the physical devices, a Client Pi presents virtual USB or Bluetooth devices to the target computer, and GhostInput Studio configures the routes between them.
Games see ordinary HID and audio devices. They do not need a GhostInput-specific plugin.
- Host: the Raspberry Pi near the physical controllers. It captures input and sends it across the local network.
- Client: the Raspberry Pi connected to the target computer. It exposes virtual USB or Bluetooth HID devices and optional USB audio devices.
- Studio: the Windows application used to provision, configure, update, and diagnose the Pis.
The usual starting point is a Raspberry Pi 4 or 5 as the Host and a Raspberry Pi Zero 2 W as the Client. See Hardware and Environment for more detail.
No. GhostInput Studio currently requires Windows, but Studio does not need to run on the gaming computer. It can manage the Pis from a separate Windows PC on the same trusted LAN.
The computer connected to the Client may run Windows or Linux, including gaming-focused distributions such as SteamOS or Bazzite. It receives standard USB/Bluetooth HID and USB audio devices and does not need GhostInput-specific software. Windows is the primary tested target; Linux enumeration, Bluetooth, audio, naming, and game bindings can vary by distribution and application.
No. Studio writes the configuration to the Pis, whose services run the routes. You can close Studio after applying the configuration. Studio is only needed when you want to change routes, inspect live status, run diagnostics, provision devices, or install updates.
No. Normal routing and management happen on the local network. Internet access is useful for downloading releases and operating-system packages, but it is not part of the realtime input or audio path.
Yes. One Host can provide routes to multiple Clients, and one Client can receive routes from multiple Hosts. Most setups should begin with one of each and grow only when the physical layout calls for it.
GhostInput is designed around standard Linux HID devices, including many joysticks, throttles, button boxes, keyboards, mice, and game controllers. Optional audio relay uses ALSA devices. Hardware and firmware vary, so a device that exposes unusual or vendor-specific interfaces may need additional work.
The current development baseline is listed in Hardware and Environment.
A USB route consumes one of the Client's limited USB gadget functions and appears through the Client's USB connection to the PC. A Bluetooth route uses the Client's paired Bluetooth HID interface and does not consume a USB gadget lane. Bluetooth behavior and reconnection can vary by Windows version, adapter, and firmware.
The Client has a limited number of USB gadget lanes. Grouping lets several joystick-style routes, and optionally a Virtual Keyboard, share one USB HID function.
The tradeoff is device identity: grouped members no longer appear to Windows as separate devices with their original USB descriptors, VID, and PID. Keep a device ungrouped when a simulator or companion application depends on its original identity. See Grouped Controllers and USB Lanes.
An unresolved route refers to a Host device that GhostInput cannot currently match. Confirm that the correct Host is online and the device is connected, then allow the Device Routing page to refresh or correct the route.
A sleeping device is known to the Host but is not currently active. This is common for wireless and Bluetooth controllers. Wake the device before assuming that its route is broken.
Signal strength measures received radio power, not packet loss, interference, airtime contention, access-point scheduling, or brief latency spikes. A link showing 100% signal can still produce input gaps or audio stutters.
Use wired Ethernet for the Host when practical. The Pi Zero 2 W Client is limited to 2.4 GHz Wi-Fi, so router/access-point quality and channel congestion matter. The Network Test page and Wi-Fi troubleshooting can help separate application behavior from network behavior.
There is no single number that applies to every setup. HID latency depends on the configured pacing interval, the network, the source device, and Windows USB handling. Audio also includes codec, jitter-buffer, ALSA, and playback-device latency. Wired or clean Wi-Fi links and sensible pacing provide the best results; very aggressive settings can reduce stability without improving the actual experience.
Wi-Fi packets do not always arrive at perfectly even intervals. The audio network buffer absorbs ordinary jitter so ALSA continues receiving a steady stream. A larger buffer is more resilient but adds latency. Start with Balanced (120 ms), use Low latency (60 ms) on a clean link, and use Stable (180 ms) when playback remains sensitive to packet bursts.
See Audio Relay for the complete setup guidance.
No. GhostInput's authentication protects its control and stream-start paths from casual unauthenticated access on a private LAN, but realtime UDP data is not encrypted. Run it only on a private network you trust and never forward its ports from the internet. Use a trusted VPN if remote access is required. See Security for the threat model and limitations.
Studio normally stores the installation identity in Windows Credential Manager. After a clean Windows installation, Studio can recover that identity over SSH from an existing provisioned Pi. If neither the Windows credential nor any provisioned Pi retains it, a new identity must be created and the devices must be reprovisioned.
See Reinstalling Studio or Reimaging the Windows PC before resetting every device at once.
Normal provisioning and updates are designed to preserve profiles, security identity, Bluetooth state, and unrelated Linux configuration. Use the explicit reset/clear option when you intend to remove an existing GhostInput configuration. Keeping a backup of an important Client profile is still a good precaution before major system work.
- Confirm that the Host and Client are online in Studio.
- Check the route state on Device Routing.
- Review the managed device Status and Network Test pages.
- Restart the affected GhostInput service if its configuration has changed.
- Follow the focused checks in Troubleshooting, including
the
journalctlcommands for Host and Client logs.