[Bug]: Fullscreen Proton/Wine games always render to the physical monitor, never to the Polaris capture target (headless or virtual)

[mrba11s]

Describe the bug

No matter what capture mode I use, any fullscreen 3D Windows game launched through Proton/Wine renders to my real physical monitor instead of whatever Polaris is actually capturing (headless labwc session, or a Host Virtual Display). Audio, input, framerate limits, and per-app env vars all correctly reach the isolated session — it's specifically the video output that escapes. I've tested this across two completely different games and two completely different Proton/launcher stacks, so I don't think it's a launcher quirk.

Steps to reproduce

Set up an app entry in Polaris pointing at a fullscreen-capable Windows game via Proton (tested with both Faugus and Lutris as launchers — see below).
Launch the app from a Moonlight-compatible client (Nova or Moonlight).
Observe: the game opens and renders on the host's real physical monitor. The client stream shows a black screen (or an empty desktop, depending on capture mode) with no game visible. Audio, however, streams correctly to the client throughout.

This happens consistently regardless of capture mode:

Private Stream (Recommended) — headless labwc, linux_use_cage_compositor = enabled, linux_prefer_gpu_native_capture = disabled (the config recommended in troubleshooting.md under "Headless session does not start cleanly")
Private Stream (GPU Native)
Host Virtual Display (real second xrandr output, e.g. Virtual-virtual-xdp-kde- at 1920x1080+2560+0)
Mirror Desktop

Games/launchers tested (same result both times):

The First Berserker: Khazan, launched via Faugus (Flatpak) → umu-run → Proton (cachyos_11.0_20260702-LinUwUx)
A separate game launched via Lutris (Flatpak, net.lutris.Lutris lutris:rungameid/1), different Proton build entirely

Install method

Arch package

Host OS

CachyOS, KDE Plasma, Wayland

GPU and driver

CPU: Ryzen 9 9800X3D GPU: AMD Radeon RX 9070 XT (RDNA4, gfx1201) Mesa 26.1.5-arch3.1, driver=amdgpu, radv

Client and device

Nova on a Lenovo Legion Y700 Gen 3 (Snapdragon 8 Gen 3) Same result reproduced on a second client (HP ProDesk running Moonlight)

Runtime path

None

Expected behavior

The fullscreen game should render inside whatever session Polaris is capturing (the headless labwc session, or the Host Virtual Display), so it streams correctly to the client — the same way the desktop and windowed-mode apps already do in my testing.

Relevant log output

WAYLAND_DISPLAY and DISPLAY are confirmed correct on the actual game process itself via /proc/<pid>/environ (WAYLAND_DISPLAY=wayland-1, DISPLAY=:2), not just on the launcher wrapper, so the environment is reaching the process correctly:

WAYLAND_DISPLAY=wayland-1
DISPLAY=:2

Polaris log snippet from a headless launch showing correct session setup, correct env injection, and correct capture backend selection, right up until the point the video should appear on the client:

Info: cage: Set WAYLAND_DISPLAY=wayland-1 DISPLAY=:2 for app command
Info: Executing: [/home/andy/khazan_launch.sh] in ["/home/andy"]
...
Info: Using SHM screencopy (preferred for this runtime)
Info: SHM screencopy buffer allocated: 2560x1440 stride=10240 format=875709016
Info: Wayland virtual input: routing supported devices to labwc socket [wayland-1]
Warning: wlr: capture_transport=shm frame_residency=cpu frame_format=bgra8; capture will incur an extra CPU-side copy/conversion path
Info: Client requested cursor visibility change: visible
...
Info: PipeWire stream is now actively streaming audio

Happy to attach a full support bundle if useful.

Screenshots or recordings

No response

Additional context

