Steam install: Flathub package com.valvesoftware.Steam (the behaviour described is a capture-path issue, not packaging-specific, but noting it for completeness)
Proton: GE-Proton 11-6 (same behaviour expected with any Proton that honours PROTON_ENABLE_WAYLAND)
Clients: Steam Link on iPhone 16 (iOS) and on Google Chromecast HD (Android 14)
Please describe your issue in as much detail as possible:
Summary: when a Proton game runs as a native Wayland window (PROTON_ENABLE_WAYLAND=1), Remote Play streams a black frame for the whole game session (audio and input keep working). The exact same game streams correctly when it runs under Xwayland (PROTON_ENABLE_WAYLAND=0). The logs show why: the "Game Vulkan NV12" capture path (overlay-based) never engages for the Wayland-native window, so Remote Play falls back to X11 window capture, which cannot read a Wayland-native surface and ends in Desktop Black Frame / k_ECaptureFailedReasonPipewireRequired.
This is closely related to #8020 (Steam overlay has no Wayland support), but the visible consequence for Remote Play users is a silent black stream with no hint that the overlay is the missing piece, so I think it is worth tracking on the Remote Play side too. #13336 shows a similar symptom on Hyprland.
Steam is launched without-pipewire (with it, KDE hosts hit #13348).
Steps for reproducing this issue:
Plasma Wayland session, Steam started normally (no -pipewire).
Game with PROTON_ENABLE_WAYLAND=1 (here: DRAGON QUEST MONSTERS: The Dark Prince, app 2175540, GE-Proton 11-6).
Connect a Steam Link client, launch the game from Big Picture.
Client shows black video; audio and controller input work. Big Picture itself streams fine before the game starts.
Same game with PROTON_ENABLE_WAYLAND=0 → streams correctly via Game Vulkan NV12.
Logs — failing case (native Wayland game), streaming_log.txt
09:45:17 Streaming started to iPhone at 192.168.x.x:62990, audio channels = 2, MTU = 1468
09:45:17 >>> Starting desktop stream
09:45:17 WARNING: Desktop capture unavailable, try running Steam with -pipewire
09:45:17 >>> Capture method set to Desktop OpenGL NV12 + VAAPI H264 <- Big Picture, OK
09:45:39 (game launched)
09:45:40 Window title set to steam_app_2175540
09:45:40 Changing record window: 0x4a00001 (77594625)
09:45:40 CDesktopCaptureX11GL: Couldn't make context current
09:45:40 CDesktopCaptureX11: Couldn't get window image <- repeated ~60x/s for the whole session
09:45:40 >>> Capture method set to Desktop Black Frame + VAAPI H264
09:46:14 Unable to capture video: k_ECaptureFailedReasonPipewireRequired
09:46:14 Steam needs to be restarted with -pipewire as a parameter in order to be able to capture video. ...
09:46:14 CLIENT: Got control packet k_EStreamControlCaptureFailed
No Switching video stream ... to GameOverlay_MovieStream_<pid> line ever appears in this session: the overlay capture never attaches to the Wayland-native game window.
Logs — working case (same game, PROTON_ENABLE_WAYLAND=0), same host, Chromecast HD client
10:52:40 Window title set to DRAGON QUEST MONSTERS : Le Prince des ombres
10:52:40 Changing record window: 0x6000001 (100663297)
10:52:40 >>> Stopped desktop stream
10:52:40 >>> Switching video stream from Desktop_MovieStream to GameOverlay_MovieStream_6526
10:52:40 CGameStreamVideoStageVAAPI: Reinitializing 1920x804 at 30000 Kbit/s and 59.84 FPS with quality 1
10:52:40 >>> Capture method set to Game Vulkan NV12 + VAAPI HEVC <- game visible on the client
Expected behaviour
Either the overlay/Vulkan capture works for Wayland-native game windows, or Remote Play detects that the target window is Wayland-native and reports it (instead of PipewireRequired, which is misleading here since -pipewire has its own problems on KDE, see #13348).
Workaround in use
A small compatibility-tool wrapper that exports PROTON_ENABLE_WAYLAND=0 only when a Remote Play session is active (detected by the UDP socket bound on port 27031, which only exists during a session), so local play keeps native Wayland + HDR and remote play gets a capturable Xwayland window. Works reliably (3/3 launches captured via Game Vulkan NV12), but it is obviously a hack around the missing Wayland overlay.
Twice in two days the client exited with src/common/pipes.cpp (900) : Fatal assert; application exiting right when the streamed game was terminated from the client; crash IDs posted on #13276.
Your system information
streaming_log.txt/remote_connections.txtavailable on request)com.valvesoftware.Steam(the behaviour described is a capture-path issue, not packaging-specific, but noting it for completeness)PROTON_ENABLE_WAYLAND)Please describe your issue in as much detail as possible:
Summary: when a Proton game runs as a native Wayland window (
PROTON_ENABLE_WAYLAND=1), Remote Play streams a black frame for the whole game session (audio and input keep working). The exact same game streams correctly when it runs under Xwayland (PROTON_ENABLE_WAYLAND=0). The logs show why: the "Game Vulkan NV12" capture path (overlay-based) never engages for the Wayland-native window, so Remote Play falls back to X11 window capture, which cannot read a Wayland-native surface and ends inDesktop Black Frame/k_ECaptureFailedReasonPipewireRequired.This is closely related to #8020 (Steam overlay has no Wayland support), but the visible consequence for Remote Play users is a silent black stream with no hint that the overlay is the missing piece, so I think it is worth tracking on the Remote Play side too. #13336 shows a similar symptom on Hyprland.
Steam is launched without
-pipewire(with it, KDE hosts hit #13348).Steps for reproducing this issue:
-pipewire).PROTON_ENABLE_WAYLAND=1(here: DRAGON QUEST MONSTERS: The Dark Prince, app 2175540, GE-Proton 11-6).PROTON_ENABLE_WAYLAND=0→ streams correctly viaGame Vulkan NV12.Logs — failing case (native Wayland game),
streaming_log.txtNo
Switching video stream ... to GameOverlay_MovieStream_<pid>line ever appears in this session: the overlay capture never attaches to the Wayland-native game window.Logs — working case (same game,
PROTON_ENABLE_WAYLAND=0), same host, Chromecast HD clientExpected behaviour
Either the overlay/Vulkan capture works for Wayland-native game windows, or Remote Play detects that the target window is Wayland-native and reports it (instead of
PipewireRequired, which is misleading here since-pipewirehas its own problems on KDE, see #13348).Workaround in use
A small compatibility-tool wrapper that exports
PROTON_ENABLE_WAYLAND=0only when a Remote Play session is active (detected by the UDP socket bound on port 27031, which only exists during a session), so local play keeps native Wayland + HDR and remote play gets a capturable Xwayland window. Works reliably (3/3 launches captured viaGame Vulkan NV12), but it is obviously a hack around the missing Wayland overlay.Side note (separate crash, reported on #13276)
Twice in two days the client exited with
src/common/pipes.cpp (900) : Fatal assert; application exitingright when the streamed game was terminated from the client; crash IDs posted on #13276.