Games open in an invisible window since 3.14.3 when using FSR

[zany130]

when I run Steam inside Gamescope (still nested under KDE in order to work around https://github.com/ValveSoftware/gamescope/issues/1180)

any game I launch launches in an invisible window

this is ever since updating to the latest tag release https://github.com/ValveSoftware/gamescope/releases/tag/3.14.3

I have tried the following games:

a hat in time

Persona 3 Reload

Trails into reverie

Yooka-Layle (native linux game)

gamescope also seems to crash when trying to open the steam overlay or alt tab

EDIT:removing FSR from the gamescop arguments fixes the issue

possibly related to https://github.com/ValveSoftware/gamescope/issues/1111 even though it was fixed for me for a while (ie: works on 3.14.2 https://github.com/ValveSoftware/gamescope/issues/1005) ( I always use fsr when using gamescope)

Gamescope output

``` gamescope -w 2560 -h 1440 -W 3840 -H 2160 -r 120 -o 30 -f -e -F fsr -S auto --fsr-sharpness 2 --immediate-flips --adaptive-sync --rt -- steam-runtime No CAP_SYS_NICE, falling back to regular-priority compute and threads. Performance will be affected. ATTENTION: default value of option vk_khr_present_wait overridden by environment. ATTENTION: default value of option vk_khr_present_wait overridden by environment. vulkan: selecting physical device 'AMD Radeon RX 6700 XT (RADV NAVI22)': queue family 1 (general queue family 0) vulkan: physical device supports DRM format modifiers wlserver: [backend/headless/backend.c:67] Creating headless backend xdg_backend: Seat name: 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) wlserver: Running compositor on wayland display 'gamescope-0' wlserver: [backend/headless/backend.c:17] Starting headless backend wlserver: [xwayland/server.c:107] Starting Xwayland on :1 wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da5716f3ea0 (res 0x5da5716f3500) wlserver: [xwayland/server.c:272] Xserver is ready pipewire: stream state changed: connecting pipewire: stream state changed: paused pipewire: stream available on node ID: 79 xwm: Embedded, no cursor set. Using left_ptr by default. vblank: Using timerfd. xdg_backend: PreferredMetadata: Red: 0.64 0.33, Green: 0.3 0.6, Blue: 0.15 0.06, White: 0.3127 0.329, Max Luminance: 100 nits, Min Luminance: 0 nits, Max Full Frame Luminance: 100 nits josh edid: Patching res 800x1280 -> 2560x1440 pipewire: renegotiating stream params (size: 3839x2158) steam.sh[122713]: Running Steam on garuda Soaring 64-bit steam.sh[122713]: STEAM_RUNTIME is enabled automatically setup.sh[122783]: Steam runtime environment up-to-date! steam.sh[122713]: Steam client's requirements are satisfied tid(122839) burning pthread_key_t == 0 so we never use it [2024-04-11 17:00:35] Startup - updater built Mar 6 2024 20:27:25 [2024-04-11 17:00:35] Startup - Steam Client launched with: '/home/zany130/.local/share/Steam/ubuntu12_32/steam' minidumps folder is set to /tmp/dumps 04/11 17:00:35 Init: Installing breakpad exception handler for appid(steam)/version(1709846872)/tid(122839) [2024-04-11 17:00:35] Loading cached metrics from disk (/home/zany130/.local/share/Steam/package/steam_client_metrics.bin) [2024-04-11 17:00:35] Using the following download hosts for Public, Realm steamglobal [2024-04-11 17:00:35] 1. https://client-update.akamai.steamstatic.com, /, Realm 'steamglobal', weight was 1000, source = 'update_hosts_cached.vdf' [2024-04-11 17:00:35] 2. https://cdn.cloudflare.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'update_hosts_cached.vdf' [2024-04-11 17:00:35] 3. https://cdn.steamstatic.com, /client/, Realm 'steamglobal', weight was 1, source = 'baked in' [2024-04-11 17:00:35] Verifying installation... [2024-04-11 17:00:35] Verification complete wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da571499b30 (res 0x5da5716f6200) xwm: got the same buffer committed twice, ignoring. The XKEYBOARD keymap compiler (xkbcomp) reports: > Warning: Unsupported maximum keycode 708, clipping. > X11 cannot support keycodes above 255. > Warning: Could not resolve keysym XF86KbdInputAssistPrevgrou > Warning: Could not resolve keysym XF86KbdInputAssistNextgrou Errors from xkbcomp are not fatal to the X server pipewire: renegotiating stream params (size: 3839x2156) xwm: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 332 UpdateUI: showing logo Steam logging initialized: directory: /home/zany130/.local/share/Steam/logs XRRGetOutputInfo Workaround: initialized with override: 1 real: 0xda177dc0 XRRGetCrtcInfo Workaround: initialized with override: 1 real: 0xda176500 steamwebhelper.sh[123150]: === Thu Apr 11 05:00:38 PM EDT 2024 === steamwebhelper.sh[123150]: Starting steamwebhelper under bootstrap sniper steam runtime at /home/zany130/.local/share/Steam/ubuntu12_64/steam-runtime-sniper CAppInfoCacheReadFromDiskThread took 64 milliseconds to initialize Steam Runtime Launch Service: starting steam-runtime-launcher-service Steam Runtime Launch Service: steam-runtime-launcher-service is running pid 123365 bus_name=com.steampowered.PressureVessel.LaunchAlongsideSteam pipewire: renegotiating stream params (size: 1745x980) pipewire: renegotiating stream params (size: 3839x2158) ATTENTION: default value of option vk_khr_present_wait overridden by environment. ATTENTION: default value of option vk_khr_present_wait overridden by environment. [Gamescope WSI] Forcing on VK_EXT_swapchain_maintenance1. ATTENTION: default value of option vk_khr_present_wait overridden by environment. ATTENTION: default value of option vk_khr_present_wait overridden by environment. /usr/share/themes/Sweet-Dark/gtk-2.0/main.rc:727: error: unexpected identifier 'direction', expected character '}' /usr/share/themes/Sweet-Dark/gtk-2.0/apps/chrome.rc:50: error: invalid string constant "button", expected valid string constant /usr/share/themes/Sweet-Dark/gtk-2.0/apps/xfce.rc:79: error: invalid string constant "entry", expected valid string constant wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da571811c00 (res 0x5da5716489c0) xwm: Unhandled NET_WM_STATE property change: _NET_WM_STATE_MAXIMIZED_VERT xwm: Unhandled NET_WM_STATE property change: _NET_WM_STATE_MAXIMIZED_HORZ pipewire: renegotiating stream params (size: 3839x2156) BRefreshApplicationsInLibrary 1: 19ms CDesktopCapturePipeWire: Opening DRM render node /dev/dri/renderD128 CDesktopCapturePipeWire: setting stream node ID: 79 BuildCompleteAppOverviewChange: 514 apps RegisterForAppOverview 1: 22ms RegisterForAppOverview 2: 22ms /bin/sh\0-c\0/home/zany130/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=360830 -- /home/zany130/.local/share/Steam/ubuntu12_32/steam-launch-wrapper -- '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee.x86_64'\0 chdir "/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee" ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored. ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object '/home/zany130/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. Found path: /mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee.x86_64 Mono path[0] = '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee_Data/Managed' Mono path[1] = '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee_Data/Mono' Mono config path = '/mnt/GAMES/SteamLibrary/steamapps/common/YookaLaylee/YookaLaylee_Data/Mono/etc' displaymanager : xrandr version warning. 1.6 displaymanager : trying .X11-unix client :0 has 1 screens displaymanager screen (0): 13695 x 3949 client :1 has 1 screens displaymanager screen (1): 2560 x 1440 Using libudev for joystick management Importing game controller configs Found /dev/input/event256 Mapping raw axis 0 to 0 Mapping raw axis 1 to 1 Mapping raw axis 2 to 2 Mapping raw axis 3 to 3 Mapping raw axis 4 to 4 Mapping raw axis 5 to 5 input-remapper DualSense Wireless Controller forwarded: Mapping b0.0 to b0 input-remapper DualSense Wireless Controller forwarded: Mapping b1.0 to b1 input-remapper DualSense Wireless Controller forwarded: Mapping b8.0 to b6 input-remapper DualSense Wireless Controller forwarded: Mapping h0.4 to a7 input-remapper DualSense Wireless Controller forwarded: Mapping h0.8 to a6 input-remapper DualSense Wireless Controller forwarded: Mapping h0.2 to a6 input-remapper DualSense Wireless Controller forwarded: Mapping h0.1 to a7 input-remapper DualSense Wireless Controller forwarded: Mapping b10.0 to b8 input-remapper DualSense Wireless Controller forwarded: Mapping b4.0 to b4 input-remapper DualSense Wireless Controller forwarded: Mapping b11.0 to b9 input-remapper DualSense Wireless Controller forwarded: Mapping a2.0 to a2 input-remapper DualSense Wireless Controller forwarded: Mapping a0.0 to a0 input-remapper DualSense Wireless Controller forwarded: Mapping a1.0 to a1 input-remapper DualSense Wireless Controller forwarded: Mapping b5.0 to b5 input-remapper DualSense Wireless Controller forwarded: Mapping b12.0 to b10 input-remapper DualSense Wireless Controller forwarded: Mapping a5.0 to a5 input-remapper DualSense Wireless Controller forwarded: Mapping a3.0 to a3 input-remapper DualSense Wireless Controller forwarded: Mapping a4.0 to a4 input-remapper DualSense Wireless Controller forwarded: Mapping b9.0 to b7 input-remapper DualSense Wireless Controller forwarded: Mapping b3.0 to b2 input-remapper DualSense Wireless Controller forwarded: Mapping b2.0 to b3 Unknown mapping for 'platform': skipping Assigning joystick 1 Found /dev/input/event26 Mapping raw axis 0 to 0 Mapping raw axis 1 to 1 Mapping raw axis 2 to 2 Mapping raw axis 3 to 3 Mapping raw axis 4 to 4 Mapping raw axis 5 to 5 DualSense Wireless Controller: Mapping b0.0 to b0 DualSense Wireless Controller: Mapping b1.0 to b1 DualSense Wireless Controller: Mapping b8.0 to b6 DualSense Wireless Controller: Mapping h0.4 to a7 DualSense Wireless Controller: Mapping h0.8 to a6 DualSense Wireless Controller: Mapping h0.2 to a6 DualSense Wireless Controller: Mapping h0.1 to a7 DualSense Wireless Controller: Mapping b10.0 to b8 DualSense Wireless Controller: Mapping b4.0 to b4 DualSense Wireless Controller: Mapping b11.0 to b9 DualSense Wireless Controller: Mapping a2.0 to a2 DualSense Wireless Controller: Mapping a0.0 to a0 DualSense Wireless Controller: Mapping a1.0 to a1 DualSense Wireless Controller: Mapping b5.0 to b5 DualSense Wireless Controller: Mapping b12.0 to b10 DualSense Wireless Controller: Mapping a5.0 to a5 DualSense Wireless Controller: Mapping a3.0 to a3 DualSense Wireless Controller: Mapping a4.0 to a4 DualSense Wireless Controller: Mapping b9.0 to b7 DualSense Wireless Controller: Mapping b3.0 to b2 DualSense Wireless Controller: Mapping b2.0 to b3 Unknown mapping for 'platform': skipping Assigning joystick 2 wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da57181e590 (res 0x5da5716ae860) xwm: got the same buffer committed twice, ignoring. wlserver: [types/wlr_compositor.c:771] New wlr_surface 0x5da57181ebe0 (res 0x5da5716aa340) xwm: got the same buffer committed twice, ignoring. gamescope: ../gamescope/src/wayland_backend.cpp:688: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed. fish: Job 1, 'gamescope -w 2560 -h 1440 -W 38…' terminated by signal SIGABRT (Abort) (EE) failed to write to Xwayland fd: Broken pipe ```

this is on the latest steam stable also happens on latest game scope git

inxi -b
System:
  Host: Garuda-Linux Kernel: 6.8.5-1-cachyos arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.0.3 Distro: Garuda Linux
Machine:
  Type: Desktop Mobo: ASRock model: X470 Taichi serial: <superuser required>
    UEFI: American Megatrends v: P5.10 date: 10/20/2022
CPU:
  Info: 6-core AMD Ryzen 5 5600X [MT MCP] speed (MHz): avg: 3831
    min/max: 550/4687
Graphics:
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
    driver: amdgpu v: kernel
  Display: wayland server: X.org v: 1.21.1.12 with: Xwayland v: 23.2.6
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu resolution:
    1: 2048x864 2: 1396x785 3: 1536x864
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.4-arch1.2
    renderer: AMD Radeon RX 6700 XT (radeonsi navi22 LLVM 17.0.6 DRM 3.57
    6.8.5-1-cachyos)
Network:
  Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi
  Device-2: Intel I211 Gigabit Network driver: igb
Drives:
  Local Storage: total: 3.64 TiB used: 4.13 TiB (113.6%)
Info:
  Memory: total: 32 GiB available: 31.26 GiB used: 20.94 GiB (67.0%)
  Processes: 612 Uptime: 11m Shell: fish inxi: 3.3.33

[sharkautarch]

void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed.

assertion failure in your output log

@zany130 do you get that assertion failure only when trying to use FSR w/ gamescope? tho there could be a chance that the assert is only triggered after you manually close the game/gamescope after seeing its window is invisible? Double check that that assertion fail actually occurs before you close the game/gamescope yourself

[zany130]

That happened when I was trying to open the Steam overlay. So I ran the game, heard the game responding to my input, but didn't see the game. Then I tried to open the Steam overlay, and it crashed.

I'll try to see if it still happens without FSR it may be a separate issue

EDIT: nope only happens when using FSR

Updated the OP to clarify I am still running nested under kde

[sharkautarch]

That happened when I was trying to open the Steam overlay. So I ran the game, heard the game responding to my input, but didn't see the game. Then I tried to open the Steam overlay, and it crashed.

I'll try to see if it still happens without FSR it may be a separate issue

EDIT: nope only happens when using FSR

that assert fail could be a clue then, or it is due to an unrelated bug... I looked through a bit of the wayland_backend.cpp code, and I have one thought as to the source of at least the assert fail

@Joshua-Ashton m_bCompositorAcquired in wayland_backend.cpp might need to be an atomic, since OnCompositorRelease() is called inside Wayland_Buffer_Release(), which is attached to a wayland event listener thingy (CWaylandFb::s_BufferListener) Correct me if it turns out that CWaylandFb::s_BufferListener is always called from the same thread as the ones that OnCompositorRelease() and OnCompositorAcquire() are called on

technically, IncRef() and DecRef() do use atomic inc/dec, and strong atomic ops can sometimes act as barriers around non-atomic ops, but with what I see in OnCompositorRelease() and OnCompositorAcquire(), imo it still wouldn't be safe for m_bCompositorAcquired to be non-atomic Tho you could probably get away with just using acquire/release atomic ordering for m_bCompositorAcquired

[KyunLFA]

Hi. I am tripping this assertion and another one upon closing the app gamescope is running. I bisected the offending commits.

The assertion (1) being tripped here started with https://github.com/ValveSoftware/gamescope/commit/aec2fd279be1edeb6249c7c31306861740cdc098 . The other one (2) which happens on closing is: src/backend.cpp:60: virtual gamescope::CBaseBackendFb::~CBaseBackendFb(): Assertion '!HasLiveReferences()' failed. . It started from https://github.com/ValveSoftware/gamescope/commit/b93b576e2d7ee69ea3112fb16b25c1c68b6f1086 . These only happen in nested mode. Couldn't reproduce on embedded mode. The assertions (and crashes) happen very often but sometimes takes a bit to trip.

Backtrace of assertion 1:

#0  0x00007fc1066a053b in pthread_kill () at /usr/lib/libc.so.6
#1  0x00007fc106642048 in raise () at /usr/lib/libc.so.6
#2  0x00007fc106624478 in abort () at /usr/lib/libc.so.6
#3  0x00007fc10662439c in ??? () at /usr/lib/libc.so.6
#4  0x00007fc106637e26 in __assert_fail () at /usr/lib/libc.so.6
#5  0x00005ca687a0ac82 in gamescope::CWaylandFb::OnCompositorRelease (this=0x7fc0c42002c0) at ../src/wayland_backend.cpp:688
#6  0x00005ca687a0ad36 in gamescope::CWaylandFb::Wayland_Buffer_Release (this=0x7fc0c42002c0, pBuffer=0x7fc0c4200240) at ../src/wayland_backend.cpp:702
#7  0x00005ca687a12969 in gamescope::CWaylandFb::$_9::operator()<wl_buffer*> (this=0x7fc0ecfff1a7, pData=0x7fc0c42002c0, args=0x7fc0c4200240)
    at ../src/wayland_backend.cpp:316
#8  0x00005ca687a096fe in gamescope::CWaylandFb::$_9::__invoke<wl_buffer*> (pData=0x7fc0c42002c0, args=0x7fc0c4200240) at ../src/wayland_backend.cpp:316
#9  0x00007fc106d4b2fe in ??? () at /usr/lib/libffi.so.8
#10 0x00007fc106d47264 in ??? () at /usr/lib/libffi.so.8
#11 0x00007fc106d4a74e in ffi_call () at /usr/lib/libffi.so.8
#12 0x00007fc107670620 in ??? () at /usr/lib/libwayland-client.so.0
#13 0x00007fc107670faf in ??? () at /usr/lib/libwayland-client.so.0
#14 0x00007fc1076712bc in wl_display_dispatch_queue_pending () at /usr/lib/libwayland-client.so.0
#15 0x00005ca687a0e897 in gamescope::CWaylandBackend::PollState (this=0x5ca6bf3bd2f0) at ../src/wayland_backend.cpp:1422
#16 0x00005ca68792c49d in steamcompmgr_main (argc=3, argv=0x7ffd6d631958) at ../src/steamcompmgr.cpp:7610
#17 0x00005ca68798ef5f in steamCompMgrThreadRun (argc=3, argv=0x7ffd6d631958) at ../src/main.cpp:933
#18 0x00005ca68798fd3a in std::__invoke_impl<void, void (*)(int, char**), int, char**>
    (__f=@0x5ca6bf5a7ea8: 0x5ca68798ef30 <steamCompMgrThreadRun(int, char**)>, __args=@0x5ca6bf5a7ea0: 3, __args=@0x5ca6bf5a7e98: 0x7ffd6d631958)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:61
#19 0x00005ca68798fca5 in std::__invoke<void (*)(int, char**), int, char**>
    (__fn=@0x5ca6bf5a7ea8: 0x5ca68798ef30 <steamCompMgrThreadRun(int, char**)>, __args=@0x5ca6bf5a7ea0: 3, __args=@0x5ca6bf5a7e98: 0x7ffd6d631958)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:96
#20 0x00005ca68798fc73 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul> (this=0x5ca6bf5a7e98)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:292
#21 0x00005ca68798fc25 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::operator() (this=0x5ca6bf5a7e98)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:299
#22 0x00005ca68798fa79 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> > >::_M_run (this=0x5ca6bf5a7e90)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:244
#23 0x00007fc106af3843 in std::execute_native_thread_routine (__p=0x5ca6bf5a7e90) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#24 0x00007fc10669e55c in ??? () at /usr/lib/libc.so.6
#25 0x00007fc10672b95c in ??? () at /usr/lib/libc.so.6

Backtrace of assertion 2:

#0  0x00007970ffaa053b in pthread_kill () at /usr/lib/libc.so.6
#1  0x00007970ffa42048 in raise () at /usr/lib/libc.so.6
#2  0x00007970ffa24478 in abort () at /usr/lib/libc.so.6
#3  0x00007970ffa2439c in ??? () at /usr/lib/libc.so.6
#4  0x00007970ffa37e26 in __assert_fail () at /usr/lib/libc.so.6
#5  0x0000637dc149f35d in gamescope::CBaseBackendFb::~CBaseBackendFb (this=0x7970bc2002c0, __in_chrg=<optimized out>) at ../src/backend.cpp:60
#6  0x0000637dc14a2956 in gamescope::CWaylandFb::~CWaylandFb (this=0x7970bc2002c0, __in_chrg=<optimized out>) at ../src/wayland_backend.cpp:672
#7  0x0000637dc14b5807 in std::destroy_at<gamescope::CWaylandFb> (__location=0x7970bc2002c0) at /usr/include/c++/13.2.1/bits/stl_construct.h:88
#8  0x0000637dc14b57ec in std::_Destroy<gamescope::CWaylandFb> (__pointer=0x7970bc2002c0) at /usr/include/c++/13.2.1/bits/stl_construct.h:149
#9  0x0000637dc14b5680 in std::allocator_traits<std::allocator<void> >::destroy<gamescope::CWaylandFb> (__p=0x7970bc2002c0)
    at /usr/include/c++/13.2.1/bits/alloc_traits.h:674
#10 std::_Sp_counted_ptr_inplace<gamescope::CWaylandFb, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x7970bc2002b0)
    at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:613
#11 0x0000637dc13faaf7 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7970bc2002b0) at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:346
#12 0x0000637dc13ffff3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x637dec77aac0, __in_chrg=<optimized out>)
    at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:1071
#13 0x0000637dc14ab5b0 in std::__shared_ptr<gamescope::CWaylandFb, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x637dec77aab8, __in_chrg=<optimized out>)
    at /usr/include/c++/13.2.1/bits/shared_ptr_base.h:1524
#14 0x0000637dc14ab5cc in std::shared_ptr<gamescope::CWaylandFb>::~shared_ptr (this=0x637dec77aab8, __in_chrg=<optimized out>)
    at /usr/include/c++/13.2.1/bits/shared_ptr.h:175
#15 0x0000637dc14b53c0 in gamescope::CWaylandBackend::~CWaylandBackend (this=0x637dec77a2f0, __in_chrg=<optimized out>) at ../src/wayland_backend.cpp:446
#16 0x0000637dc14b5478 in gamescope::CWaylandBackend::~CWaylandBackend (this=0x637dec77a2f0, __in_chrg=<optimized out>) at ../src/wayland_backend.cpp:446
#17 0x0000637dc149f259 in gamescope::IBackend::Set (pBackend=0x0) at ../src/backend.cpp:30
#18 0x0000637dc13f14db in steamcompmgr_exit () at ../src/steamcompmgr.cpp:6047
#19 0x0000637dc13f74f0 in steamcompmgr_main (argc=3, argv=0x7fff8a469468) at ../src/steamcompmgr.cpp:7934
#20 0x0000637dc142f272 in steamCompMgrThreadRun (argc=3, argv=0x7fff8a469468) at ../src/main.cpp:933
#21 0x0000637dc142fd09 in std::__invoke_impl<void, void (*)(int, char**), int, char**> (__f=@0x637deca35d28: 0x637dc142f23b <steamCompMgrThreadRun(int, char**)>)
    at /usr/include/c++/13.2.1/bits/invoke.h:61
#22 0x0000637dc142fc4a in std::__invoke<void (*)(int, char**), int, char**> (__fn=@0x637deca35d28: 0x637dc142f23b <steamCompMgrThreadRun(int, char**)>)
    at /usr/include/c++/13.2.1/bits/invoke.h:96
#23 0x0000637dc142fb7d in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul> (this=0x637deca35d18)
    at /usr/include/c++/13.2.1/bits/std_thread.h:292
#24 0x0000637dc142fb1a in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::operator() (this=0x637deca35d18)
    at /usr/include/c++/13.2.1/bits/std_thread.h:299
#25 0x0000637dc142fafe in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> > >::_M_run (this=0x637deca35d10)
    at /usr/include/c++/13.2.1/bits/std_thread.h:244
#26 0x00007970ffef3843 in std::execute_native_thread_routine (__p=0x637deca35d10) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#27 0x00007970ffa9e55c in ??? () at /usr/lib/libc.so.6

(tested on master branch with both Clang 18.1.2 and GCC 13.2.1 with either debug on and off, CachyOS Linux)

[sharkautarch]

@KyunLFA You could try checking for possible data races by building gamescope with thread sanitizer

you'll need to first run this: sudo sysctl vm.mmap_rnd_bits=28 (this is a workaround for this issue: https://stackoverflow.com/questions/77850769/fatal-threadsanitizer-unexpected-memory-mapping-when-running-on-linux-kernels) (also you'll probably need to run this before you try building gamescope w/ tsan, since otherwise the build process will fail upon trying to run a test binary built w/ tsan)

