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:

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:

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:

pkill -f 'Gaea.Viewport.exe'

1. Observe that the main Gaea shell becomes responsive again.
2. Switch the same prefix to X11/XWayland and launch without PROTON_ENABLE_WAYLAND=1.
3. 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:

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:

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

• 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.