https://bugs.kde.org/show_bug.cgi?id=518139
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from [email protected] --- I have a 100% reproducible variant of this and detailed Wine x11drv traces that I think pin down where the protocol breaks. Adding here rather than opening a duplicate, since this looks like the same KWin Xwayland fullscreen path as the original report just with a different surface symptom — always a black screen on restore, never the spurious minimize on Alt+Tab. Environment - Plasma 6.6.5 / KWin Wayland - Debian Sid (kernel 7.0.7+deb14-amd64) - Proton Experimental `experimental-bleeding-edge-11.0-364676`. Also reproduces on Proton 9, 10, 11 beta. - DXVK 2.7.1-594, AMD Radeon RX 7900 XT / RADV NAVI31, mesa 26.0.6 - Natural Selection 2 (Steam appid 4920) in fullscreen-windowed (borderless) at 3840×2160 Reproduction (100% reliable) 1. Launch NS2, start a local listen server on any map, then `map ns2_veil` from the console. 2. As soon as the loading screen appears, Alt+Tab. 3. After a few seconds, click NS2 in the taskbar to restore. 4. Window returns at the correct geometry but renders fully black. Audio and networking continue, the engine's `log.txt` keeps being written, the process has ~120 healthy threads. Game has to be killed. Why it's 100% here vs the original "small chance": NS2's render thread is blocked on map streaming during the Alt+Tab, so it can't process whatever residual event might otherwise paper over the protocol gap shown below. Protocol-level evidence Captured with `WINEDEBUG=+seh,+focus,+message,+win,+x11drv` from a Steam-launched Proton run. Line numbers reference the same `~/steam-4920.log`. Minimize half — works correctly: ``` 153129 X11DRV_WindowPosChanging hwnd 0x10096 rects { window (-32000,-32000)-(-31840,-31969) ... } 153168 window_set_wm_state window 0x10096/6000003, requesting WM_STATE 0x1 -> 0x3 serial 690 153305 set_net_active_window requesting _NET_ACTIVE_WINDOW 0x10020/35a serial 287 154267 handle_state_change WM_STATE 0x3/697, expected 0x3/690 # KWin confirms IconicState ``` Wine generates `WM_SIZE wp=SIZE_MINIMIZED` and `WM_ACTIVATEAPP wp=FALSE` for the engine. Engine correctly pauses rendering. Restore half — protocol gap: ``` 192408 handle_state_change unexpected _NET_ACTIVE_WINDOW 0x10096/6000003 serial 101 time 653845 192409 handle_state_change unexpected _NET_ACTIVE_WINDOW 0x10096/6000003 serial 292 time 653845 192410 handle_state_change unexpected _NET_ACTIVE_WINDOW 0x10096/6000003 serial 104 time 653845 ... (continues across 9 Wine threads, all "unexpected") ... ``` KWin sets `_NET_ACTIVE_WINDOW` to the NS2 window (0x10096), but there is **no `WM_STATE` change back to NormalState** between the iconic confirmation at line 154267 and the active-window notifications at 192408+. winex11.drv's state tracker therefore still has the window in IconicState, never synthesises `WM_SIZE wp=SIZE_RESTORED` or `WM_ACTIVATEAPP wp=TRUE`, and never moves the window back from `(-32000,-32000)`. The Win32-side ends up in an inconsistent "active but iconic" state. No restore message ever reaches the engine, so its render loop stays paused — hence the black screen with audio/network alive. ICCCM 4.1.2.4 expects the WM to update `WM_STATE` on iconic↔normal transitions. The missing `WM_STATE → NormalState` on restore is what wedges Wine's tracking. Workaround that confirms the layer Wrapping the game in `gamescope -W 3840 -H 2160 -f -- gamemoderun mangohud %command%` eliminates it completely. With the same `WINEDEBUG` enabled, the matched log shows **zero** `unexpected _NET_ACTIVE_WINDOW` events across multiple Alt+Tab/restore cycles, and the engine renders normally. gamescope owns the host Wayland surface, so KWin's restore handshake operates on gamescope (which handles it cleanly) rather than on NS2's inner Xwayland window. That isolates the issue to the KWin ↔ Xwayland ↔ winex11.drv path on restore from iconic — not Wine internals, not DXVK, not the GPU driver, and not the engine itself. I have full traces from a failing run (~19 MB) plus matched clean runs under `gamescope -f` and `gamescope -b`. Happy to attach the relevant chunks if it helps triage — let me know what's useful. Quick note: reproduction, log capture, and verification of the gamescope workaround were all done on my system. Log analysis and the write-up were done with Claude Opus assistance. Line numbers and excerpts above are from the actual captured log. -- You are receiving this mail because: You are watching all bug changes.