Here's the build command(s) I've used for building w/ clang tsan: (clang's sanitizers are a bit more powerful than gcc's)

TSAN_OPTIONS="symbolize=false malloc_context_size=0 detect_leaks=false check_printf=false detect_deadlocks=false intercept_strstr=false intercept_strspn=false intercept_strpbrk=false intercept_memcmp=false history_size=0 report_destroy_locked=0 report_bugs=0 atexit_sleep_ms=0 io_sync=0" UBSAN_OPTIONS=$TSAN_OPTIONS CXX=clang++ CC=clang meson setup --wipe build -Db_lundef=false -Db_lto_mode=thin -Db_sanitize=thread --buildtype=debugoptimized -Dc_args="-shared-libsan -fsanitize-recover=all -fsanitize=undefined -fsanitize=local-bounds -fno-omit-frame-pointer" -Dc_link_args="-fuse-ld=lld -lm /usr/lib/clang/18/lib/linux/libclang_rt.tsan-x86_64.so -lm /usr/lib/clang/18/lib/linux/libclang_rt.ubsan_standalone-x86_64.so -Wl,-rpath,/usr/lib/clang/18/lib/linux/ -shared-libsan -fsanitize-recover=all -fsanitize=undefined  -fsanitize=local-bounds" -Dcpp_args="-shared-libsan -fsanitize-recover=all -fsanitize=undefined -fsanitize=local-bounds -fno-omit-frame-pointer" -Dcpp_link_args="-fuse-ld=lld -shared-libsan -fsanitize-recover=all -fsanitize=undefined -fsanitize=local-bounds  -fno-omit-frame-pointer -lm /usr/lib/clang/18/lib/linux/libclang_rt.tsan-x86_64.so -lm /usr/lib/clang/18/lib/linux/libclang_rt.ubsan_standalone-x86_64.so -Wl,-rpath,/usr/lib/clang/18/lib/linux/"

