Hello @Dr-Obek, we're using one issue report per unofficially supported game title, so I've gone ahead and transferred this issue report to https://github.com/ValveSoftware/Proton/issues/8727#issuecomment-4223989897.
proton 10.0-4x1 2026-04proton experimentalx1 2026-04PROTON_USE_WAYLAND=0`x1 2026-04PROTON_USE_WAYLAND=0`).x1 2026-04WINEDEBUG=+rawinput,+dinput,+eventx1 2026-04WINEDLLOVERRIDES="dinput8=b"x1 2026-04WINEDLLOVERRIDES="dinput8=d"x1 2026-04WINEDLLOVERRIDES="dinput8=n"x1 2026-04whgame.dllx1 2026-04
Compatibility Report
System Information
I confirm:
Symptoms
Camera/mouse input is intermittently broken. On some launches, the camera flies uncontrollably when touching the mouse. On other launches, mouse works perfectly. The issue occurs on both native Wayland and XWayland (
PROTON_USE_WAYLAND=0).Root cause: Wine's
dinput_mouse_rawinput_hookinterceptsWM_INPUTmessages and returns absolute screen coordinates instead of relative deltas via the unimplementedMOUSE_VIRTUAL_DESKTOPflag.The game registers raw input for mouse via its own code (
RegisterRawInputDevices, usage 0x2) AND creates a DirectInput8 mouse device. Wine's dinput8 installs aWH_INPUThook that interceptsWM_INPUTbefore the game's own handler processes them. The hook has a known unimplementedMOUSE_VIRTUAL_DESKTOPflag (fixme) which causes absolute coordinates to be reported as relative deltas (inferred from behavior: values accumulate ~1320/frame, consistent with cursor position being added each frame).The issue is intermittent — it appears to depend on focus timing during startup. When the dinput8 mouse device is not acquired (e.g., window doesn't have focus at the right moment), the
WH_INPUThook doesn't process mouse messages, and the game's own raw input handler works correctly.Reproduction
Broken Launch — Wine Debug Trace
Launch options:
WINEDEBUG=+rawinput,+dinput,+event %command%Full debug log attached. Key sequence:
1. Focus established on game window:
2. DirectInput creates mouse device with DISCL_FOREGROUND:
3. Game thread registers raw input for mouse:
4. dinput's WH_INPUT hook immediately intercepts with broken absolute coordinates:
Values accumulate every frame (x -376, x -750, x -1126...). These appear to be absolute cursor positions, not relative deltas.
Working Launch
When the game works correctly,
dinput_mouse_rawinput_hookis never called. The game's own raw input handler processesWM_INPUTdirectly without dinput8 intercepting.The difference is likely focus timing: if the dinput8 mouse device is not acquired when
WM_INPUTmessages arrive, the hook doesn't process them, and the game works correctly. This has not been conclusively proven.Analysis
dinput_mouse_rawinput_hookindlls/dinput/mouse.chasMOUSE_VIRTUAL_DESKTOPmarked asfixme— unimplementedRegisterRawInputDevicesfor mouse (usage 0x2)WH_INPUThook interceptsWM_INPUTmessages before the game's handlerWorkarounds Attempted (None Effective)
PROTON_USE_WAYLAND=0(XWayland) — same bugWINEDLLOVERRIDES="dinput8=d"— game fails to load WHGame.dllWINEDLLOVERRIDES="dinput8=n"— only 32-bit native available via winetricks, game is 64-bitWINEDLLOVERRIDES="dinput8=b"— same as defaultHKCU\Software\Wine\DirectInput\RawInput=disable— not respectedMouseWarpOverride=enable/force— no effecti_mouse_buffered 1— doesn't fix at runtimeSuggested Fix
Implement
MOUSE_VIRTUAL_DESKTOPflag handling indinput_mouse_rawinput_hook(dlls/dinput/mouse.c). When the flag is present, the raw input data contains absolute coordinates and should be converted to relative deltas (current position minus previous position) before being passed to the game.Alternatively, prevent dinput8's
WH_INPUThook from interceptingWM_INPUTmessages when the game has registered its own raw input handler for the same device viaRegisterRawInputDevices.Logs
https://gist.github.com/Dr-Obek/c567e7efe4f7820e4fde253da2627a18