gamescope
gamescope copied to clipboard
ValveSoftware
Gamescope doesn't quit when game quits
OS: KUbuntu 22.10 Kernels tested: stock ubuntu 5.19.0 and xanmod 6.1 GPU: AMD RX 570 Mesa version: 22.2.5
Tested on both Plasma X11 and Plasma Wayland.
When I play a game via steam using gamescope everything works correctly until I quit the game.
When I do, the game ends, music stops playing, etc. but I am not dropped out to desktop. Steam shows the game is still running. I can bring up the process manager and see that the game process is no longer running but an instance of gamescope will still be running. Killing it will make the game disappear and the desktop to return. I can also kill the gamescope process by pressing stop in the steam client. It happens both full screen and windowed.
I have tested with Pillars of Eternity: Deadfire (Linux native), Valheim (native), Aragami 2 (proton), and Portal (native). All exhibit the same behaviour.
I also tried Stardew Valley (with SMAPI installed) but that exited correctly. Not sure why that worked when the others did not.
Compiled git master branch (fully up to date as of about an hour ago).
Happy to provide any additional details if they would help.
Same here in Ubuntu 22.10 Gnome wayland. Compiled it today and tried Looking-Glass-Client for my Windows 11 VM with gamescope and it works very well. When shutting down windows it closes looking-glass, but the terminal that was used to launch gamescope/looking-glass needs a Ctrl+C to stop the process.
This is the last line in terminal where it waits for me to kill the process: xwm: error 3: BadWindow (invalid Window parameter) request 15 minor 0 serial 270140
Not sure if it has anything to do with the issue, just though I'd add the info.
A little debugging show that it is stuck on https://github.com/Plagman/gamescope/blob/2a09fbcb695102e9a990ed7cf1fdc350397a58f1/src/wlserver.cpp#L1211
Adding a timeout fix the issue, however I don't know why it is stuck there.
I'm having this problem with Life is Strange: Before the Storm. If I Alt+F4, Gamescope closes. But if I quit the game from the main menu, Gamescope won't close.
A little debugging show that it is stuck on
https://github.com/Plagman/gamescope/blob/2a09fbcb695102e9a990ed7cf1fdc350397a58f1/src/wlserver.cpp#L1211
Adding a timeout fix the issue, however I don't know why it is stuck there.
How did you add this timeout?
How did you add this timeout?
By changing -1 in that line to a value in milliseconds, like 1000.
I tried adding the timeout as @patlefort suggested and it worked. Thank you!
How did you add this timeout?
By changing -1 in that line to a value in milliseconds, like 1000.
Is there a way to add this timeout to a already compiled build? Cause I'm using the Gamescope from Arch's repository.
No. That value is hard coded into the program and can't be changed at run time, only compile time. Maybe someone could make a pull request with the change in it to get it into the main code base which would get in to the arch version eventually, but it is probably better to figure out why the original line is failing.
Nope. It doesn't close after 3 seconds. I recompiled gamescope to current master without the fix @patlefort suggested and ran the command @DocMAX posted. With the process monitor open I can see gamescope start and then a moment later sleep starts. Three seconds later sleep quits but gamescope keeps going. I have to manually kill it.
Just for testing purposes, I reran a few games with the recompiled version, Valheim still exhibits the issue, but Cyberpunk 2077 does not.
It is a bug. gamescope doesn't quit. It stays resident in memory after it is supposed to have ended and continues to display a screen when it is not supposed to.
A little debugging show that it is stuck on
https://github.com/Plagman/gamescope/blob/2a09fbcb695102e9a990ed7cf1fdc350397a58f1/src/wlserver.cpp#L1211
Adding a timeout fix the issue, however I don't know why it is stuck there.
This seems like something that should be in a pull request.
I noticed that killing gamescope won't kill the invoked program either.... is it expected behaviour, or another bug?
This is really quite a severe bug.
It means I can start a Steam game in gamescope just fine, but I can't launch another one without rebooting the PC, even after explicitly killing the 'gamescope' process, restarting Steam, etc.
If I exit a non-Steam game in gamescope, the process won't terminate properly either. After a while, the console it was started from starts spamming the message 'vblankmanager: write failed: Resource temporarily unavailable'.
I encounter the same problem with flatpak:
| ID | Version | Branch |
|---|---|---|
| com.valvesoftware.Steam.CompatibilityTool.Proton-GE | 8.14-1 | stable |
| org.freedesktop.Platform.VulkanLayer.gamescope | 3.12.5 | 23.08 |
| com.valvesoftware.Steam | 1.0.0.78 | stable |
My desktop environment is GNOME Wayland. When I launch Stardew Valley it works as expected and if I quit from game menu it closes just fine too. But if I close the window itself then the game closes but gamescope just hangs around. Even if I use sudo pkill -9 -f gamescope the game shows as stopped in steam but I can't open it again unless I restart the steam client. Same behavior for Half-Life 1.
@EoceneMiacid
I've found that it is possible to start a new game without rebooting, but it required killing the entire process tree of everything gamescope started and even then it seems to fail to fix the problem occasionally.
A little debugging show that it is stuck on https://github.com/Plagman/gamescope/blob/2a09fbcb695102e9a990ed7cf1fdc350397a58f1/src/wlserver.cpp#L1211 Adding a timeout fix the issue, however I don't know why it is stuck there.
This seems like something that should be in a pull request.
A pull request was made, but @emersion felt that waiting was not a good fix. What is the problem with waiting? Specifically, what other things stand to break if this method is used? This is a legitimate question. Users are left out in the cold on a 7-month old issue that has a very trivial workaround, so it merits a response.
A real fix will definitely take some digging into all the interlocking parts, but there has been radio silence from gamescope contributors on this issue, so we don't know what--if anything--is being done to figure out what the real fix is. So why not merge a workaround if the workaround doesn't impact anything else? Sure, this creates technical debt, which is very real and shouldn't be ignored, but by leaving issues unaddressed in pursuit of real fixes, you create a different sort of debt that I can't really find a word for.
This also occurs with xivlauncher. I use Gamescope to get around this issue: https://bugs.kde.org/show_bug.cgi?id=458233
I'm having the issue with CS2, can't say I've ever had the issue on other games, but I don't really use gamescope with other games.
Edit: Issue persists on other games, just tried Raft
Very strange, this used to work and no code has changed here. Gamescope sets itself up as a reaper so if it dies its children should too.
To be more specific, the XIVLauncher process ends just fine, it's specifically the gamescope-wl process that keeps going (and Steam doesn't know XIVLauncher has quit until I end that process manually)
@Joshua-Ashton I just pulled your changes and compiled. I have tested with a couple of games and gamescope now seems to quit properly when quitting the game.
Can't get it to work in Plasma, gives an error about something being unsupported. I'll get it in a minute. In GNOME there's a different issue.
$ XL_SECRET_PROVIDER=FILE gamescope -w 2560 -h 1440 -f -- %command% run --parent-expose-pids --parent-share-pids --parent-pid=1 --branch=stable --arch=x86_64 --command=xivlauncher dev.goats.xivlauncher
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
vulkan: selecting physical device 'AMD Radeon RX 5700 XT (RADV NAVI10)': queue family 1 (general queue family 0)
vulkan: physical device supports DRM format modifiers
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:16] Starting headless backend
wlserver: [xwayland/sockets.c:63] Failed to bind socket @/tmp/.X11-unix/X0: Address already in use
wlserver: [xwayland/server.c:108] Starting Xwayland on :3
wlserver: [types/wlr_compositor.c:681] New wlr_surface 0x5650f2723df0 (res 0x5650f2749d30)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 93
xwm: execvp failed: No such file or directory
gamescope: children shut down!
(EE) failed to read Wayland events: Broken pipe
Plasma:
$ XL_SECRET_PROVIDER=FILE gamescope -w 2560 -h 1440 -f -- %command% run --parent-expose-pids --parent-share-pids --parent-pid=1 --branch=stable --arch=x86_64 --command=xivlauncher dev.goats.xivlauncher
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
Your Wayland compositor does NOT support wp_presentation/presentation-time which is required for VK_KHR_present_wait and VK_KHR_present_id which is needed for Gamescope to function.
Please update your compositor or complain to your compositor vendor for support.
This is on Arch with Plasma (Wayland) and Gnome on Wayland.
I just compiled the latest version from git as well, and I'm now experiencing several new problems.
I'm on Arch, using the Wayfire compositor on an ATI Radeon 6600.
gamescope -w 1920 -h 1080 -f -- wine game.exe - this now crashes my compositor outright, most of the time. Interestingly, when it doesn't, gamescope now terminates properly after quitting the game. The crash could be a Wayfire bug.
Running gamescope with no arguments shows:
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
vulkan: selecting physical device 'AMD Radeon RX 6600 (RADV NAVI23)': queue family 1 (general queue family 0)
vulkan: physical device supports DRM format modifiers
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: [wayland] unable to lock lockfile /run/user/1000/gamescope-0.lock, maybe another compositor is running
wlserver: Running compositor on wayland display 'gamescope-1'
wlserver: [backend/headless/backend.c:16] Starting headless backend
wlserver: [xwayland/server.c:108] Starting Xwayland on :2
wlserver: [types/wlr_compositor.c:681] New wlr_surface 0x5619625ca110 (res 0x5619624f8310)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 70
pipewire: renegotiating stream params (size: 1280x720)
What is completely broken now is running Steam games, however.
This used to work:
gamescope -w 1920 -h 1080 -f -r 60 -e -- /home/eocene/.steam/steam/ubuntu12_32/reaper SteamLaunch AppId=985890 -- /home/eocene/.steam/steam/ubuntu12_32/steam-launch-wrapper -- /home/eocene/.steam/steam/steamapps/common/Streets of Rage 4/SOR4
But with the latest version this happens:
gamescope -w 1920 -h 1080 -r 60 -f -e -- /home/eocene/.steam/steam/ubuntu12_32/reaper SteamLaunch AppId=985890 -- /home/eocene/.steam/steam/ubuntu12_32/steam-launch-wrapper -- /home/eocene/.steam/steam/steamapps/common/Streets of Rage 4/SOR4
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
ATTENTION: default value of option vk_khr_present_wait overridden by environment.
vulkan: selecting physical device 'AMD Radeon RX 6600 (RADV NAVI23)': queue family 1 (general queue family 0)
vulkan: physical device supports DRM format modifiers
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: [wayland] unable to lock lockfile /run/user/1000/gamescope-0.lock, maybe another compositor is running
wlserver: [wayland] unable to lock lockfile /run/user/1000/gamescope-1.lock, maybe another compositor is running
wlserver: Running compositor on wayland display 'gamescope-2'
wlserver: [backend/headless/backend.c:16] Starting headless backend
wlserver: [xwayland/server.c:108] Starting Xwayland on :3
wlserver: [types/wlr_compositor.c:681] New wlr_surface 0x55d9bb4f6ec0 (res 0x55d9bb4e2e40)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 73
gamescope: children shut down!
Adding gamescope to a game's launch options in steam has the same effect.
gamescope -w 1920 -h 1080 -r 60 -f -e -- %command%
to add something to yaomtc comment, gamescope used to work a few months ago (toggling fullscreen will freeze my PC and other shenanigans). however it's now completely unusable (RTX 3600 mobile / Cinnamon DE): every single time I'll launch gamescope, I'll meet another bug then crash. and commit after commit, I'll meet even new bugs. now, launching gamescope will simply invoke a black screen, and my PC will halt for ~5sec when I kill it.
gamescope -W 1920 -H 1080 -r 120 -- vkcube
No CAP_SYS_NICE, falling back to regular-priority compute and threads.
Performance will be affected.
wlserver: [backend/headless/backend.c:68] Creating headless backend
vulkan: selecting physical device 'NVIDIA GeForce RTX 3060 Laptop GPU': queue family 2 (general queue family 0)
vulkan: physical device supports DRM format modifiers
vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x3231564E (VkResult: 0)
vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x48344241 (VkResult: 0)
vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x48344258 (VkResult: 0)
vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x38344241 (VkResult: 0)
vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x38344258 (VkResult: 0)
vulkan: supported DRM formats for sampling usage:
vulkan: AR24 (0x34325241)
vulkan: XR24 (0x34325258)
vulkan: AB24 (0x34324241)
vulkan: XB24 (0x34324258)
vulkan: RG16 (0x36314752)
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:16] Starting headless backend
wlserver: [xwayland/server.c:108] Starting Xwayland on :1
wlserver: [types/wlr_compositor.c:681] New wlr_surface 0x55d2910818a0 (res 0x55d2910843d0)
wlserver: [xwayland/server.c:273] Xserver is ready
pipewire: stream state changed: connecting
pipewire: stream state changed: paused
pipewire: stream available on node ID: 69
Selected GPU 0: NVIDIA GeForce RTX 3060 Laptop GPU, type: DiscreteGpu
[Gamescope WSI] Creating Gamescope surface: xid: 0x400000
[Gamescope WSI] Atom of T was wrong type. Expected XCB_ATOM_CARDINAL.
wlserver: [types/wlr_compositor.c:681] New wlr_surface 0x55d290f44f70 (res 0x55d2910895a0)
[Gamescope WSI] Atom of T was wrong type. Expected XCB_ATOM_CARDINAL.
[Gamescope WSI] Made gamescope surface for xid: 0x400000
[Gamescope WSI] Surface state:
steam app id: 0
window xid: 0x400000
wayland surface res id: 5
layer client flags: 0x0
server hdr output enabled: false
hdr formats exposed to client: false
wlserver: [types/wlr_compositor.c:681] New wlr_surface 0x55d29110aa30 (res 0x55d2910897e0)
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.
Errors from xkbcomp are not fatal to the X server
[Gamescope WSI] Creating swapchain for xid: 0x400000 - minImageCount: 3 - format: VK_FORMAT_B8G8R8A8_UNORM - colorspace: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR - flip: true
[Gamescope WSI] Created swapchain for xid: 0x400000 - imageCount: 3
I can still run it OK from the TTY though.
gamescope -w 1920 -h 1080 -f -- wine game.exe - this now crashes my compositor outright, most of the time. Interestingly, when it doesn't, gamescope now terminates properly after quitting the game. The crash could be a Wayfire bug.
If your compositor is crashing, then yes, that's a compositor bug. (Unless you see a GPU hang in dmesg)