TSAN_OPTIONS="symbolize=false malloc_context_size=0 detect_leaks=false check_printf=false detect_deadlocks=false intercept_strstr=false intercept_strspn=false intercept_strpbrk=false intercept_memcmp=false history_size=0 report_destroy_locked=0 report_bugs=0 atexit_sleep_ms=0 io_sync=0" UBSAN_OPTIONS=$TSAN_OPTIONS ninja -C build

and then you can run gamescope like so: TSAN_OPTIONS="atexit_sleep_ms=0 io_sync=0" UBSAN_OPTIONS=$TSAN_OPTIONS gamescope ...

if you get a message complaining about sanitizer library load order, you might need to LD_PRELOAD /usr/lib/clang/18/lib/linux/libclang_rt.tsan-x86_64.so and/or /usr/lib/clang/18/lib/linux/libclang_rt.ubsan_standalone-x86_64.so when running gamescope

[sharkautarch]

for assertion #1, looking at this line of the backtrace:

8 0x00005ca687a096fe in gamescope::CWaylandFb::$_9::__invoke<wl_buffer*> (pData=0x7fc0c42002c0, args=0x7fc0c4200240) at ../src/wayland_backend.cpp:316

that corresponds to CWaylandFb::s_BufferListener which I had just been talking about before

so I might have been onto something afterall... though... maybe the issue isn't simply just that m_bCompositorAcquired isn't atomic, but now that I look at it more, I think there's also another issue with it:

