Bringing streamed game to foreground failed on manjaro i3 streaming host on nvidia gpu

steamopen StreamingDistro Family: Arch

ValveSoftware/steam-for-linux#12057 · opened 2025-05-30 by komali2 · updated 2026-09-28 · 3 comments · github

Kkomali2 2025-05-30 github

Your system information

=========================== SYSTEM INFORMATION ===========================
OS: Manjaro Linux 25.0.3 (Zetar)
Kernel: Linux 6.12.28-1-MANJARO #1 SMP PREEMPT_DYNAMIC (x86_64)
Window Manager: i3 version 4.24
Compositor: picom v12.5 (revision a456d43)

=========================== HARDWARE INFORMATION =========================
CPU: 12th Gen Intel(R) Core(TM) i7-12700K
     - 12 Cores, 20 Threads (1 Socket)
RAM: 31GB Total
GPU: NVIDIA GeForce RTX 3080 Lite Hash Rate (10GB VRAM)

=========================== GRAPHICS INFORMATION =========================
NVIDIA Driver Version: 570.144
CUDA Version: 12.8 (V12.8.93)
OpenGL: Version 4.6.0 NVIDIA 570.144
OpenGL Renderer: NVIDIA GeForce RTX 3080/PCIe/SSE2
OpenGL Vendor: NVIDIA Corporation

=========================== DISPLAY INFORMATION ==========================
Primary Display: HDMI-0 connected 3840x2160 (4K) (697mm x 392mm)
Secondary Display: DP-0 connected 3840x2160 (4K) (600mm x 340mm)
Multi-monitor setup: 2x 4K displays side by side

Steam Beta Branch:  Stable Client
Steam Version:  1747701111
Steam Client Build Date:  Tue, May 20 3:51 AM UTC +08:00
Steam Web Build Date:  Tue, May 20 8:21 AM UTC +08:00
Steam API Version:  SteamClient022

Steam client version (build number or date):
Distribution (e.g. Ubuntu): Manjaro
Opted into Steam client beta?: [Yes/No] No
Have you checked for system updates?: [Yes/No] Yes
Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]

steam-logs.tar.gz

GPU: Nvidia 3080

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

Steps for reproducing this issue:

Launch steam on host machine
On paired steam deck on network, select a game such as Baldur's Gate 3, and select "Stream from [host pc])
Observe black screen on steam deck with in-game custom cursor and hear game's audio through steam deck
Observe game running correctly on host machine's display
Try changing in game settings from full screen, to windowed, to full screen windowed
Observe continued black screen on steam deck
Try moving mouse to another monitor and back
Observe stream crash
Observe line in logs: Bringing streamed game to foreground - failed with timestamp from before crash

In all experiments, I try launching the game, confirm the audio, then on the host machine try shift tab and shift tab again to show/hide the steam overlay, then on the host pc in the game settings try changing from fullscreen, to windowed, to borderless windowed, and then moving the screen around until the stream crashes.

Note, in further testing this is consistent behavior only in Baldur's Gate 3. Other games work much more consistently.

Stream logs:

detect-client-leader = true;
unredir-if-possible = false;
host use nvfbc: false
host enable hardware encoding: true
host change desktop resolution to match streaming client: false
i3:
# focus_follows_mouse yes
# focus_on_window_activation focus

https://pastebin.com/3pyvfCaP

detect-client-leader = false;
unredir-if-possible = false;
host use nvfbc: false
host enable hardware encoding: true
host change desktop resolution to match streaming client: false
i3:
# focus_follows_mouse yes
# focus_on_window_activation focus

https://pastebin.com/qkSM3uiq

detect-client-leader = false;
unredir-if-possible = false;
host use nvfbc: false
host enable hardware encoding: true
host change desktop resolution to match streaming client: true
i3:
# focus_follows_mouse yes
# focus_on_window_activation focus

https://pastebin.com/nfKN7Ahp

detect-client-leader = false;
unredir-if-possible = false;
host use nvfbc: false
host enable hardware encoding: false
host change desktop resolution to match streaming client: true
i3:
# focus_follows_mouse yes
# focus_on_window_activation focus

https://pastebin.com/uMjjEjJn

detect-client-leader = false;
unredir-if-possible = false;
host use nvfbc: false
host enable hardware encoding: false
host change desktop resolution to match streaming client: true
i3:
focus_follows_mouse yes
focus_on_window_activation focus

https://pastebin.com/zfCQGYuQ

TTehGingerDev 2026-09-26 github

