Games using Raw Input have broken mouse drag/zoom on headless setups with no physical mouse

[Licho1]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the nightly release?

• This issue is present in the nightly release

Describe the Bug

On a headless Windows setup with no physical mouse connected, games that use the Raw Input API (WM_INPUT) for map/camera controls have broken mouse input when streaming via Sunshine + Moonlight.

Symptoms:

• GUI clicks work perfectly (menus, buttons, UI elements)
• Map drag (hold left mouse + move to scroll) is completely non-functional
• Mouse wheel zoom works but centers on the wrong point (top-left / origin instead of cursor position)
• Mouse cursor is visible and moves correctly at all times
• All other applications and games work fine

Root cause:
Sunshine injects mouse input via SendInput(). When no physical mouse device is present in Windows, the Raw Input subsystem does not properly dispatch WM_INPUT messages from SendInput() because there is no hardware device to attribute the events to. SendInput() still moves the system cursor and generates WM_MOUSEMOVE (which is why GUI works), but games reading WM_INPUT for map controls receive nothing or default values (explaining the zoom centering on 0,0).

Proof:
Plugging any USB mouse into the host machine immediately fixes the issue — even without using the mouse. Simply having a physical mouse device present causes Windows to properly route SendInput() events through the Raw Input pipeline.

Tested and ruled out:

• Windows DPI scaling (tried 100%)
• Game DPI override (Application mode)
• Sunshine high-resolution scrolling (disabled)
• Moonlight mouse mode (relative/game mode from start)
• Ctrl+Alt+Shift+M toggle mid-stream
• Game windowed/fullscreen/borderless modes
• Resolutions all matching across host and client

Suggested Fix

Sunshine already uses ViGEmBus to create virtual gamepad devices. A similar approach for mouse input — creating a virtual HID mouse device instead of (or in addition to) using SendInput() — would make the injected input appear as real hardware to Windows, ensuring proper WM_INPUT dispatch regardless of whether a physical mouse is connected.

Alternatively, Sunshine already detects the no-mouse condition for cursor visibility (Mouse Keys workaround in PR #721). This detection could be extended to warn users that some games may have input issues without a physical mouse present.

Expected Behavior

Games using the Raw Input API should receive proper mouse input from Sunshine regardless of whether a physical mouse is connected to the host.

Steps to Reproduce

1. Set up a headless Windows machine (no physical mouse connected)
2. Configure Sunshine and connect via Moonlight
3. Launch a game that uses Raw Input for map/camera controls (e.g., Nexus 5X / Stellaris Nexus)
4. Try to drag the map with left mouse button — does not work
5. Try to zoom with scroll wheel — zooms toward top-left instead of cursor
6. Plug in any USB mouse to the host
7. Both drag and zoom now work correctly

Host Operating System

Windows

Operating System Version

Windows 11 Pro

Apps

Nexus 5X (Steam App ID 1983990) — likely affects any game using Raw Input API for camera/map controls

[busybox11]

Seeing the same issue on a Linux machine. The docs do mention that plugging in a physical mouse should fix the weirdness we're seeing. However, the issue consistently happens on my end now, and I don't remember it being consistent before.

Mostly seeing this on Zen Browser (based on Firefox), not on Chromium-based ones.

Running 2026.226.41312, commit 98dc21954ea0c254f058ef5b3b3ec6aef359e2aa on Hyprland. Don't have the time to bisect now unfortunately.