m_bCompositorAcquired is initially set to false in the CWaylandFb::CWaylandFb() constructor, CWaylandFb::s_BufferListener is set up as an event listener using wl_buffer_add_listener(), but m_bCompositorAcquired should probably be getting set to true within the CWaylandFb::CWaylandFb() constructor, which it currently isn't

So I think there's a race condition that's happening in a short window of time, where if pHostBuffer is released during/after CWaylandFb::CWaylandFb() but before IncRef() is run (IncRef() being called from within OnCompositorAcquire()) then Wayland_Buffer_Release() will be run w/ m_bCompositorAcquired=false

Note that the reason why I mention IncRef() is because it does an atomic increment with the default sequentially consistent memory ordering which will make memory writes before said atomic increment visible to other threads But note that in this case, if Wayland_Buffer_Release() runs before IncRef(), we still get a race condition (note: if you are curious about visibility of memory reads, know that on x86_64, memory reads are default visible, but writes are not. tho that is only from the CPU's perspective, not the compiler's)

[sharkautarch]

@zany130 @KyunLFA I made a branch wayland_backend_assert1_fix in my fork here: https://github.com/sharkautarch/gamescope/ Let me know whether or not the branch fixes that first assertion failure

[sharkautarch]

@Joshua-Ashton This may be unrelated to this issue (not sure), but while running scan-build to check the latest git version of gamescope, I found this warning (tho it could always just be a false-positive idk):

