[Feature] Expose guest virtual HID/USB devices (e.g. TARGET virtual joystick) to Linux host

[TYeniyayla]

Feature Description

Hi, first of all thanks for WinBoat – it works great for running Windows apps that don’t behave well under Wine/Proton.

I have a use-case where WinBoat is almost the perfect solution, but it’s currently blocked by how input devices are exposed:

• I’m passing a physical HOTAS (Thrustmaster Warthog) via USB passthrough into the Windows VM.

• Inside the VM I run Thrustmaster T.A.R.G.E.T, which creates a virtual combined joystick (e.g. “Thrustmaster Combined”) and exposes that as a virtual HID device to Windows.

• Tools running inside WinBoat see this combined device fine, but on the Linux host there is no way to see or use that virtual HID. Only the original physical USB device exists on the host side.

For some scenarios (e.g. running a game via Proton on the host, but using WinBoat only for TARGET or other Windows-only input software), it would be extremely useful if WinBoat could:

1. Forward virtual HID devices from the guest to the host, or

2. At least provide a mechanism to stream guest HID events to the host and create a virtual input device via uinput (evdev) on Linux.

Rough idea of a possible implementation:

• In the Windows guest, WinBoat Guest Server (or a small helper) could read events from selected HID devices (e.g. those flagged as “share with host” in the UI).

• These events could be sent to the host over a virtio/socket channel.

• On the Linux side, a small daemon could create a virtual joystick/gamepad using /dev/uinput and replay those events, so applications on the host see a normal joystick device (e.g. /dev/input/jsX / eventX).

This would enable setups like:

• Windows-only input stack (TARGET, vJoy, etc.) inside WinBoat

• Game running natively or via Proton on the Linux host

• Host sees a single, nicely combined virtual joystick instead of raw device fragments

Even a limited implementation (e.g. forward one selected virtual HID as a single virtual joystick on the host) would already solve a lot of real-world use cases.

Would it be feasible to add some form of “guest HID → host virtual input” support like this to WinBoat?

Thanks!

Use-Case

I’m running Linux as my main OS and use WinBoat only to host Windows-only input software (e.g. Thrustmaster T.A.R.G.E.T) that creates a virtual combined HID device. The actual game (Elite Dangerous in my case, but this applies to any sim / game with complex controls) is running on the Linux host via Proton.

Right now I have two sub-optimal options:

• Run both the game and TARGET fully inside Windows (losing the benefits of my native Linux setup), or

• Skip TARGET and manually bind the raw devices on Linux (losing all the advanced layered mappings, macros and quality-of-life features provided by TARGET / other input tools).

If WinBoat could expose the guest’s virtual HID as a host-side virtual joystick (or provide an event stream that a uinput helper on the host can turn into a joystick), I could:

• Keep the full Linux gaming stack (Proton, native tools, overlays, etc.)

• Still use Windows-only input stacks (TARGET, vJoy, custom Windows joystick software) inside WinBoat

• Present a single, clean virtual controller to the game, instead of multiple raw devices with duplicated or missing bindings

• Reuse the same Windows mapping setup across different host games without re-binding everything per title

This is especially valuable for HOTAS / sim setups where:

• Many buttons, hats and axes are spread across several physical devices

• Advanced logic (modifiers, modes, macros, tempo taps, context-sensitive bindings) is implemented in Windows tools

• Recreating that logic natively on Linux is either impossible or extremely time-consuming

So, exposing guest virtual HID devices to the host would make WinBoat a perfect bridge between Windows-only input ecosystems and Linux-hosted games.

Proposed Implementation

No response

Notice

• I have checked the issue tracker and verified that this Feature Request has not been proposed before.
• I would like to help out implementing this feature