Wrapped the launch in gamescope --backend wayland to force nesting inside the labwc session. Confirmed via gamescope's own log that it correctly initialized a nested Wayland backend on the intended socket — game still escaped to the physical monitor.
Tested in true headless mode (single output, HEADLESS-1, no second display in the session at all) to rule out any "wrong primary monitor" selection — same result. This rules out the known Proton/Wine bug where fullscreen games attach to whichever display is marked primary (ValveSoftware/Proton#6938), since there's nothing else for it to attach to in a single-output headless session.
Manually forced the game into windowed mode via its own settings, at which point the window became genuinely draggable with no title bar (Alt+drag worked) — I was able to physically drag it onto the Host Virtual Display and switch it to borderless windowed there, and it streamed to the client correctly. This confirms the compositor/capture pipeline itself works fine; it's specifically fullscreen mode that escapes.
Edited the game's GameUserSettings.ini directly (WindowPosX/Y, DefaultMonitorIndex, FullscreenMode=1 for borderless) to try to force it onto the virtual display from launch — had no effect, the game still opened on the physical monitor regardless of these values.
Checked DXVK's documented behavior — by default DXVK disables Vulkan exclusive fullscreen entirely on Linux, so if this is a DX11 title it shouldn't be able to bypass the compositor this way at all, which makes me suspect this may be VKD3D-Proton (DX12) specific behavior instead, though I haven't been able to confirm that further.
Would appreciate knowing if this has been reported with other fullscreen titles, particularly on RDNA4/gfx1201 hardware, and whether there's a known-good reference title/Proton build I could test against to isolate hardware/driver vs. Polaris capture logic vs. Proton itself.

[papi-ux]

I audited this against current master. The evidence currently points to two different routing behaviors, not a capture-backend or VKD3D fullscreen defect:

• Host Virtual Display / Mirror Desktop: these remain inside the host KDE session. WAYLAND_DISPLAY/DISPLAY select a display server, not one KDE output, so fullscreen Wine can be placed on the physical primary while Polaris captures another output. The successful windowed drag confirms the selected output itself can be captured.
• Private labwc: a client genuinely attached to private labwc/Xwayland cannot switch to KDE merely by entering fullscreen. The plausible path is Flatpak launcher/singleton delegation or namespace socket aliasing. /proc/<pid>/environ names alone do not prove which Unix socket/inode the actual game uses.

Before changing launch/capture code, please attach a support bundle plus the game PID parent chain, cgroup and mount-namespace IDs, and endpoint identity for the actual game process (Wayland socket inode/path or proof the X11 window exists under private :2). An A/B after fully terminating Faugus/Lutris desktop instances, and an A/B with a direct non-singleton runner, would be especially useful. For Mirror Desktop, please include the exact connector Polaris selected and the connector where the game appears.

I am keeping this open as needs endpoint-provenance evidence rather than landing a speculative Proton workaround.

[mrba11s]

Thanks for the detailed reply. I (hopefully) went through everything you asked for. Summary up front and results below. Let me know if I can help further & thanks so much for creating Polaris!

Summary

I could not find any evidence of Flatpak singleton delegation. The game process (whether launched via Faugus or completely bypassing Faugus/Flatpak) never opens a Wayland connection or an X11 connection to any display at all — private :2 or otherwise. libwayland-client.so is loaded in memory, but zero sockets to a compositor exist in its fd table. Every socket it holds is IPC to wineserver. It does have direct handles to /dev/dri/renderD128 and renderD129 open throughout. This reproduces identically whether launched through Faugus's Flatpak wrapper or via a completely bare umu-run invocation with no Flatpak involvement at all.

Environment note

I'm currently on 1.3.2. I hit two separate regressions while gathering this evidence, noted at the bottom, since I wasn't able to complete Step 7 as a result of one of them.

---

1 & 2. Game PID and parent chain

Real game process, isolated from the Faugus/umu-run/Proton scaffolding above it in the tree:

27431 S:\Games\AC Black Flag Resynced\ACBlackFlag.exe

Full chain (pstree -p -s 27431) traces cleanly through: umu-run → steam-runtime-launch-client → bwrap/pv-adverb → umu-shim → proton → srt-launcher-service → wine-preloader → wine (running a steam.exe shim) → the real exe. Nothing unexpected in the chain itself.

3. cgroup and namespace IDs

	cgroup	mount ns	pid ns	net ns
Game (27431)	app-flatpak-io.github.Faugus.faugus‑launcher-486124083.scope	4026533913	4026533906	4026531833
Polaris (1755)	polaris.service	4026531832	4026531836	4026531833
labwc-polaris (26911)	polaris.service	4026531832	(matches Polaris)	(matches Polaris)

The game sits in its own mount/pid namespace via the Flatpak sandbox, separate from Polaris and its own private labwc instance, which share the plain host namespace. Expected for a Flatpak-launched process on its own — not itself proof of anything, which is why I moved to the socket-level check next.

4. Actual Wayland socket / endpoint identity

$ sudo lsof -p 27431 2>/dev/null | grep -i wayland
ACBlackFl 27431 andy mem REG 0,36 75424 1032473 /run/parent/usr/lib/x86_64-linux-gnu/libwayland-client.so.0.24.0

$ sudo lsof -p 27431 2>/dev/null | grep -i "socket\|\.X11"
(no output)

$ sudo ss -xp | grep 27431

All u_str ESTAB entries returned pair ACBlackFlag.exe with wineserver (pid=27333) only. No compositor socket anywhere in the list.

So: the Wayland client library is loaded, but no Wayland connection is ever opened, and no X11 connection is opened either.

5. X11 window under private :2

$ DISPLAY=:2 xwininfo -root -tree
xwininfo: Window id: 0x350 (the root window) (has no name)
  Root window id: 0x350 (the root window) (has no name)
  Parent window id: 0x0 (none)
     5 children:
     0x200005 (has no name): ()  1x1+-100+-100  +-100+-100
     0x200004 "wlroots wm": ()  10x10+0+0  +0+0
     0x200003 (has no name): ()  8192x8192+0+0  +0+0
     0x200002 (has no name): ()  10x10+0+0  +0+0
     0x200001 (has no name): ()  10x10+0+0  +0+0

All five children are XWayland/wlroots internal helper windows. No game window present under :2 at all.

6. A/B with a direct non-singleton runner

Killed the Faugus Flatpak instance entirely first (flatpak kill io.github.Faugus.faugus-launcher), then launched completely outside Flatpak:

WAYLAND_DISPLAY=wayland-1 GAMEID=umu-default PROTONPATH=cachyos_11.0_20260702-LinUwUx \
  ~/.var/app/io.github.Faugus.faugus-launcher/data/faugus-launcher/umu-run \
  "/run/media/andy/M2/Games/AC Black Flag Resynced/ACBlackFlag.exe"

New game PID 33560, parented under srt-bwrap directly (no Flatpak sandbox scope this time — confirmed no app-flatpak cgroup path for this run).

$ sudo lsof -p 33560 2>/dev/null | grep -i wayland
ACBlackFl 33560 andy mem REG 0,36 64248 1145172 /run/host/usr/lib/libwayland-client.so.0.25.0

$ sudo ss -xp | grep 33560

Identical pattern: library loaded, zero compositor sockets, all u_str connections to wineserver (pid=33403) only.

This is the part I think matters most — the behavior reproduces exactly the same with Faugus/Flatpak completely out of the picture, which is why I don't think this is singleton/Flatpak delegation. It looks like the game process just never negotiates a windowing-system connection at all, for either display.

7. Mirror Desktop connector info

Wasn't able to complete this one — see regression note below. Happy to circle back on it once the config-save issue is fixed, or if there's a way to set the display mode directly via file/API that bypasses the web UI, I'm glad to try that instead.

---

Two separate issues hit along the way on 1.3.2 (not the main bug, flagging for visibility)

Config save regression: Changing an app's stream/display mode via the web UI now fails:

Failed to save configuration: {"error":"Unsupported config key: stream_path_id","status":false,"status_code":400}

This blocked switching back to Mirror Desktop to complete Step 7, and also blocked re-testing other capture-path variants generally. Happy to open this as its own issue if useful — didn't want to conflate it with this thread.

HEVC encoder profile failure (non-blocking, auto-recovered): On the same 1.3.2 install, HEVC 10-bit/SDR sessions throw:

[hevc_vaapi @ ...] No usable encoding profile found.
Could not open codec [hevc_vaapi]: Function not implemented

vainfo confirms VAProfileHEVCMain10: VAEntrypointEncSlice is genuinely available on this driver stack (Mesa 26.1.5, RX 9070 XT), so this doesn't look like a real hardware gap. Polaris's own fallback logic handled it gracefully and landed on AV1 successfully, so this isn't blocking anything — just flagging in case it's useful.

Related community reports (possibly relevant context)

Two threads that might be adjacent to this, both on RDNA4/AMD:

• Discussion #167 — linux_prefer_gpu_native_capture = enabled crashes Polaris outright on a different RX 9070 XT setup, same as the labwc: Exited before creating a Wayland socket (exited with status 1) crash I hit earlier in this thread.
• Discussion #78 — different root cause (NVIDIA DMA-BUF GL import failure), but same overall shape: headless capture produces a black client stream while audio/input work fine, and Desktop/Mirror mode is confirmed as a working fallback. Matches what I've found here too.

Let me know what else would help — happy to keep digging on this.

polaris-anonymized-diagnostics-2026-07-30T19-46-44.398Z.json

[papi-ux]

Polaris v1.3.3 is now available: https://github.com/papi-ux/polaris/releases/tag/v1.3.3

This release fixes the response-only configuration round-trip that caused:

Unsupported config key: stream_path_id

Please upgrade from v1.3.2 and first confirm that changing the stream/display mode now saves successfully.

For the main fullscreen-routing issue, the direct umu-run A/B makes Flatpak/Faugus singleton delegation unlikely, but inspecting only ACBlackFlag.exe does not yet identify the Wine process that owns presentation. Direct render-node handles also prove rendering access, not which compositor/output receives presentation.

Could you please collect one matched v1.3.3 retest with:

1. Mirror Desktop: the exact connector Polaris selects and the connector where the game visibly appears.
2. Private Stream: the full Wine-prefix process set, including wineserver, Wine display-driver/helper processes, the real game executable, and any XWayland clients.
3. Socket ownership by inode/peer across that process set, rather than filtering ss/lsof only by the game PID.
4. DISPLAY=:2 xwininfo -root -tree from the same private-session run.
5. The matching anonymized Polaris support bundle and exact game/Proton/runner versions.

A same-session Mirror Desktop versus Private Stream comparison will distinguish host-KDE fullscreen placement from a Wine-prefix process attaching—or failing to attach—to the private display endpoint.

The HEVC Main10 failure is separate because Polaris recovered to AV1. If it still occurs on v1.3.3, please open a focused issue with the matching encoder log and vainfo output so it can be tracked without mixing it into this routing investigation.

[mrba11s]

Confirmed v1.3.3 first (Step 0), then went through your five points. Found what looks like the actual root cause this time

Root cause found: DISPLAY is not being set to the private session, only WAYLAND_DISPLAY is

$ sudo cat /proc/22487/environ | tr '\0' '\n' | grep -E "^DISPLAY=|^WAYLAND_DISPLAY="
WAYLAND_DISPLAY=wayland-1
DISPLAY=:1

WAYLAND_DISPLAY=wayland-1 is correct (matches the private labwc session, as it always has in every test I've run). But DISPLAY=:1 is my real host KDE session's X11 display — not :2, which is what your own Polaris logs consistently report as the private session's XWayland (labwc: XWayland display ready — :2).

Traced this at the socket level and confirmed it's a live, real connection, not a failed one:

$ ps -p 1236 -o pid,ppid,cmd
   1236    1093 /usr/bin/Xwayland :1 -auth /run/user/1000/xauth_ynOOTR -listenfd 8 -listenfd 9 -displayf...

$ ps -p 21966 -o pid,ppid,cmd
  21966   19509 labwc -C /home/andy/.config/labwc-polaris -s bash -c 'for i in $(seq 1 50); do wlr-randr...

$ echo $DISPLAY
:1

Xwayland :1 (pid 1236) is parented by 1093, which is kwin_wayland — my real host desktop's compositor. labwc (pid 21966, the private session) is a completely separate process tree, parented by 19509.

So: Polaris correctly exports WAYLAND_DISPLAY for the private session at launch, but DISPLAY isn't being overridden to match — it's inheriting the host's :1 from the surrounding environment instead. Since Wine's X11 driver is the default (not winewayland.drv) unless explicitly configured otherwise, and a lot of the Proton/DXVK stack still routes window/input management through XWayland even on nominally-Wayland hosts, it follows DISPLAY and lands on my real desktop's X11 server, completely bypassing the isolated :2 instance — despite WAYLAND_DISPLAY being perfectly correct throughout.

This also explains why last time I found no Wayland or X11 socket at all on the game process — I only checked whether it connected to the correct display, not what it was actually connected to. It was connected the whole time, just to :1 instead of :2.

---

0. Confirmed the stream_path_id fix

Changing an app's stream/display mode now saves cleanly on v1.3.3, no error. Confirmed before doing anything else below.

1. Mirror Desktop: connector

$ kscreen-doctor -o
Output: 1 DP-1 ... enabled connected ... Geometry: 0,0 2560x1440

Only one output exists in Mirror Desktop mode — DP-1. Polaris captures DP-1, and the game visibly renders to DP-1. Same connector, as expected for a non-isolated mode.

2. Private Stream: full Wine-prefix process set

Game launched normally (Faugus → umu-run → Proton, same as every previous test). Real game PID 22487. Alongside it, identified the full Wine helper set:

andy  22389  ... wineserver
andy  22393  ... C:\windows\system32\services.exe
andy  22396  ... C:\windows\system32\winedevice.exe
andy  22406  ... C:\windows\system32\plugplay.exe
andy  22412  ... C:\windows\system32\svchost.exe -k LocalServiceNetworkRestricted
andy  22419  ... C:\windows\system32\winedevice.exe
andy  22439  ... C:\windows\system32\explorer.exe /desktop
andy  22466  ... C:\windows\system32\rpcss.exe
andy  22487  ... S:\Games\AC Black Flag Resynced\ACBlackFlag.exe

3. Socket ownership by inode/peer across the full process set

Took a full unfiltered snapshot (sudo ss -xp) rather than filtering to one PID, then cross-referenced inodes across every process in the list above, plus a blanket search for any Wayland/X11 reference in the whole table.

explorer.exe (22439) and wineserver (22389) only talk to each other and themselves — no compositor connection from either.

The actual connection is owned by wineserver (22389) via a socket shared with ACBlackFlag.exe (22487, fd 230) — inode 124301, peer inode 137884. That peer inode (137884) is bound to @/tmp/.X11-unix/X1 and held by Xwayland, pid=1236 (fd 62). That's the connection identified above as the host's real XWayland, not the private session's.

4. X11 window check under private :2

$ DISPLAY=:2 xwininfo -root -tree
xwininfo: Window id: 0x350 (the root window) (has no name)
  Root window id: 0x350 (the root window) (has no name)
  Parent window id: 0x0 (none)
     5 children:
     0x200005 (has no name): ()  1x1+-100+-100  +-100+-100
     0x200004 "wlroots wm": ()  10x10+0+0  +0+0
     0x200003 (has no name): ()  8192x8192+0+0  +0+0
     0x200002 (has no name): ()  10x10+0+0  +0+0
     0x200001 (has no name): ()  10x10+0+0  +0+0

Same as before — only wlroots/XWayland infrastructure windows, no game window under :2. Consistent with Step 3: the game was never going to appear here, since its actual connection is to :1.

5. Support bundle + versions

Anonymized support bundle attached, exported while this session was live (streaming: true).

• Polaris: 1.3.3
• Proton/runner: cachyos_11.0_20260702-LinUwUx
• umu-launcher: 1.4.4 (unchanged since last report)
• Game: AC Black Flag Resynced (same build as previous report)

---

Given WAYLAND_DISPLAY is set correctly but DISPLAY isn't, would it make sense for Polaris to also export DISPLAY=:2 (matching whatever XWayland display the private labwc/cage session actually creates) at launch, alongside WAYLAND_DISPLAY? Happy to test a build with that change if useful.

polaris-anonymized-diagnostics-2026-08-01T04-12-35.925Z.json