Full logs [...] available on request
I'm not a Steam Client developer, but I predict that they are unlikely to be able to diagnose or solve this problem without logs, so please provide the information that was requested in the issue template.
Separately, and possibly related to the same family of container-bootstrap bugs: the pressure-vessel sandbox intermittently fails to capture 10_nvidia.json (host symlink into /var/run/nvidia/configs/, possibly not resolved by the capture logic) and never captures egl_external_platform.d for GBM at all — the fix in [#485](https://github.com/ValveSoftware/steam-for-linux/issues/485) (2022) appears to have only covered the Wayland external platform.
Please report this part as a separate issue, either here or in ValveSoftware/steam-runtime. Let's reserve this issue number for only the black screen in Big Picture mode that you described in the issue title. Having more than one issue reported in the same issue report is how we get issue reports that can never be closed or properly diagnosed, because their scope is unclear.
When opening the new issue, please include a description of how your host system's Nvidia graphics drivers are arranged - don't assume that Steam or Steam Runtime developers are familiar with distro-specific details of Batocera.
Also please include a detailed log from the container runtime framework, from a run where you have reproduced the problem. If it's intermittent, then a log from a failed/problematic run is the most important, but a separate log from a successful run would also be interesting for comparison.
If it is the steamrt3c runtime that you are having trouble with, the usual STEAM_LINUX_RUNTIME_LOG/STEAM_LINUX_RUNTIME_VERBOSE will not work, but instead you can use:
SRT_LOG=debug flatpak run com.valvesoftware.Steam
and find the container runtime's log output in:
~/.var/app/com.valvesoftware.Steam/.steam/steam/logs/webhelper-linux.txt~/.var/app/com.valvesoftware.Steam/.steam/steam/logs/console-linux.txtNote that if you are running the unofficial Flatpak-packaged version of Steam from Flathub, it is usually not expected to use your graphics drivers from the host system (Batocera in your case). Instead, it uses a copy of the Nvidia drivers from a Flatpak extension, usually org.freedesktop.Platform.GL{,32}.nvidia-X-Y-Z for version X.Y.Z of the driver. This means that Batocera-specific quirks of the driver layout on the host system are unlikely to affect Flatpak apps directly.
(An exception is if Batocera has specially configured Flatpak to use a copy of the host Nvidia drivers as an "unmanaged extension" in `/var/lib/flatpak, in which case someone will also need to explain how that's laid out on Batocera.)
Environment: Batocera.linux 43.1, kernel 6.18.16, GTX 1050 Ti / proprietary driver 580.126.09, Steam flatpak 1.0.0.85 (flathub), launched via
-oldbigpictureor via the Big Picture button from the desktop client.Desktop mode works perfectly. Switching to Big Picture produces a permanent black screen, with no error message and no crash. Full live diagnostic performed on the machine (logs, pressure-vessel sandbox inspection, direct window pixmap read via XComposite):
• steamwebhelper and all its subprocesses (zygote, GPU, network, audio) stay alive and healthy the whole time — no crash.
• GL_VENDOR/GL_RENDERER confirm the NVIDIA driver is active throughout — no software fallback.
• The top-level X11 window is correctly created, positioned, focused, and topmost in the stacking order — not a WM/stacking issue.
• Direct read of the window's composite pixmap (manual redirect + XGetImage): every pixel is 0xff000000 — genuinely painted opaque black, not an empty/transparent buffer.
• Internal logs (steamui_html.txt) show the UI's JS loading and running normally, but routed to "ensure desktopui window" instead of "ensure gamepadui window exists" on switch — despite -oldbigpicture being explicitly passed.
Separately, and possibly related to the same family of container-bootstrap bugs: the pressure-vessel sandbox intermittently fails to capture 10_nvidia.json (host symlink into /var/run/nvidia/configs/, possibly not resolved by the capture logic) and never captures egl_external_platform.d for GBM at all — the fix in #485 (2022) appears to have only covered the Wayland external platform.
Happy to test any candidate fix on this setup. Full logs and diagnostic scripts available on request.