Compatibility Report

Regression: works correctly on Proton 11.0 (proton-11.0-2c-x86_64), hangs on Proton
Experimental (experimental-11.0-20260917b-x86_64). Same machine, same game, same prefix,
same settings — only the compatibility tool changed.

• Name of the game with compatibility issues: STEEL GULLET Demo
• Steam AppID of the game: 5164020

System Information

• GPU: NVIDIA GeForce RTX 4070
• Video driver version: nvidia 615.71.09 (open kernel module)
• Kernel version: 7.2.7-200.fc44.x86_64 (Fedora 44, X11 / KDE Plasma)
• Link to full system information report as Gist: https://gist.github.com/Lyko5/e3e7de5c97abc974cb8ea9930131af34

• Proton version: Proton Experimental experimental-11.0-20260917b-x86_64 (wine-11.0) — BROKEN
  • Also tested: Proton 11.0 proton-11.0-2c-x86_64 — WORKS, no hang

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

Right-click-drag to pan the camera hard-locks the game, 100% of the time, within a minute of
starting the tutorial. The process stays alive — audio keeps playing — but the window renders
nothing and accepts no input. The desktop stays fully responsive; only the game is wedged.

wineserver enters an infinite loop in get_hardware_message and never returns, so the game's
main thread blocks forever in NtUserGetMessage waiting for a reply that never comes.

Mouse-wheel zoom works fine. Only the action that captures/clips the cursor triggers it.

Reproduces identically on kernel 7.2.6 and 7.2.7 (rebooted between, same result), so it is not
specific to a kernel or ntsync version.

Switching the compatibility tool to Proton 11.0 (proton-11.0-2c-x86_64) resolves it. The same
right-click-pan that hangs Experimental within ~60s plays normally. Soaked for 6.5 minutes of
continuous play including repeated camera panning with no hang, against a ~60-70s time-to-hang on
Experimental. Throughout, wineserver stayed idle in epoll_pwait2 at ~4% CPU (17s of CPU time
total) rather than spinning at 53-87% and climbing. Nothing else changed: same prefix, machine,
monitors, kernel and window mode.

Game main thread — blocked waiting on wineserver

#3 readv
#4 read
#5 read_reply_data
#6 server_call_unlocked
#7 wine_server_call
#8 peek_message
#9 NtUserGetMessage
#10 __wine_syscall_dispatcher

All 46 other threads in the process are parked in futex_do_wait / ntsync_schedule. Nothing is
deadlocked inside the game itself.

wineserver — spinning, single-threaded, burning a core

State: R (running) %CPU: 53% -> 87%, climbing steadily across samples

#0 get_hardware_message <-- never returns
#1 req_get_message
#2 call_req_handler
#3 thread_poll_event
#4 main_loop_epoll
#5 main_loop

wineserver is not blocked — it is looping, and never sends the reply.

Monitor layout ruled out

Originally suspected a multi-monitor cause (three displays, two rotated portrait, primary inset
240px, leaving uncovered regions in the virtual screen). Tested and disproved. With the two
side monitors disabled and a single 2560x1440+0+0 display active — no rotation, no offset, no
uncovered regions — the hang still reproduced every time.

This reproduces on a completely ordinary single-monitor setup.

Possibly related prior art in the same area of the server, offered only as context: wine-devel
patch "server: Improve handling of cursor position clipping for empty rectangle", and
ValveSoftware/wine#24 (fullscreen clips the mouse to the wrong monitor).

A second hang mode, possibly the same bug

Roughly one launch in four hangs during startup instead, before the main menu renders (the
game's own log stops right after Vulkan init at 836 bytes, versus 5,984 for a healthy run). In that
case the main thread is stuck slightly deeper in the same path:

NtUserPeekMessage -> peek_message -> window_from_point -> send_message
-> send_message_timeout -> process_message -> call_window_proc
-> NtUserGetProp -> wine_server_call -> read_reply_data [BLOCKED]

Same subsystem (mouse hit-test inside the message pump), same wineserver round-trip that never
returns. Not proven to be the same root cause, but noted in case it helps.

Ruled out

• Not a GPU or driver fault. No Xid, no GPU reset, no coredump. Kernel journal is completely
  empty across every freeze window and the Xorg log is untouched. GPU sits at 53C / 27% while frozen.
• Not a crash. Process alive and healthy; only the render/input path stalls.
• Not shader compilation stutter. These are permanent hangs, not hitches.
• Not the Steam overlay. Disabling the in-game overlay for this title does not help.
• Not the D3D translation layers. The game renders in native Vulkan 1.4.351 (Godot 4
  Forward+) — DXVK and vkd3d are never loaded.

Reproduction

1. Launch STEEL GULLET Demo (AppID 5164020) under Proton Experimental, windowed.
   Single 2560x1440 display is sufficient — no multi-monitor setup required.
2. Enter the tutorial.
3. Hold right mouse button and drag to pan the camera.
4. Permanent freeze. Audio continues, desktop stays responsive, only the game is wedged.

Mouse-wheel zoom beforehand does not trigger it. Reproducible on demand in under a minute.

The game is a free demo, so this can be reproduced at no cost by anyone with a Steam account.

Engine: Godot 4.8.dev6.mono, Vulkan 1.4.351 Forward+. ntsync is in use (/dev/ntsync present).

Scope of testing: hang reproduced many times on experimental-11.0-20260917b (both freeze
modes). Not reproducible on proton-11.0-2c. Proton Hotfix (hotfix-20260828-ptr) is installed
but untested — happy to test it, or any intermediate Experimental build, to narrow the regression
window.

Stacks captured live with eu-stack against the frozen process while still wedged
(ptrace_scope=0). Happy to provide full thread dumps, repeated wineserver samples, or test patches.