../../../src/backend.cpp:78:14: warning: Use of memory after it is freed [cplusplus.NewDelete]
   78 |         if ( m_pClientBuffer && !uRefCount )

I think that the point where said memory is freed (and then the static analyzer complains about the use-after-free) is when RcObject::DecRefPrivate() is called from within RcObject::DecRefPrivate scan-build doesn't give a use-after-free warning if I comment out the DecRefPrivate(); at line 27 in rc.h

At this point, I wonder if it would be simpler to refactor the Rc stuff to just use boost intrusive pointers since I think that does something similar to what the Rc stuff is trying to do... just food for thought (also see: https://baptiste-wicht.com/posts/2011/11/boost-intrusive_ptr.html and see example of use in a real project here: -base class: https://github.com/ceph/ceph/blob/47950f12a30f65c9e4dab3eef9382f77e3b3d82f/src/common/RefCountedObj.h#L81 -implementation: https://github.com/ceph/ceph/blob/main/src/msg/Connection.h#L245)

[KyunLFA]

@zany130 @KyunLFA I made a branch wayland_backend_assert1_fix in my fork here: https://github.com/sharkautarch/gamescope/ Let me know whether or not the branch fixes that first assertion failure

Did not fix it for me. Now getting gamescope: ../src/wayland_backend.cpp:689: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion 'm_bCompositorAcquired.load(std::memory_order_acquire)' failed..

Backtrace again in case anything changed:

#0  0x0000764e320a053b in pthread_kill () at /usr/lib/libc.so.6
#1  0x0000764e32042048 in raise () at /usr/lib/libc.so.6
#2  0x0000764e32024478 in abort () at /usr/lib/libc.so.6
#3  0x0000764e3202439c in ??? () at /usr/lib/libc.so.6
#4  0x0000764e32037e26 in __assert_fail () at /usr/lib/libc.so.6
#5  0x00005fd4c1ad5fa3 in gamescope::CWaylandFb::OnCompositorRelease (this=0x764df0293a30) at ../src/wayland_backend.cpp:689
#6  0x00005fd4c1ad6076 in gamescope::CWaylandFb::Wayland_Buffer_Release (this=0x764df0293a30, pBuffer=0x764df01fb1a0) at ../src/wayland_backend.cpp:703
#7  0x00005fd4c1add0d9 in gamescope::CWaylandFb::$_9::operator()<wl_buffer*> (this=0x764e0fdff1df, pData=0x764df0293a30, args=0x764df01fb1a0)
    at ../src/wayland_backend.cpp:316
#8  0x00005fd4c1ad5161 in gamescope::CWaylandFb::$_9::__invoke<wl_buffer*> (pData=0x764df0293a30, args=0x764df01fb1a0) at ../src/wayland_backend.cpp:316
#9  0x0000764e327012fe in ??? () at /usr/lib/libffi.so.8
#10 0x0000764e326fd264 in ??? () at /usr/lib/libffi.so.8
#11 0x0000764e3270074e in ffi_call () at /usr/lib/libffi.so.8
#12 0x0000764e3305b620 in ??? () at /usr/lib/libwayland-client.so.0
#13 0x0000764e3305bfaf in ??? () at /usr/lib/libwayland-client.so.0
#14 0x0000764e3305c2bc in wl_display_dispatch_queue_pending () at /usr/lib/libwayland-client.so.0
#15 0x00005fd4c1ad977a in gamescope::CWaylandBackend::PollState (this=0x5fd4e6520160) at ../src/wayland_backend.cpp:1423
#16 0x00005fd4c1a0b362 in steamcompmgr_main (argc=2, argv=0x7ffdc029b608) at ../src/steamcompmgr.cpp:7610
#17 0x00005fd4c1a65f2f in steamCompMgrThreadRun (argc=2, argv=0x7ffdc029b608) at ../src/main.cpp:933
#18 0x00005fd4c1a66a9a in std::__invoke_impl<void, void (*)(int, char**), int, char**>
    (__f=@0x5fd4e67aa7a8: 0x5fd4c1a65f00 <steamCompMgrThreadRun(int, char**)>, __args=@0x5fd4e67aa7a0: 2, __args=@0x5fd4e67aa798: 0x7ffdc029b608)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:61
#19 0x00005fd4c1a66a05 in std::__invoke<void (*)(int, char**), int, char**>
    (__fn=@0x5fd4e67aa7a8: 0x5fd4c1a65f00 <steamCompMgrThreadRun(int, char**)>, __args=@0x5fd4e67aa7a0: 2, __args=@0x5fd4e67aa798: 0x7ffdc029b608)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/invoke.h:96
#20 0x00005fd4c1a669d3 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::_M_invoke<0ul, 1ul, 2ul> (this=0x5fd4e67aa798)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:292
#21 0x00005fd4c1a66985 in std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> >::operator() (this=0x5fd4e67aa798)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:299
#22 0x00005fd4c1a66809 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)(int, char**), int, char**> > >::_M_run (this=0x5fd4e67aa790)
    at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/bits/std_thread.h:244
#23 0x0000764e324f3843 in std::execute_native_thread_routine (__p=0x5fd4e67aa790) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#24 0x0000764e3209e55c in ??? () at /usr/lib/libc.so.6
#25 0x0000764e3212b95c in ??? () at /usr/lib/libc.so.6

[misyltoad]

@sharkautarch Definitely opposed to any boost crap, we can just store m_pClientBuffer in DecRef before the base class call.

[misyltoad]

The assertion is because of how composition output buffers are handled fundamentally not working with how Wayland buffer release works. I need to rewrite that code to be smarter and pick images based on which are free.

[sharkautarch]

Definitely opposed to any boost crap

good to know

The assertion is because of how composition output buffers are handled fundamentally not working with how Wayland buffer release works.

Ah I see

I need to rewrite that code to be smarter and pick images based on which are free.

Well good luck, that sounds like a bit of a pain...

[DJXJD]

I'm experiencing something similar on my end. As of 3.14.3 (downgrading to 3.14.2 fixes the issue), launching with FSR causes the window to show up not quite invisible, but extremely transparent and over-saturated. Toggling off FSR with super + u brings things back to normal, but then toggling on any other form of up-scaling via keyboard shortcut makes the window appear to be frozen. Toggling off that up-scaling again brings things back to normal, but also shows that the window was still interact-able while appearing frozen.

For reference, I'm on arch, with hyprland 0.38.1-1

[sharkautarch]

Ah, it looks like Joshua Ashton has fixed the use-after-free bug that I had found w/ scan-build. Though unfortunately it’ll still take him some time to fix the assert issue I’m sure he’ll figure it out, he’s a good dev :)

