Wine-Wayland child viewport/subsurface reparenting freezes after SetParent; X11 works

## Issue type Native Wine-Wayland windowing/rendering issue in GE-Proton. This is filed as **Other** rather than a normal per-game compatibility report because the issue appears to be in the Wine-Wayland child-window / subsurface / embedded viewport path. Gaea 2 is the concrete reproducible application. I searched existing issues for `Gaea`, `Gaea.Viewport`, `winewayland`, `subsurface`, `SetParent`, and related terms, and did not find an existing matching issue. ## Proton version GE-Proton10-34 ## Affected title / reproducer * Application: QuadSpinner Gaea 2 * Version: Gaea 2.3.0.1 * Steam AppID / compatdata AppID: 3501090215 * Runtime: SteamLinuxRuntime_sniper ## System information * Distribution: Arch Linux * Session/compositor: Hyprland / Wayland * GPU: NVIDIA RTX 3070 Laptop GPU * NVIDIA driver: 610.43.02 * Kernel: 6.18.34-1-lts * Full Steam System Information / Steam Runtime Diagnostics gist: `<optional / can provide if needed>` ## Summary Under native Wine-Wayland, Gaea launches its embedded viewport process, `Gaea.Viewport.exe`. Gaea logs that viewport attachment completed, but immediately afterward the application freezes. The same clean prefix and same Gaea install work under X11/XWayland. Under X11/XWayland, the viewport attaches and the application remains responsive. Killing only `Gaea.Viewport.exe` while the native Wayland session is frozen immediately restores the main WPF shell responsiveness. After killing the viewport process, the previously missing shell/welcome content remains visible. This looks like a Wine-Wayland child-window / subsurface / docking issue rather than a font, codec, WPF resource, or general VKD3D problem. ## Launch options Failing native Wine-Wayland run: ```text PROTON_LOG=1 WAYLAND_DEBUG=1 WINEDEBUG=-all,+waylanddrv,+win,+event,+dwmapi PROTON_ENABLE_WAYLAND=1 __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia %command% ``` Working X11/XWayland control run: ```text PROTON_LOG=1 WINEDEBUG=-all,+x11drv,+win,+event,+dwmapi __NV_PRIME_RENDER_OFFLOAD=1 __VK_LAYER_NV_optimus=NVIDIA_only __GLX_VENDOR_LIBRARY_NAME=nvidia %command% ``` The Wine graphics driver was switched between `wayland` and `x11` in the prefix registry for A/B testing. ## Symptoms Native Wine-Wayland: 1. Gaea opens the main shell and welcome window. 2. Some shell/welcome content is initially invisible, but hit-testing still works. 3. `Gaea.Viewport.exe` starts. 4. Gaea logs: `Viewport attachment completed`. 5. The previously missing shell content appears. 6. The application freezes. 7. Killing only `Gaea.Viewport.exe` restores shell responsiveness. X11/XWayland control: 1. Same clean prefix. 2. Same Gaea install. 3. Viewport attaches. 4. Application remains responsive. 5. Content renders. ## Reproduction 1. Use GE-Proton10-34. 2. Use a clean prefix. 3. Enable native Wine-Wayland with `PROTON_ENABLE_WAYLAND=1`. 4. Launch Gaea 2.3.0.1. 5. Wait for `Gaea.Viewport.exe` to start. 6. Observe Gaea log entry: `Viewport attachment completed`. 7. Observe that the application freezes. 8. Run: ```bash pkill -f 'Gaea.Viewport.exe' ``` 9. Observe that the main Gaea shell becomes responsive again. 10. Switch the same prefix to X11/XWayland and launch without `PROTON_ENABLE_WAYLAND=1`. 11. Observe that the viewport attaches and the application remains responsive under X11/XWayland. ## Debugging already performed The following did not fix the native Wine-Wayland freeze: * `PROTON_NO_NTSYNC=1 PROTON_NO_ESYNC=1 PROTON_NO_FSYNC=1` * `VKD3D_CONFIG=single_queue` * `VKD3D_SWAPCHAIN_PRESENT_MODE=IMMEDIATE` * `VKD3D_FRAME_RATE=30` * `VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_id,VK_KHR_present_wait` * `WINEDLLOVERRIDES=openxr_loader,openvr_api=d` * disabling D3D12/D3D12Core * WPF/font/codecs related prefix experiments were reverted before the final A/B comparison. ## Relevant trace finding The attached Wine/Wayland trace suggests the embedded viewport uses a Wayland subsurface and then enters a problematic docking/reconfiguration path. Smallest relevant inline extract: ```text wl_subcompositor.get_subsurface(... wl_surface#46, wl_surface#3) wl_subsurface#50.set_desync() wl_subsurface#50.set_position(...) wl_subsurface#50.place_above(wl_surface#3) wl_surface#3.commit() ``` Later, around the freeze, the same viewport HWND (`0x200d6`) is repeatedly moved/reconfigured and `wayland_surface_reconfigure_client hwnd=0x200d6 subsurface=...` continues to appear. My current interpretation is: ```text Gaea.Viewport.exe creates/uses a Wayland subsurface for the embedded Unity viewport. When Gaea docks/reparents the viewport into the main shell, native Wine-Wayland appears to mishandle the child-window/subsurface relationship. The viewport process remains alive, but the shell freezes while waiting on the viewport. Killing only Gaea.Viewport.exe releases the shell. ``` ## Attachments Two archives: * [wayland-freeze-setparent-subsurface-logs.tar.gz](https://github.com/user-attachments/files/28674058/wayland-freeze-setparent-subsurface-logs.tar.gz) * [x11-control-viewport-attaches-responsive-logs.tar.gz](https://github.com/user-attachments/files/28674059/x11-control-viewport-attaches-responsive-logs.tar.gz) Each archive contains the Proton log, Gaea application log, captured process/window state, and extracted windowing/subsurface traces for that run. The Wayland archive contains the failing native Wine-Wayland run with `PROTON_LOG=1`, `WAYLAND_DEBUG=1`, and focused Wine windowing traces. The X11 archive contains the working X11/XWayland control run with `PROTON_LOG=1` and focused X11/windowing traces. I can provide the uncompressed/full logs separately if needed.