protonscr

Kingdom Come: Deliverance II — camera flies uncontrollably due to dinput8 MOUSE_VIRTUAL_DESKTOP fixme

protonclosed appid 1771300
ValveSoftware/Proton#9655 · opened 2026-04-10 by Dr-Obek · updated 2026-04-10 · 1 comments · github · game page · search this game
1 matching comments, n / p to jump
DDr-Obek 2026-04-10 github

Compatibility Report

  • Name of the game with compatibility issues: Kingdom Come: Deliverance II
  • Steam AppID of the game: 1771300

System Information

  • GPU: NVIDIA GeForce RTX 5070 Laptop GPU (8 GB VRAM)
  • Video driver version: NVIDIA 580.126.18 (open), OpenGL 4.6
  • Kernel version: 6.18.7-76061807-generic
  • Link to full system information report as [Gist](https://gist.github.com/):
  • Proton version: Tested with Proton Experimental (10.1000-200) and Proton 10.0-4 — both affected
  • OS: Pop!_OS 24.04 LTS (COSMIC desktop, Wayland-only)
  • CPU: AMD Ryzen AI 9 HX 370 (24 logical / 12 physical)
  • Hardware: Framework Laptop 16

I confirm:

  • [x] that I haven't found an existing compatibility report for this game. (Note: #8727 exists for KCD2 but covers a different issue — freezing after 5 minutes, not mouse/camera input.)
  • [x] that I have checked whether there are updates for my system available.

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_hook intercepts WM_INPUT messages and returns absolute screen coordinates instead of relative deltas via the unimplemented MOUSE_VIRTUAL_DESKTOP flag.

The game registers raw input for mouse via its own code (RegisterRawInputDevices, usage 0x2) AND creates a DirectInput8 mouse device. Wine's dinput8 installs a WH_INPUT hook that intercepts WM_INPUT before the game's own handler processes them. The hook has a known unimplemented MOUSE_VIRTUAL_DESKTOP flag (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_INPUT hook doesn't process mouse messages, and the game's own raw input handler works correctly.

Reproduction

  1. Install KCD2 on a Wayland Linux system (Pop!_OS 24.04 LTS, COSMIC compositor)
  2. Launch the game repeatedly
  3. On some launches, the camera immediately flies upward/sideways uncontrollably when touching the mouse
  4. On other launches, mouse works perfectly

Broken Launch — Wine Debug Trace

Launch options: WINEDEBUG=+rawinput,+dinput,+event %command%

Full debug log attached. Key sequence:

1. Focus established on game window:

0130:trace:event:set_focus setting foreground window to 0x100dc
0130:trace:event:X11DRV_FocusIn window 0x100dc/6600004 FocusIn serial 290

2. DirectInput creates mouse device with DISCL_FOREGROUND:

0130:trace:dinput:mouse_create_device dinput ..., guid {6f1d2b60-...}
0130:trace:dinput:_dump_cooperativelevel_DI  cooperative level : DISCL_FOREGROUND DISCL_NONEXCLUSIVE

3. Game thread registers raw input for mouse:

02b4:trace:rawinput:NtUserRegisterRawInputDevices device 0: page 0x1, usage 0x2, flags 0, target 0x200aa.

4. dinput's WH_INPUT hook immediately intercepts with broken absolute coordinates:

02b4:trace:dinput:dinput_mouse_rawinput_hook iface ..., wparam 0, lparam 0x14, ri ...
02b4:fixme:dinput:dinput_mouse_rawinput_hook Unimplemented MOUSE_VIRTUAL_DESKTOP flag
02b4:trace:dinput:dinput_mouse_rawinput_hook buttons 00 00 00 00 00, x -404, y -578, w +0

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_hook is never called. The game's own raw input handler processes WM_INPUT directly without dinput8 intercepting.

The difference is likely focus timing: if the dinput8 mouse device is not acquired when WM_INPUT messages arrive, the hook doesn't process them, and the game works correctly. This has not been conclusively proven.

Analysis

  1. dinput_mouse_rawinput_hook in dlls/dinput/mouse.c has MOUSE_VIRTUAL_DESKTOP marked as fixme — unimplemented
  2. When the flag is set, raw input data appears to contain absolute screen coordinates, but the hook likely treats them as relative deltas (inferred from behavior: values accumulate ~1320/frame, consistent with cursor position being added each frame)
  3. The game uses BOTH dinput8 mouse AND its own RegisterRawInputDevices for mouse (usage 0x2)
  4. Wine's dinput8 WH_INPUT hook intercepts WM_INPUT messages before the game's handler
  5. Whether this happens appears to depend on DISCL_FOREGROUND acquisition timing — likely a race condition during startup (in working launches the hook never fires; in broken launches it fires immediately)

Workarounds Attempted (None Effective)

  • PROTON_USE_WAYLAND=0 (XWayland) — same bug
  • WINEDLLOVERRIDES="dinput8=d" — game fails to load WHGame.dll
  • WINEDLLOVERRIDES="dinput8=n" — only 32-bit native available via winetricks, game is 64-bit
  • WINEDLLOVERRIDES="dinput8=b" — same as default
  • Wine registry HKCU\Software\Wine\DirectInput\RawInput=disable — not respected
  • Wine registry MouseWarpOverride=enable/force — no effect
  • CryEngine cvar i_mouse_buffered 1 — doesn't fix at runtime
  • Deleting shader cache — changes startup timing, sometimes avoids the race condition temporarily
  • Resetting Wine prefix — no effect

Suggested Fix

Implement MOUSE_VIRTUAL_DESKTOP flag handling in dinput_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_INPUT hook from intercepting WM_INPUT messages when the game has registered its own raw input handler for the same device via RegisterRawInputDevices.

Logs

https://gist.github.com/Dr-Obek/c567e7efe4f7820e4fde253da2627a18

Kkisak-valve maintainer 2026-04-10 github

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.