Same Bringing streamed game to foreground - failed on NVIDIA, reproduced on KDE Plasma Wayland (not just X11/i3), streaming to a Steam Frame. Details, plus the related EGL 0x3001 / dmabuf failure in the desktop-capture fallback, in #13650.

TTehGingerDev 2026-09-26 github

Consolidating here per the duplicate closure of #13650. Same failure on a different setup, with two additional findings.

Setup: Arch Linux, kernel 7.2.2, KDE Plasma 6.7.4 Wayland (Steam under XWayland), NVIDIA RTX 3090 on nvidia-open 610.57.04. Steam client 1790121765 (beta) started with -pipewire. Streaming client is a Steam Frame in theater/flat mode.

1. Game capture never engages, the same as this report but on Wayland rather than X11/i3. Reproduced with Easy Red 2 (1324780), both as the native Linux build (OpenGL) and under Proton with DirectX 11 and with Vulkan:

Bringing streamed game to foreground - failed
>>> Starting desktop stream

2. The desktop-capture fallback cannot use dmabuf on NVIDIA and copies every frame on the CPU:

CDesktopCapturePipeWire: Couldn't initialize EGL: 0x3001
CDesktopCapturePipeWire: PipeWire stream format changed (size: 1920x1080, format 8, stride 7680, size 8294400, dmabuf: 0)
>>> Capture method set to Desktop PipeWire NV12 + NVENC H264 [CPU]

The capture stage alone costs 11-17 ms on this host (Setting target framerate: ... capture 16.67 ...). When game capture does engage on the same host, for a Proton/DXVK title (Game Vulkan NV12 + NVENC H264), capture is ~0 ms. So the foreground failure pushes every stream onto this slow path.

3. One attempt went through SteamVR's theater path instead (VR OpenGL NV12 + NVENC H264 [CPU]) and the Frame's decoder rejected it (CV4L2Accel: Resetting because decoded frame ID has failed). The headset was in power-saver mode during these tests, which may have contributed on the client side. The host-side findings above are independent of that.

An AMD RX 9070 XT is going into this host in the next few days. I'll post whether the foreground failure and the EGL/dmabuf failure persist on AMD, which should separate the NVIDIA-specific part from the Wayland part.

TTehGingerDev 2026-09-28 github

Follow-up from my earlier comment: I retested on the same host after swapping the display GPU to an AMD RX 9070 XT (Mesa 26.2.2 / RADV, amdgpu). The RTX 3090 stays in the machine for CUDA only, with no displays attached. Everything else is unchanged: KDE Plasma 6.7.4 Wayland, Steam 1790121765 (beta) with -pipewire, Steam Frame in theater mode, headset in its normal power mode this time, Easy Red 2 (1324780).

Results on AMD

The foreground failure still happens, but only briefly. It's logged once at launch, Steam starts a desktop stream, and then game capture takes over about 9 seconds later:
```
14:28:27 Streamed game has created a window
14:28:27 Bringing streamed game to foreground - failed
14:28:27 >>> Starting desktop stream
14:28:36 >>> Capture method set to Game Vulkan NV12 + NVENC H264 [CPU]
```
On NVIDIA, game capture never engaged, and the whole session ran on desktop capture. So the foreground failure itself looks Wayland/KWin-wide, but on this setup Steam now recovers from it.
The EGL/dmabuf failure is NVIDIA-specific. Couldn't initialize EGL didn't appear once on AMD, and the PipeWire desktop capture now negotiates dmabuf:
```
CDesktopCapturePipeWire: PipeWire stream format changed (size: 1920x1080, format 8, stride 7680, size 8294400, dmabuf: 1)
```
On NVIDIA it was always Couldn't initialize EGL: 0x3001 followed by dmabuf: 0.
Subjectively, the stream went from very high latency to quick and smooth, and it launched with no manual steps.

Still present on the client side: in the first second after launch, the Frame logs decoder errors before settling:

CLIENT: CV4L2Accel: Resetting because decoded frame ID has failed
CLIENT: CV4L2Accel -> F Couldn't queue capture buffer 5 -> 0/0 / FD:119: Invalid argument

They stop once the stream is running.

Summary: the latency problem in my earlier comment was mostly the NVIDIA EGL/dmabuf failure, which forced a CPU copy on every desktop-capture frame. The Bringing streamed game to foreground - failed bug reported here still reproduces on AMD under KDE Wayland, but with working dmabuf capture it's now a brief startup delay rather than a broken session.

Nothing extracted yet.