ValveSoftware / gamescope

SteamOS session compositing window manager

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Steam Games Hang Without Opening with Nested GameScope using `--backend`

sonic2kk opened this issue · comments

Using GameScope built from commit 09cb7b4.

When trying to launch a Steam game with gamescope --backend [any_backend] -- %command%, they don't open. This happens when specifying any backend. Games will launch if just using gamescope -- %command%. Without specifying one, GameScope will prefer the Wayland backend I believe, but even gamescope --backend wayland -- %command% does not work and results in this hanging behaviour.

I initally thought this issue was specific to specifying --backend sdl, but while writing up this issue, I realised it was not specific to any backend, and only to providing the --backend option altogether.

The Steam "Play" button changes to "STOP" as though the game is loading, but the window never appears. Using gamescope --backend [any_backend] -- foobar with any other process I can find appears to work.

When launching Steam from the terminal and examining the output of a Steam game trying to use GameScope, the following gets output but there is no continuous logging, which may suggest nothing else is happening. This log includes force-stopping the game from Steam.

This log is from gamescope --backend sdl -- %command%.

wlserver: [backend/headless/backend.c:67] Creating headless backend
vulkan: supported DRM formats for sampling usage:
vulkan:   AR24 (0x34325241)
vulkan:   XR24 (0x34325258)
vulkan:   AB24 (0x34324241)
vulkan:   XB24 (0x34324258)
vulkan:   RG16 (0x36314752)
vulkan:   NV12 (0x3231564E)
vulkan:   AB4H (0x48344241)
vulkan:   XB4H (0x48344258)
vulkan:   AB48 (0x38344241)
vulkan:   XB48 (0x38344258)
vulkan:   AB30 (0x30334241)
vulkan:   XB30 (0x30334258)
vulkan:   AR30 (0x30335241)
vulkan:   XR30 (0x30335258)
vulkan: Creating Gamescope nested swapchain with format 64 and colorspace 0
wlserver: Using explicit sync when available
wlserver: Running compositor on wayland display 'gamescope-0'
wlserver: [backend/headless/backend.c:17] Starting headless backend
wlserver: Successfully initialized libei for input emulation!
wlserver: [xwayland/sockets.c:64] Failed to bind socket @/tmp/.X11-unix/X0: Address already in use
wlserver: [xwayland/server.c:107] Starting Xwayland on :2
ERROR: ld.so: object '/home/emma/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Adding process 25705 for gameID 583090
ERROR: ld.so: object '/home/emma/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/emma/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x62d9aa805c90 (res 0x62d9aa80c950)
wlserver: [xwayland/server.c:272] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 84
vblank: Using timerfd.
Adding process 25718 for gameID 583090
vulkan: Creating Gamescope nested swapchain with format 64 and colorspace 0
pipewire: renegotiating stream params (size: 1920x1080)
gamescope: children shut down!
terminate called without an active exception
(EE) failed to read Wayland events: Broken pipe

@sonic2kk
If you're up to building from a fork of gamescope, try building from my branch: gs-fix-wlserver-wlr-virtual_keyboard_device_nullptr_assert_fail_latest_upstream from my fork: https://github.com/sharkautarch/gamescope

Very strange, I tried out your branch and it worked. To confirm, I went back to upstream GameScope master, and it worked prefectly fine now. Both your branch and upstream master now work with and without --backend sdl / --backend wayland.

I will close this issue, it seems to have gone away. I guess it wasn't related to GameScope after all somehow.

I spoke too soon somewhat, it appears this issue happens intermittently with only one game in particular (SeaBed).

I tested some other games after restarting Steam with your branch and upstream, and SeaBed intermittently fails with both.

I spoke too soon somewhat, it appears this issue happens intermittently with only one game in particular (SeaBed).

I tested some other games after restarting Steam with your branch and upstream, and SeaBed intermittently fails with both.

HMM interesting
maybe try compiling with thread sanitizer:

LD_PRELOAD=/usr/lib/libtsan.so CC=gcc CXX=g++ meson setup --reconfigure --wipe build -Db_ndebug=false --buildtype=debugoptimized -Db_lto=true -Dc_args="-Wno-error=stringop-overflow -Wno-error=calloc-transposed-args -Wno-error=unused-but-set-variable -Wno-error=unused-variable -fsanitize=undefined -fsanitize=thread -fsanitize-recover=all -fno-omit-frame-pointer" -Dc_link_args="-Wno-error=stringop-overflow -Wno-error=calloc-transposed-args -Wno-error=unused-but-set-variable -Wno-error=unused-variable -fsanitize=undefined -fsanitize=thread -fsanitize-recover=all -fno-omit-frame-pointer" -Dcpp_args="-Wno-error=stringop-overflow -Wno-error=calloc-transposed-args -Wno-error=unused-but-set-variable -fno-omit-frame-pointer -Wno-error=unused-variable -fsanitize=undefined -fsanitize=thread -fsanitize-recover=all" -Dcpp_link_args="-Wno-error=calloc-transposed-args -Wno-error=unused-but-set-variable -Wno-error=stringop-overflow -fno-omit-frame-pointer -Wno-error=unused-variable -fsanitize=undefined -fsanitize=thread -fsanitize-recover=all"

and then to run:
first set this sysctl thingy to avoid this issue: https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels
sudo sysctl vm.mmap_rnd_bits=30

then run like this:
LD_PRELOAD=/usr/lib/libtsan.so TSAN_OPTIONS="halt_on_error=false detect_leaks=false" path/to/gamescope <otherparams>

Even --backend auto?