misyltoad
commented
1 year ago Can you try Steam Beta?
Open Milliw opened 1 year ago
misyltoad
commented
1 year ago Can you try Steam Beta?
Milliw
commented
1 year ago Can you try Steam Beta?
I did right now and that changed nothing.
I would like to mention, that forcing gamescope to start the game in fullscreen (-f) leads to a black screen with not launching the game at all. I then need to kill the game and the gamescope process.
Below two screenshots showing the malformed mouse cursor:
Oh and hotkeys only work by pressing super + alt/ctrl, too. (Just to mention if someone stumbles over this and is wondering maybe, too)
Dhizaes
commented
1 year ago I tried it with Cyberpunk 2077 and Steam Overlay isn't working in there too. Looks like it isn't related to external programs, or it isn't a game specific issue, i'm not sure.
Milliw
commented
1 year ago Something has changed while I was a few days away. Steam overlay seems to work now but gamescope makes the game acting strange in terms of mouse input. Feels very laggy and mouse input gets send to the character although map is opened which is not the default behaviour. Makes gamescope unusable for me sadly.
kevenwyld
commented
1 year ago @Milliw I'm having this issue still. Is the overlay still working for you? I can't seem to get it to work at all and I'm trying to figure out if it's just me or if there are just very few people who use it.
I found #810 which seems to be the same thing. In my comment there I have some details about my env.
Stuff I've tried so far has been:
all the debugging options, which don't seem to yield any useful information except repeated instances of the following error however I think that is normal maybe since 64bit is used?
ERROR: ld.so: object '/home/
I tried forcing gamescope instead of gamescope-wl by unsetting all the various wayland variables. This worked in that it launched an X11 based gamescope session but it did not change the overlay behavior.
Tried disabling layers (one of the debug options). As far as I understand the overlay is generated using these layers (could be wrong, really out of my depth here). This has no impact, but it's also interesting that when running --debug-layers there doesn't seem to be any layer debug lines around when I would expect the overlay popups to be displayed on game launch. So maybe I'm wrong about how this works, or maybe it's not working?
Here's a successful launch of Dirt Rally 2.0. The overlay does not work in any of the games I have tried but this is one that I play often. I started the game, waited until it was running in the start screen, attempted to launch the overlay with Shift+Tab (at that point it should have already shown the popups which also didn't appear), and then force-exited the game.
This is a game where the overlay is necessary to invite people to multiplayer races, so the multiplayer functionality of the game is broken due to this issue.
```
ERROR: ld.so: object '/home/
kevenwyld
commented
1 year ago I just discovered that the overlay, or rather a close relative of the overlay, works in big-picture mode. So if you launch steam with gamescope like so (resolution of my display just as an example):
/usr/bin/gamescope -W 3840 -H 1600 -r 144 -b --steam /usr/bin/steamAnd then enter big picture mode and launch a game, the invite functions in multiplayer games launch the big picture version of the overlay which works fine and all the menus work. The only issue is that there's no way to get the overlay to appear in game without a controller. Everything else can be done with the keyboard but displaying the overlay is not possible from what I can tell, you have to be able to press the "steam" button or equivalent button on another controller type.
Milliw
commented
1 year ago Is the overlay still working for you?
Nah.... it's changing from time to time... I don't use gamescope anymore and since last Steam UI-update even without gamescope the overlay does not work anymore - crashes the games sometimes. It's a mess. I'm getting so annoyed...
InsaneCake
commented
1 year ago For me steam overlay not working inside gamescope regardles of game (for a long time). In case with HUNT: Showdown - I can't invite people to my party, but can accept invites from others in separate chat window.
Up to date EndeavourOS with KDE Wayland, RX 6600XT
ForTheReallys
commented
1 year ago I'm not entirely sure what caused the overlay to stop working in gamescope, but I found a way to work around it:
gamescope -W 1920 -H 1080 -r 144Starting Xwayland on :1DISPLAY=:1 %command%Milliw
commented
1 year ago That's some interesting method!
Milliw
commented
1 year ago Does anyone have news on this?
I tried again today and my state is now, that Steam overlay works, but Hunt: Showdown says "enable steam overlay"...
kevenwyld
commented
1 year ago @Milliw what version of gamescope are you using?
EDIT: And to answer your question, I haven't been able to get it to work, but also I didn't feel like installing an experimental version of mesa so I haven't tried the latest which I think is 3.12.5.r23.gb19e928
Milliw
commented
1 year ago 3.12.3-16 @kevenwyld
Interestingly after having no success with gamescope yesterday I disabled gamescope but left overlay enabled and invite/overlay worked the whole evening with no game crashing.
rsramkis
commented
1 year ago I'm not entirely sure what caused the overlay to stop working in gamescope, but I found a way to work around it:
1. Launch gamescope without the %command% in a separate terminal window. eg `gamescope -W 1920 -H 1080 -r 144` 2. Note the Xwayland display gamescope is listening on. It should look like `Starting Xwayland on :1` 3. Run the game with DISPLAY set to the gamescope DISPLAY via launch options. eg `DISPLAY=:1 %command%`
I'm testing in Arch\EndeavourOS with Gnome 44.5 (Thinkpad T450 with Intel Graphics) and I also when I remove the "-- %command%" games like Wingspan and World of Tanks Blitz that the games launch.
So my working launch configuration is "gamescope --expose-wayland".
So like you all, I"m trying to find out what %command% does.
returnofblank
commented
1 year ago Replying to https://github.com/ValveSoftware/gamescope/issues/835#issuecomment-1732638848
%command% should refer to the game's executable
rsramkis
commented
1 year ago Thanks for the heads up on %command%. I think what I was really looking for is why the "gamescope --expose-wayland" will run without the %command%. Because the game (World of Tank Blitz" still launches.
Kagukara
commented
1 year ago I'm not entirely sure what caused the overlay to stop working in gamescope, but I found a way to work around it:
- Launch gamescope without the %command% in a separate terminal window. eg
gamescope -W 1920 -H 1080 -r 144- Note the Xwayland display gamescope is listening on. It should look like
Starting Xwayland on :1- Run the game with DISPLAY set to the gamescope DISPLAY via launch options. eg
DISPLAY=:1 %command%
This is the only way I've been able to get the Steam Overlay in Risk of Rain Return. Thank you. (Archlinux, Swaywm)
Using gamescope -W 3840 -H 1800 in the terminal and DISPLAY=:1 %command% in "Launch Options".
fritz-fritz
commented
11 months ago I'm not entirely sure what caused the overlay to stop working in gamescope, but I found a way to work around it:
1. Launch gamescope without the %command% in a separate terminal window. eg `gamescope -W 1920 -H 1080 -r 144` 2. Note the Xwayland display gamescope is listening on. It should look like `Starting Xwayland on :1` 3. Run the game with DISPLAY set to the gamescope DISPLAY via launch options. eg `DISPLAY=:1 %command%`
Just wanted to add I have the same issue and this workaround DOES work, but only if you launch gamescope without -e. I haven't noticed a downside for doing so at this point.
I also haven't been able to get this workaround working entirely via steam launch options yet. So it's just another thing to add to my custom script.
I tried something like:
gamescope -w 2560 -h 1080 -W 3440 -H 1440 -f -F fsr -r 120 --adaptive-sync --prefer-vk-device 10de:1f9d 2&>1 /dev/null & while [ -z \"$(ps aux | egrep '[X]wayland :[\d]+*')\" ]; do sleep 0.5; done; ps aux | egrep '[X]wayland :[\d]+*' | awk '/Xwayland/ {{ match($0, /Xwayland :([0-9]+)/, arr); print arr[1] }}' | read screen; DISPLAY=:$screen %command%which in theory should launch gamescope, wait for it to create the screen, and then pass it to the launching game via DISPLAY. In practice, the game never fully launches.
Wish the devs would take a look at fixing the overlay so this workaround isn't needed!
DonKatsu
commented
11 months ago Running Fedora 39 KDE on Wayland. Up until December 14th the Steam overlay was working for me in gamescope on Wayland.
Between then and the 17th, it stopped working.
I didn't play anything with gamescope between then so I'm not sure which of these package changes might have caused it.
mesa is still 23.2.1 since rpmfusion's mesa-va-drivers-freeworld is lagging behind mesa 23.3.0, and gamescope is still 3.12.5 as 3.12.6 and 3.12.7 fail to launch games and Fedora hasn't released anything since.
I use the sentry copr for my kernel, and I first noticed problems with gamescope when I was on 6.6.7-202. Trying to launch any game with gamescope in Wayland would show the panel icon, but no window would appear. Title screen music could still be heard. Closing the game or trying to stop the game through Steam would get stuck and gamescope had to be killed manually. After updating to 6.6.7-203 the gamescope window would show again in Wayland, but without the Steam overlay. Going back to 6.6.7-202, 6.6.6-201, and 6.6.5-202 still had the invisible window. Since I was using the third with no problems on the 13th, I don't know why that is.
Switching to x11, all kernel versions launch gamescope as expected, with working overlay. The DISPLAY=:1 trick does work for me in Wayland. But I'm primarily using gamescope as a workaround for a game that seems to have the XNA issue that causes the Steam overlay to render as solid colors. And using that causes it to happen again, defeating the purpose.
On another drive, I have an updated fresh install of Fedora 39 KDE with the bare minimum amount of tweaks. It has rpmfusion (with multimedia), mesa 23.3.0 (no freeworld), Steam, and gamescope still at 3.12.5 for the same reasons. Overlay doesn't work in Wayland on any of those above kernels, but the invisible window doesn't happen either. So I don't know why that happens on my actual setup. I tried the stock Fedora 6.6.6 kernel too. All kernels started gamescope normally with overlay on x11 as well.
In all instances I'm using the Steam rpm, beta enabled. GPU is a 6700XT.
One more thing that is definitely outside the scope for this issue, but might be relevant?
At the same time as this started I noticed the Linux native game Brigador was failing to launch while on Wayland.
It tries going through openGL versions 4.3 to 2.1 and gets Failed to initialize GLEW: Unknown error on each try until it quits.
If I force the Steam Linux runtime (scout) it will launch. Switching to x11 lets it launch without forced compatibility checked.
But it has been at least two months since I last launched it so I don't know for sure if it's part of the same problem.
Update: While messing around with dnf, I found I had wlroots 0.17.0 available despite it not showing up before. That alone didn't help anything, but I was able to install the f40 build of gamescope 3.13.19 from koji which required it. I should compile it myself but the dependency list on the wiki is outdated. Overlay works on Wayland and the game icon shows instead of the generic Wayland icon.
Eckoa
commented
9 months ago Could some folks here try adding SDL_VIDEODRIVER=x11 to your launch options
This resolved the issue with steam overlay not working in gamescope for me and it may possibly fix it for you folks also.
my exact launch options for gamescope are
SDL_VIDEODRIVER=x11 gamescope -f -e -F fsr -r 60 -w 1970 -h 1108 --
kevenwyld
commented
9 months ago @Eckoa well that's a bit embarrassing, could have sworn I tried that but you're right it works.
Unfortunately placing that env var at the beginning like you have forces the gamescope window to run with xwayland, instead of wayland native. This is not ideal since gamescope does in fact support wayland, however it does maybe explain why things aren't working since I think wayland support might be relatively new and experimental. It's also a pretty good workaround though.
Eckoa
commented
9 months ago @Eckoa well that's a bit embarrassing, could have sworn I tried that but you're right it works.
Unfortunately placing that env var at the beginning like you have forces the gamescope window to run with xwayland, instead of wayland native. This is not ideal since gamescope does in fact support wayland, however it does maybe explain why things aren't working since I think wayland support might be relatively new and experimental. It's also a pretty good workaround though.
I havent tested placing it after gamescope, I just tossed it into my launch options to see if it would work. Im not really concerned myself of xwayland or native wayland and care more about it functioning XD
kevenwyld
commented
9 months ago @Eckoa I havent tested placing it after gamescope
What I mean to say is that I think gamescope running in wayland native mode is the reason the overlay is not working. So placing it after won't have the same impact.
Eckoa
commented
9 months ago @Eckoa I havent tested placing it after gamescope
What I mean to say is that I think gamescope running in wayland native mode is the reason the overlay is not working. So placing it after won't have the same impact.
gotcha, very well could be the case. I decided to test it after seeing someone having issues running GLmark with gamescope and they came to the conclusion the SDL wayland driver has some sort of bug as the X11 option fixed launching GLmark
Eckoa
commented
9 months ago Another part to the SDL driver workaround may require you to pass XCURSOR_THEME=_some-cursor-theme_ as a variable also to fix the cursor theme not propagating to the game.
The SDL workaround leaves the steam overlay mouse being huge but the games mouse is the proper size and passing the cursor theme fixes the game using the wrong cursor in the case of games that dont have their own.
notpeelz
commented
9 months ago The SDL workaround leaves the steam overlay mouse being huge
I had the same issue. Upgrading to gamescope 3.14.0 fixed it for me. See 58509f03ba00f7adaca77b27515e585412e440cc and 1a008fafbd6cb5291eda160b9dcbfa1c13785921
ThisNekoGuy
commented
9 months ago The SDL workaround doesn't seem to work for Helldivers 2; was hoping that it would but it didn't. :/
urioTV
commented
8 months ago Right know I see that I can run a game in gamescope once but when I quit it I need to restart whole steam to play any other game. SDL workaround also doesn't seem to work.
Barbyie
commented
8 months ago I'm not entirely sure what caused the overlay to stop working in gamescope, but I found a way to work around it:
1. Launch gamescope without the %command% in a separate terminal window. eg `gamescope -W 1920 -H 1080 -r 144` 2. Note the Xwayland display gamescope is listening on. It should look like `Starting Xwayland on :1` 3. Run the game with DISPLAY set to the gamescope DISPLAY via launch options. eg `DISPLAY=:1 %command%`
I am facing the same issue, and this is the only thing that fixed it for me. Running on version 3.14.0.
ThisNekoGuy
commented
8 months ago That's the only way I've gotten it to work too, except I had to set the DISPLAY value to :2 instead because that's what gamescope decided to set for Xwayland. Closing the game (in my case, Helldivers 2) causes the window to hang though, with gamescope errors:
morissonmaciel
commented
8 months ago Hello everyone, for those still encountering this issue, I strongly advise against manipulating the DISPLAY environment variable. This variable appears to be linked to the physical device layer hierarchy itself.
I have managed to resolve this issue in two Arch Linux installations with Gamescope Session Git, using the following command:
export GAMESCOPE_WAYLAND_DISPLAY=:`1`Upon debugging through a tty session, I noticed that my DISPLAY variable was initially set to :0. This setting
corresponds to the root physical layer. In my logs, there were numerous warnings related to XWayland and layer :1
every time I attempted to take a screenshot or enable another overlay resource. My assumption is that Steam Overlay relies on XWayland and failed to connect to the appropriate display layer.
By setting the GAMESCOPE_WAYLAND_DISPLAY environment variable to the overlooked display number :1, I was able to bypass this issue.
Eckoa
commented
8 months ago Replying to https://github.com/ValveSoftware/gamescope/issues/835#issuecomment-2002113726
You running the gamescope session or nested here? because pretty sure youre just running a session if youre using Gamescope Session Git . If youre running the session that has never been a problem afaik and running gamescope as your session is completely different from trying to solve the issue while running it nested within another compositor such as kwin or mutter.
What myself and others have attempted to do is solve the nested issue, which when you run gamescope in a terminal will output the wayland display it is on then you just use point the game to that. I personally use the SDL workaround for it so i dont have to do that and it works for my use case.
morissonmaciel
commented
8 months ago Replying to https://github.com/ValveSoftware/gamescope/issues/835#issuecomment-2002151952
I'm sorry. I know this thread primarily focuses on addressing issues related to nested compositing with Gamescope. But, recently, some users, including myself, have encountered similar problems when running Gamescope in a standalone session without any additional compositor. The nature and cause of these issues are currently unclear but may be related to recent changes in Mesa or RADV libraries, which could impact both nested and standalone sessions.
What I know is that custom Mesa patched libraries (such as used by Chimera), or more "outdated" versions of Gamescope, didn't result in these overlays errors.
DonKatsu
commented
7 months ago Ran into this again after moving to CachyOS and trying to set up Gamescope to work around Underrail's issues.
The SDL_VIDEODRIVER=x11 workaround does the job, but then the cursor is able to leave the game window with -f on my dual monitor setup. (Though minimizing and restoring the window does lock it.)
It's locked to the window when SDL_VIDEODRIVER isn't set.
urioTV
commented
5 months ago From all suggestions only running gamescope separately and running a game afterwards works.
I tried to write a script to automate that(as a workaround until it's fixed) however it does not work in steam. It works only outside for example when i run gamescope-lau.cher.sh vkcube.
#!/bin/bash
# Function to launch gamescope and the game
launch_game() {
# Launch gamescope in the background and redirect output to the temporary file
gamescope -f &
GAMESCOPE_PID=$!
# Wait a few seconds to ensure gamescope is fully initialized
sleep 3
# Set DISPLAY to :1
export DISPLAY=:1
# Launch the game with the DISPLAY environment variable set to :1
$@
# Wait for the game to exit
wait $!
# Kill gamescope process
kill $GAMESCOPE_PID
}
# Check if a command was provided
if [ $# -eq 0 ]; then
echo "Usage: $0 %command%"
exit 1
fi
# Call the function to launch gamescope and the game
launch_game "$@"
Virkkunen
commented
4 months ago As of today (20240628) this is still an issue. The workaround works fine, and to be able to run it with gamemode and mangohud, you can run gamescope with:
gamescope -W RES_WIDTH -H RES_HEIGHT -f --mangoappand the game's launch properties as:
DISPLAY=:XWAYLAND_DISPLAY gamemoderun %command%Be sure to change RES_WIDTH, RES_HEIGHT and XWAYLAND_DISPLAY.
My full arguments are:
gamescope -W 3840 -H 2160 -r 165 --hdr-enabled --hdr-itm-enable --hdr-itm-sdr-nits 300 -f --mangoappThere's a bug going on in which mangohud won't be able to display the GPU info and wether gamemode is active or not, but this is beyond gamescope's scope (no pun intended).
cncz42
commented
2 months ago This started working for me today on plasma wayland and I'm not sure how, did valve update steam overlay on their end? (I'm on steam family beta and my full launch args are MANGOHUD=1 hdr-wrapper gamescope -f -W 2560 -H 1440 -r 240 --hdr-enabled -- gamemoderun %command% if anyone wants to confirm this). Even game recording works except in dx11 hdr games.
cncz42
commented
2 months ago This started working for me today on plasma wayland and I'm not sure how, did valve update steam overlay on their end? (I'm on steam family beta and my full launch args are
MANGOHUD=1 hdr-wrapper gamescope -f -W 2560 -H 1440 -r 240 --hdr-enabled -- gamemoderun %command%if anyone wants to confirm this). Even game recording works except in dx11 hdr games.
Despite overlay now working correctly, https://github.com/ValveSoftware/gamescope/issues/1292 is still present
ThisNekoGuy
commented
2 months ago For me, the overlay still doesn't work correctly (on Steam Beta Stable; forgot the Steam Family Beta got merged with Stable yesterday)
gavtroy
commented
2 months ago For the Wayland backend it started working in 3.14.23, but there's still no overlay with the SDL backend unless you apply the SDL_VIDEODRIVER=x11 "workaround".
ThisNekoGuy
commented
2 months ago For the Wayland backend it started working in 3.14.23
I used --backend wayland (and tried leaving it on auto), am running a desktop Wayland session, and using 3.15.5 and still not having it work, to clarify.
SDL_VIDEODRIVER=wayland LD_BIND_NOW=1 VKD3D_CONFIG=no_upload_hvv DXVK_HDR=1 ENABLE_GAMESCOPE_WSI=1 gamescope -e --nested-refresh=60 -o 15 -w 3840 -h 2160 -f -b -R --rt --force-grab-cursor --hide-cursor-delay 3000 --fade-out-duration 200 --prefer-vk-device --adaptive-sync --sharpness 0 --hdr-enabled --hdr-itm-enable --backend wayland -- gamemoderun %command%EDIT: Using --backend sdl with SDL_VIDEODRIVER=x11 made no difference either.
SDL_VIDEODRIVER=x11 LD_BIND_NOW=1 VKD3D_CONFIG=no_upload_hvv DXVK_HDR=1 ENABLE_GAMESCOPE_WSI=1 gamescope -e --nested-refresh=60 -o 15 -w 3840 -h 2160 -f -b -R --rt --force-grab-cursor --hide-cursor-delay 3000 --fade-out-duration 200 --prefer-vk-device --adaptive-sync --sharpness 0 --hdr-enabled --hdr-itm-enable --backend sdl -- gamemoderun %command%
ninja-
commented
2 months ago I think playing with $DISPLAY is more of a placebo.
The issue happens only with ENABLE_GAMESCOPE_WSI=1, and if you are not HDR gaming, you don't need it. (you can force it to 0) The input actually works fine, so steam overlay turns on on shift+tab but is invisible. By playing with $DISPLAY, you are bypassing the enabled gamescope WSI and silently breaking HDR.
To me, the issue looks like gamescope improperly assumes it can direct scanout the game even if the overlay is on, or there is some problem with managing wl_subsurfaces if that's what gamescope is using in nested composition.
ninja-
commented
2 months ago also, on HDR topic, not sure why --hdr-debug-force-output is still needed, kde devs said it's not needed anymore on recent KDE versions...
wrz 19 20:11:09 fedora steam[317571]: [Gamescope WSI] Surface state: wrz 19 20:11:09 fedora steam[317571]: steam app id: 1332010 wrz 19 20:11:09 fedora steam[317571]: window xid: 0x1200053 wrz 19 20:11:09 fedora steam[317571]: wayland surface res id: 5 wrz 19 20:11:09 fedora steam[317571]: layer client flags: 0x4 wrz 19 20:11:09 fedora steam[317571]: server hdr output enabled: false wrz 19 20:11:09 fedora steam[317571]: hdr formats exposed to client: false
with hdr-debug-force-output, last two lines change to true; even though the swapchain is in both cases the HDR one
also, it's easy to think you are playing HDR while in reality game is not outputting HDR, for example for Unreal Engine 4
Good swapchain: wrz 19 19:09:08 fedora steam[259177]: [Gamescope WSI] Creating swapchain for xid: 0x1200053 - minImageCount: 4 - format: VK_FORMAT_R16G16B16A16_SFLOAT - colorspace: VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT - flip: true
HDR disabled swapchain: wrz 19 20:21:55 fedora steam[317571]: [Gamescope WSI] Creating swapchain for xid: 0x1200053 - minImageCount: 4 - format: VK_FORMAT_A2B10G10R10_UNORM_PACK32 - colorspace: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR - flip: true
To 100% verify you are not playing with fake HDR, it's useful to change KDE SDR brightness back and forth - if the HDR is not fake, the game will ignore the brightness changes while the taskbar will change brightness
ninja-
commented
2 months ago back to the topic of overlay, I am not sure if it's fixable just on gamescope side as per https://github.com/ValveSoftware/steam-for-linux/issues/8020.
It might be possible to analyze all X11 calls steam-overlay is doing, and carefully emulate them in a way that kind of let's it access windows created using Gamescope WSI.
Another solution would be to create HDR enablement path for XWayland, which would make Gamescope WSI unnecessary for HDR gaming until steam-overlay releases a fixed version
(maybe it will happen in next few months in Mesa because color-management protocol is close to being merged to wayland-protocols, and then you should be able to HDR play with and without gamescope, and with Gamescope WSI disabled; gamescope will need to implement color_management_v1 in addition to deprecated frog-color-management-v1)
ninja-
commented
2 months ago for HDR gaming for now I recommend: turning off steam input(fixes gamepads not working) in game settings and turning off "enable steam overlay ingame"(to avoid accidently bringing up an invisible overlay with hotkeys)
fkroener
commented
3 weeks ago Adding --force-grab-cursor fixed the overlay for me in a plasma session.
ninja-
commented
3 weeks ago Sounds very weird, with what game do you see this behavior? Maybe it’s another false positive that also results in Gamescope WSI being turned off.
anyway I made a patch that brings it closer to a real fix - at #1537 - but it needs more work to avoid cursor glitches when going in and out of overlay and to copy keyboard inputs to the overlay and not only to the game itself
dragaoazuljr
commented
2 weeks ago Hello everyone,
I’m also having issues with input in the nested session of Gamescope with Steam. When I use the -e flag in the command line, input doesn’t work in the games. What I can't understand is why Steam games using Proton accept input normally, while games from outside Steam (like Heroic and Lutris) do not. Does anyone know what Steam does differently to launch the games? Since both theoretically use Proton, there shouldn’t be a difference.
Here’s what I’ve identified so far:
gamescope (vars) -- %command% works fine for input (for both Steam and non-Steam games), but the Steam overlay doesn’t display; it stays in the background.gamescope -e (vars) -- %command% does not work for non-Steam games, but it works for Steam games.gamescope (vars) -- steam -gamepadui launches Steam normally, but there are some issues with MangoHUD. The games start but don’t display anything. In the Gamescope log, I see: [gamescope] [Warn] xwm: got the same buffer committed twice, ignoring. This happens for both Steam and non-Steam games.gamescope -e (vars) -- steam -gamepadui launches Steam and the game (both Steam and non-Steam), and the overlay works, but input does not.--backend sdl to force X11, but it doesn’t start. The log shows: [gamescope] [Error] vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x38344241 (VkResult: 0) [gamescope] [Error] vulkan: vkGetPhysicalDeviceFormatProperties2 returned zero modifiers for DRM format 0x38344258 (VkResult: 0) [gamescope] [Info] vulkan: supported DRM formats for sampling usage: [gamescope] [Info] vulkan: Creating Gamescope nested swapchain with format 64 and colorspace 0 gamescope: types/wlr_linux_dmabuf_v1.c:532: feedback_compile: Assertion table_len > 0' failed.I also tried disabling Steam Input for the non-Steam games, but that didn’t help. The same situation occurs: without the -e flag, input works, but with it, it does not.
Steam games I’ve tested:
Metal Gear Rising
Hades
Final Fantasy XIIINon-Steam games I’ve tested:
The Witcher 3
God of War - RagnarokMy setup:
Bazzite - Gnome - Wayland
Intel Xeon CPU
Nvidia 3060
LimticRage
commented
2 weeks ago I'm not entirely sure what caused the overlay to stop working in gamescope, but I found a way to work around it:
1. Launch gamescope without the %command% in a separate terminal window. eg `gamescope -W 1920 -H 1080 -r 144` 2. Note the Xwayland display gamescope is listening on. It should look like `Starting Xwayland on :1` 3. Run the game with DISPLAY set to the gamescope DISPLAY via launch options. eg `DISPLAY=:1 %command%`
On Nobara (Fedora) 40 and Hyprland (Wayland) session, running it as the quote it works...
No matter the game running gamescope it breaks the overlay.
Mondrethos
commented
1 day ago Replying to https://github.com/ValveSoftware/gamescope/issues/835#issuecomment-2459909603
The above method also restores the steam overlay for me. I wish I didn't have to run gamescope through terminal for this.
When I run "Hunt: Showdown" with gamescope the Steam overlay is not working anymore. Also mouse pointer is not shown correctly depending on launch options I tried.
Tried several options: -e, -f, -b, --dbug-hud, --adaptive-sync (latter two don't do anything) Tried different Proton versions: GE-7.51, Experimental, 7.0.6
OS: Nobara 37, Gnome 43.2, Wayland GPU: Nvidia RTX2060, driver v 525.85.05 Kernel: 6.2.6-201.fsync.fc37.x86_64 (Nobara standard)
Only wanted to try gamescope because of mouse escaping the game from time to time and also crashes sometimes. Enabled proton log, too but couldn't find out what of the many entries are breaking the overlay/game.
I think, it has maybe something to do with EAC (Easy Anti-Cheat) or the way the game is started by Steam because at launch the usually displayed, small starting window is not shown but instead there is a black screen/window showing some blue, disturbed graphics in it.