protonscr

Titan Quest II

protonopen appid 1154030Game compatibility - UnofficialRegression
ValveSoftware/Proton#10051 · opened 2026-08-09 by daveemu · updated 2026-08-12 · 1 comments · github · game page · search this game
1 matching comments, n / p to jump
Ddaveemu 2026-08-09 github

Compatibility Report

  • Name of the game with compatibility issues: Titan Quest II
  • Steam AppID of the game: 1154030

System Information

proton11.0-broken-rawinput.log
proton9.0.4-working-rawinput.log

  • Proton version: 11.0-1b (broken). Also broken: 10.0, Hotfix (hotfix-20260730), GE-Proton10-27, GE-Proton11-3. Working: 9.0-4f

Additional environment details relevant to this bug:

  • Arch Linux, KDE Plasma 6.7.3 / KWin 6.7.3, Wayland session (game runs through XWayland 24.1.13)
  • Dual monitor: DP-1 3440x1440+2560+0 (primary, game runs here), DP-2 2560x1440+0+0 — X screen 6000x1440
  • CPU/RAM: AMD Ryzen 9 3900X, 31 GiB
  • Steam 1.0.0.87
  • Engine: Unreal Engine 5, D3D12

I confirm:

  • [x] that I haven't found an existing compatibility report for this game.
  • [x] that I have checked whether there are updates for my system available.

Symptoms

Since Proton 10, the mouse is not processed during gameplay. Menus and UI react to the mouse
normally — movement, hover and clicks all work. As soon as gameplay starts, mouse movement and
clicks have no effect at all; the character does not move or attack. Keyboard input keeps working
in both menus and gameplay. Proton 9.0-4f is unaffected.

The regression is stable across Wine 10 and Wine 11 based builds, including GE builds, so it does
not appear to be something GE patches around.

Already ruled out

  • gamescope (gamescope -W 3440 -H 1440 -r 100 -f -- %command%), verified to actually wrap the
    game (own DISPLAY=:2, XDG_CURRENT_DESKTOP=gamescope): problem persists. This rules out the
    host compositor, KWin pointer constraints and the multi-monitor X screen geometry as sole cause.
  • GrabFullscreen=Y in HKCU\Software\Wine\X11 Driver: no change.
  • All in-game display modes (fullscreen, windowed, borderless): no change.
  • Focus loss: the broken log contains zero FocusIn/FocusOut events, so the game is not
    simply losing focus.
  • No controller connected, so this is not gamepad/Steam Input related.

Log analysis

Two runs were captured with WINEDEBUG=+rawinput,+dinput,+cursor PROTON_LOG=1 %command%, using
identical short sessions (enter gameplay, move mouse, click, quit).

Mouse motion reaches Wine correctly in both versions, with sane deltas:

trace:cursor:map_raw_event_coords event -8.332031,0.000000 raw value -10.000000,0.000000, raw input -10,0

The game never calls RegisterRawInputDevices (0 occurrences in both logs), so it relies on the
normal cursor path and therefore on the cursor clip requested via ClipCursor.

The difference is in grab_clipping_window:

Proton 9.0-4f (working):

trace:cursor:grab_clipping_window clipping to (1,1)-(3439,1439) win 3e00001
trace:cursor:grab_clipping_window user clip rect (1,1)-(3439,1439)
trace:cursor:grab_clipping_window setting real clip to (2561,1) x (3438,1438)

Proton 11.0-1b (broken):

trace:cursor:grab_clipping_window clipping to (1,1)-(3439,1439) win 3e00001

In 9.0-4f the requested clip rect is translated into real X screen coordinates, adding the game
monitor's X offset of 2560 — (1,1) becomes (2561,1). In 11.0-1b the user clip rect and
setting real clip traces do not appear anywhere in the log (0 occurrences each).

Proton 9.0-4f (works) Proton 11.0-1b (broken)
total log lines 25795 29635
grab_clipping_window lines 3 1
ungrab_clipping_window 12 11
map_raw_event_coords 7980 8839
RegisterRawInputDevices 0 0
FocusIn / FocusOut 0 0

Caveats

  • Missing traces do not prove missing behaviour. grab_clipping_window may have been
    refactored between Wine 9 and 10/11 with different TRACE output. Someone familiar with the
    x11drv changes should be able to confirm or dismiss this quickly.
  • This conflicts with the gamescope result. If the root cause were only the monitor offset
    translation, the game should work under gamescope, where it renders on a single 3440x1440 screen
    at origin 0,0. It does not. So either the offset translation is not the whole story, or gamescope
    fails for an independent reason. Not investigated further.
  • Not tested on an X11 session — only a Plasma Wayland session (XWayland) was tested.
  • Both sessions end without an active clip because the game was closed. That is expected and not a
    difference between the versions.

Reproduction

  1. Dual monitor setup with the game running on a monitor that is not at X origin 0,0
    (here: primary DP-1 at +2560+0), KDE Plasma Wayland session
  2. Set Proton 10.0 or newer for Titan Quest II
  3. Launch the game — in the menus the mouse works normally
  4. Start or continue a game
  5. In gameplay, move the mouse and click: no reaction. Keyboard still works
  6. Switch to Proton 9.0-4f and repeat — the mouse works in gameplay
Ddaveemu 2026-08-12 github

Correction to my log analysis above, plus new measurements.

Correction. The user clip rect / setting real clip traces I highlighted are Proton-specific:
ValveSoftware/wine branch proton_9.0 calls fs_hack_rect_user_to_real() in
grab_clipping_window, while branch proton_10.0 has no fs_hack code in
dlls/winex11.drv/mouse.c at all, matching Wine upstream. Their absence under 11.0 is therefore
expected and not evidence of a skipped code path. Both versions call grab_clipping_window exactly
once — my "3 vs 1" was one call with three traces. That comparison does not localize anything;
please disregard it.

New measurements, Proton 11.0-1b, during gameplay:

  • X pointer sampled every 0.3s for 10s while moving the mouse: 32 distinct positions out of 33
    samples, all 33 inside the game monitor's area. The pointer is not stuck or confined to a wrong
    rect.
  • The pointer is over the game window, and that window holds both X input focus and active-window
    status. Geometry correct (2560,0 3440x1440).
  • WINEDEBUG=+msg, short gameplay session: 761 WM_MOUSEMOVE, 21 WM_LBUTTONDOWN, 21
    WM_LBUTTONUP, 4 WM_RBUTTONDOWN    , all 807 of them retrieved by the game for one and the same
    window handle.

Measured in both versions (9.0-4f and 11.0-1b):

  • WM_INPUT: 0, and no RegisterRawInputDevices — the game does not use raw input, it uses the
    normal cursor path.
  • WM_ACTIVATE, WM_ACTIVATEAPP, WM_KILLFOCUS, WM_SETFOCUS: 0 — no activation is lost.
  • FocusIn / FocusOut: 0 — no X focus changes during the session either.

So the input chain is intact all the way into the game's message loop, and behaves the same as
on 9.0-4f. Cursor clipping, pointer confinement, window focus and message delivery can all be ruled
out as the cause.

The only structural difference I found in the +msg logs is WM_WINE_WINDOW_STATE_CHANGED
(0x8000000a): 135 occurrences under 11.0-1b, none under 9.0-4f. I don't know whether that message
exists in Wine 9 at all, so I can't say whether this is meaningful or simply a message that was
introduced later.

I can't narrow this down further without knowledge of Wine internals. The reproduction is stable if
someone wants to bisect: Proton 9.0-4f works, everything from 10.0 onwards does not.

Still not tested on an X11 session.

Proton versions

Launch options

Launch lines

Error codes