[Cryolitia]

I'm trying to start waydroid in gamescope, and meet the same fault.

gamescope: ../src/wayland_backend.cpp:688: void gamescope::CWaylandFb::OnCompositorRelease(): Assertion `m_bCompositorAcquired' failed.

录屏 2024-04-22 13-31-56.webm

[misyltoad]

You can comment out that assertion for now, but you might get visual glitching

[zany130]

So, update on this issue. I tried the latest commit and FSR still shows a blank image. I'm guessing that just needs to be fixed but the really interesting thing is that it sorta works with nis... except an old copy of the screen is overlayed on top...

trying to see how I can upload a screen shot here it comes out to big for github (prob because its 4k)

EDIT:

So the "bottom" image is correct and responds to input while the top "overlayed image is static

[exalented]

Something I've noticed is that this seems to be happening with the Nvidia generations Pascal and older. I have a 1080. This only happens when not full-screen otherwise it's black. gamescope 3.14.3-1 nis has never worked for me. I see effectively the same results as fsr in this issue.

System:
  Host: ArchTower Kernel: 6.8.9-arch1-1 arch: x86_64 bits: 64
  Desktop: Sway v: 1.9 Distro: Arch Linux
Graphics:
  Device-1: NVIDIA GP104 [GeForce GTX 1080] driver: nvidia v: 550.78
  Display: wayland server: X.org v: 1.21.1.13 with: Xwayland v: 21.1.99
    compositor: Sway v: 1.9 driver: X: loaded: modesetting,nvidia
    gpu: nvidia,nvidia-nvswitch resolution: 1: 1920x1080~60Hz
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 550.78
    renderer: NVIDIA GeForce GTX 1080/PCIe/SSE2

Edit: switched to Arc and this issue is gone.

[llyyr]

@Joshua-Ashton I was able to bisect this to 92f28b0a5477beecc2e35e5de50d26dd18c29413

Although my issue might be unrelated, because gamescope never launches in nested mode no matter what (unrelated to using FSR)

edit: fixed by this diff

diff --git a/src/steamcompmgr.cpp b/src/steamcompmgr.cpp
index 0edc4bbe036e..210150ddb73b 100644
--- a/src/steamcompmgr.cpp
+++ b/src/steamcompmgr.cpp
@@ -6997,7 +6997,7 @@ void init_xwayland_ctx(uint32_t serverId, gamescope_xwayland_server_t *xwayland_
        else
        {
            xwm_log.infof( "Embedded, no cursor set. Using left_ptr by default." );
-           if ( !ctx->cursor->setCursorImageByName( "left_ptr" ) )
+           if ( !ctx->cursor->setCursorImageByName( "default" ) )
                xwm_log.errorf( "Failed to load mouse cursor: left_ptr" );
        }
    }

[misyltoad]

Does your cursor theme not have left_ptr? That should not be fatal anyway.

[llyyr]

Does your cursor theme not have left_ptr? That should not be fatal anyway.

It does not, duplicating the "default" cursor as "left_ptr" fixes it as well. My cursor does not have any of the fallback names listed here https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/xcursor/wlr_xcursor.c?ref_type=heads#L262-292 but it does have the names wlroots tries for first.

[zany130]

Can't reproduce this anymore after

https://gitlab.archlinux.org/archlinux/packaging/packages/gamescope/-/issues/3

Got merged so maybe it was a an issue with arch using the system libdisplay?

[Revival8697]

Can't reproduce this anymore after

https://gitlab.archlinux.org/archlinux/packaging/packages/gamescope/-/issues/3

Got merged so maybe it was a an issue with arch using the system libdisplay?

Still reproducible on my system. 🤔

[s-daveb]

Can't reproduce this anymore after

https://gitlab.archlinux.org/archlinux/packaging/packages/gamescope/-/issues/3

Got merged so maybe it was a an issue with arch using the system libdisplay?

You might be onto something!

I've noticed that when I launch gamescope via Steam with Compatibility Runtime set to "Steam Linux Runtime 1.0" or via Lutris, with "prefer system libraries" disabled, the issue would go away!

@Revival8697, have you tried something like this? It could help identify the problem.

[Revival8697]

You might be onto something!

I've noticed that when I launch gamescope via Steam with Compatibility Runtime set to "Steam Linux Runtime 1.0" or via Lutris, with "prefer system libraries" disabled, the issue would go away!

@Revival8697, have you tried something like this? It could help identify the problem.

The issue is something wrong with the wayland backend AFAIK. It works if launch with --backend sdl.

[zany130]

My mistake seems like the only reason fsr was working was because I had my 4k tv disabled.

My other monitors are 1080p so I'm guessing my fsr settings of 1440 upscaled to 4k don't do anything there so it was "working"

When I enabled my tv I started getting the same issues again

--backend sdl fixes it for me aswell

[Neubulae]

Same issue here. Glad I found this issue being tracked.

[jamesdsparling]

To note this issue does not affect sway window manager unless for some reason you set the window to floating mode. The gamescope release from 24.05 does have this issue in sway when using global fullscreen spanning the game across multiple monitors with FSR on, but this is already fixed in unstable.

[M-L-Crassus]

Same issue here. Can get FSR to work using --backend sdl, but that breaks steam integration. Using KDE on arch and gamescope 3.14.24-1

[s-daveb]

This issue went away after I updated my Arch-based system to the latest gamescope-git, and the latest stable release of kwin_wayland, the kernel, and MESA.

There is something happening with the Wayland backend, as correctly pointed out by others, but the specific place in the backend code is still unknown.

I'm still thinking this is caused by an incompatibility with a helper library in that backend, but one that might go away as distributions update their very old packages.

Can't reproduce this anymore after

https://gitlab.archlinux.org/archlinux/packaging/packages/gamescope/-/issues/3

Got merged so maybe it was a an issue with arch using the system libdisplay?

You might be onto something!

I've noticed that when I launch gamescope via Steam with Compatibility Runtime set to "Steam Linux Runtime 1.0" or via Lutris, with "prefer system libraries" disabled, the issue would go away!

@Revival8697, have you tried something like this? It could help identify the problem.

[Neubulae]

This issue went away after I updated my Arch-based system to the latest gamescope-git, and the latest stable release of kwin_wayland, the kernel, and MESA.

There is something happening with the Wayland backend, as correctly pointed out by others, but the specific place in the backend code is still unknown.

I'm still thinking this is caused by an incompatibility with a helper library in that backend, but one that might go away as distributions update their very old packages.

I've built against latest commit and it now seems to work for me too, I haven't checked which commit fixed this issue, would anybody else try to take a look? @zany130

[zany130]

Switched to Bazzite, and I mainly only game now in game mode instead of on the desktop, but from a quick test gamescope -w 2560 -h 1440 -W 3840 -H 2160 -r 120 -o 30 -f -F fsr -S auto --fsr-sharpness 2 -- vkcube , I haven't been able to reproduce this anymore

[t9999clint]

Switched to Bazzite, and I mainly only game now in game mode instead of on the desktop, but from a quick test, I haven't been able to reproduce this anymore

I'm also on Bazzite. Running a RX 6750XT, issue is still there for me. the workaround of --backend sdl does seem to fix it. --backend wayland is still borked with FSR for me

Can't use FSR in bottles because I don't think there's a way to get it to use a SDL backend.

[dNifle]

Had this issue with gamescope version 3.14.20-1 (from official Manjaro repository). Worked with gamescope commit ddf0d76 I built locally (just used current master).

[zastrixarundell]

With the change to kde 6.2.1 on a 7900XTX and flatpak gamescope, my current behaviour is that it's not blank anymore but just transparent. Weirdly enough when the monitor is set to a vertical orientation it works.

Vertical orientation:

Horizontal orientation:

Launch options: gamescope -h 720 -H 1080 -F fsr -f -- %command% & sleep 10 && while pgrep -x "CrBrowserMain"; do pgrep -f "eso64\.exe" && sleep 5 && pkill -9 CrBrowserMain && break || sleep 1 && echo "waited"; done

The last part is just an autoclose of the launcher.