Related to this, https://github.com/ValveSoftware/steam-runtime/issues/473#issuecomment-953932369 mentions that in at least some configurations, the overlay is loaded into a native Wayland app, but causes the app to crash when it is opened.

It's starting to look very much like 2.0.22 will be the SDL release that defaults to Wayland... our only blockers are this and NVIDIA finishing their driver support, the latter being actively worked on as we speak.

As a stepping stone to native support, it might be a good idea for the Steam client to check SDL_VIDEODRIVER and set it to x11 if it's unset? That way we can have Wayland be the default in SDL without having to wait for the Steam team to catch up.

I've been playing Axiom Verge recently (native, FNA game) and Steam overlay shows up but nothing is rendered. For example, achievement popups has nothing on them, just a flat background. Is it due to this issue?
I'll launch the game with SDL_VIDEODRIVER=wayland and see if it works better.

I've been playing Axiom Verge recently (native, FNA game) and Steam overlay shows up but nothing is rendered. For example, achievement popups has nothing on them, just a flat background. Is it due to this issue? I'll launch the game with SDL_VIDEODRIVER=wayland and see if it works better.

#7889

@flibitijibibo thanks, Ethan, that's exactly the issue.
You can add the list of games you have there.

I see Fedora has patched their SDL to make SDL default to native Wayland (which I think is premature, but I'm not a Fedora developer, so it's not up to me)...

As a stepping stone to native support, it might be a good idea for the Steam client to check SDL_VIDEODRIVER and set it to x11 if it's unset?

... so I think it would be a good idea for Steam to do this, as a stopgap until the gameoverlayrenderer has Wayland support.

I see Fedora has patched their SDL to make SDL default to native Wayland (which I think is premature, but I'm not a Fedora developer, so it's not up to me)...

From my point of view, it's important so that the Wayland backend is actively used and developers wind up encountering it. Otherwise people will continue to develop their applications in a way where the backend won't work.

Here we are again

Going to try this one more time for SDL 2.28: https://github.com/libsdl-org/SDL/pull/6362

Has Valve done any work towards this? Wayland seems to be the default for SDL2 now, and since Wayland is especially being preferred by more users this would probably be desired (fractional scaling).

If something is needed to base support for Wayland off of, wouldn't using MangoHUD as an example work? It seems to support native Wayland just fine, more or less. Permissive licensing too (MIT) if that's a concern.

Doesn't seem like MangoHud has Wayland input written either: https://github.com/flightlessmango/MangoHud/blob/11142b5b2cdeb1b83a52d14c1adb567ff2513c31/src/keybinds.h#L58

Presentation works but that's arguably the easy part, since Vulkan layers are a thing and EGL is something that's been overridden before in lots of other places.

Interesting, I thought it was global keybindings that didn't work. IG I'll have to do a bit more testing with native Wayland applications.

If presentation works, could the keybinds be done via the global shortcuts portal? That seems like the best way to go about it, especially since by design Wayland doesn't like to allow keylogging without permission.

The latest Steam client overhauls the rendered contents of the overlay, but not the overlay itself - still no luck with EGL or Wayland WSI yet!

The latest Steam client overhauls the rendered contents of the overlay, but not the overlay itself - still no luck with EGL or Wayland WSI yet!

They're using portals for the filechooser on the Beta client, at the very least, so I've got hope. Good to see Valve working towards improving the client.

@kisak-valve @Plagman Any update? Will be support of Steam, Dota 2 of native Wayland? Is there work going on in this direction?

Any movement on this?

... our only blockers are this and NVIDIA finishing their driver support

It's 2024 and Nvidia on Wayland is looking better than ever. Many distros are now beginning to default to Wayland on their chosen DEs / compositors. It's time for Steam to do their end and implement Wayland support for their client and overlay.

I've been testing out and running Counter-Strike 2 with native wayland for quite a while now. This was achieved by editing the game/cs2.sh file in the CS2 game file directory, and changing the SDL_VIDEO_DRIVER line to use Wayland instead. This has worked almost flawlessly for a while now, and other than a few hiccups like crashing on loading screens if you move your mouse, it has worked perfectly. To be honest with you, it's better than running through XWayland. I noticed immediately that frametimes were improved, and even though I was seeing the same / similar FPS, the game just felt so much smoother.

With many native games supporting Wayland, and now Wine (and then proton soon), everything is now moving over to a Native wayland backend. When will we see these roadblocks for the steam client and overlay solved?

You can add Left 4 Dead 2 to this also. I am on CachyOS.

Launch commands

STEAM_COMPAT_RUNTIME_SDL2=1 SDL_VIDEODRIVER=wayland %command% -vulkan

Also when you select ' Wayland' as the graphics driver in Factorio in the Graphics settings menu. The Steam in-game overlay is not working. When you switch back to ' x11' it does work again. I assume it is related to this issue.

I think it's related to shortcuts on wayland. If you try to use any shortcuts, to display steamoverlay, or other apps like MangoHUD, it does not work. But with X11, all work.

MangoHUD shortcuts work fine for me in CS2 Wayland mode. Steam Overlay does not however.

I think it's related to shortcuts on wayland.
If you try to use any shortcuts, to display steamoverlay, or other apps like MangoHUD, it does not work.
But with X11, all work.

If that were the case, the FPS overlay would work anyway, but it doesn't.

Mangohud may not work with OpenGL Wayland games on Steam, for them, at least right now, it additionally requires LD_PRELOAD=""

You are right, with latest MangoHUD build, it work fine in wayland.

But Steamoverlay not....

Confirming that after the latest CS2 updates, it seems to have broken support for the steam overlay on native wayland for that game specifically, as running the game under the gamescope microcompositor returns the steam overlay functionality. Seems specific to CS2 as other native games like TF2 still work fine.

Tested with KDE Plasma 6.4.3 and gamescope 3.16.2

Confirming that after the latest CS2 updates, it seems to have broken support for the steam overlay on native wayland for that game specifically, as running the game under the gamescope microcompositor returns the steam overlay functionality. Seems specific to CS2 as other native games like TF2 still work fine.

Tested with KDE Plasma 6.4.3 and gamescope 3.16.2

Can you share your launch command with gamescope ?

I tried with gamescope but in my case it launch cs2 with xwayland, so overlay work. But with the expand wayland option, overlay does not work too, like cs2 wayland without gamescope.

I fixed the steam overlay issue temporarily by setting these startup flags for cs2:

SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1 SDL_VIDEO_DRIVER=x11 gamemoderun %command%

Running KDE Plasma 6.4.3 and gamemode 1.8.2-1.1 on CachyOS Linux :) 👍🏼

That's because you set it to XWayland with "SDL_VIDEO_DRIVER=x11"

I fixed the steam overlay issue temporarily by setting these startup flags for cs2:

SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1 SDL_VIDEO_DRIVER=x11 gamemoderun %command%

Running KDE Plasma 6.4.3 and gamemode 1.8.2-1.1 on CachyOS Linux :) 👍🏼

This might get the overlay running; however, that is beside the point of this issue.
The issue is, that the overlay doesn't work on wayland, where as your method forces the use of x11/xwayland.

As I understand it, the overlay (just like the Steam client itself) is based on fundamentally incompatible software and will have to be manually ported to wayland or maybe even entirely rewritten.

Did this get fixed in latest cs2 update? Overlay seems to work again, and I'm using wayland.

from cs2.sh:

# There is Wayland support in SDL but a recent (7/30/2025) attempt at
# allowing SDL to default to Wayland caused a number of customer issues so
# keep the default at X11 for now. Don't override any user setting so
# people can easily use Wayland if they want.
if [ "$UNAME" == "Linux" ]; then
    if [ -z "$SDL_VIDEO_DRIVER" ]; then
        export SDL_VIDEO_DRIVER=x11
    fi
fi

The game defaults to x11/Xwayland again.
You can run it with SDL_VIDEO_DRIVER=wayland %command% to use wayland.

@NyCodeGHG

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/8020#issuecomment-3141060558

As an aside, this explains the behavior of Gamescope.

In my case, I initialize the SDL_VIDEO_DRIVER=wayland environment variable via the Hyprland configuration file :

env = SDL_VIDEO_DRIVER,wayland

The bahavior, is the same as an export SDL_VIDEO_DRIVER=wayland for all system.

So, the game launches in its Wayland version every time with the overlay problem mentioned here.

However, in Gamescope, it does not inherit the environment variable. Therefore, according to the cs2.sh script, it will be defined in X11 and thus systematically start on xwayland (unless this same script is modified).

This confirms the observation made in this comment :

@TheOdd

Confirming that after the latest CS2 updates, it seems to have broken support for the steam overlay on native wayland for that game specifically, as running the game under the gamescope microcompositor returns the steam overlay functionality. Seems specific to CS2 as other native games like TF2 still work fine.

Tested with KDE Plasma 6.4.3 and gamescope 3.16.2

Did this get fixed in latest cs2 update? Overlay seems to work again, and I'm using wayland.

It is not fixed and will not work until Valve fixes it. You cannot fix this on your own because it is a problem with the Steam Overlay program itself so no amount of modifying files or adding launch parameters will work.

I fixed the steam overlay issue temporarily by setting these startup flags for cs2:
SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0 SDL_VIDEO_WAYLAND_SCALE_TO_DISPLAY=1 SDL_VIDEO_DRIVER=x11 gamemoderun %command%
Running KDE Plasma 6.4.3 and gamemode 1.8.2-1.1 on CachyOS Linux :) 👍🏼

That's because you set it to XWayland with "SDL_VIDEO_DRIVER=x11"

Oh right, I've completely forgot! Thanks for pointing out and sorry

Hey valve, maybe do something useful already? we are still waiting

Hey valve, maybe do something useful already? we are still waiting

Have Valve promised something considering Wayland? Being an entitled asshole certainly doesn't help

I suddenly get overlay and steam input using proton-ge with wayland+hdr with steam beta (flatpak). Is it fixed?

I suddenly get overlay and steam input using proton-ge with wayland+hdr with steam beta (flatpak). Is it fixed?

I can't confirm this. Steam Beta (native) on CachyOS with proton-cachyos and GE-Proton10-15, no Steam overlay.
The performance monitor is rendered, but still no Steam overlay.

Can you confirm, that the game is running in an wayland window? On KDE, you could use the KWin console:

qdbus org.kde.KWin /KWin showDebugConsole

I wasn't able to repro - a smaller test is the public sdl3 beta for FEZ; if you delete FEZ.bmp in the game folder the window icon on Plasma 6.4 and newer should be the Wayland symbol.

It is still broken. I am on the Steam Beta and was using it last night playing Left 4 Dead 2 the native version. My launch options use the sdl3 video driver and wayland. I have to keep the Steam client visible so that I can Alt tab to it to download workshop content or to answer messages from friends. Hope they do fix it soon.

SDL_VIDEODRIVER=wayland STEAM_COMPAT_RUNTIME_SDL3=1

I suddenly get overlay and steam input using proton-ge with wayland+hdr with steam beta (flatpak). Is it fixed?

I can't confirm this. Steam Beta (native) on CachyOS with proton-cachyos, no Steam overlay. The performance monitor is rendered, but still no Steam overlay.

Can you confirm, that the game is running in an wayland window? On KDE, you could use the KWin console:

qdbus org.kde.KWin /KWin showDebugConsole

Sorry for late confirm. I don't use KDE. I am on Fedora 42 Silverblue with cachyos kernel (6.16.6-cachyos1.fc42.x86_64).

Like I said before, I was using proton-ge, so it's not a native game. I don't know if it's from proton-ge side, cachy kernel, or anything else because my concern is only HDR with steam input. AFAIK HDR needs wayland. That's why I asked here, to confirm things.

I just learned about lg (looking glass) on GNOME.
Looks like it says wayland, not xwayland.

For example, I have Hunt Showdown running, with HDR enabled.

screenshot

launch command

PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 %command%

Helldiver 2

screenshot

Looks like overlay menu the cannot be opened, but showing FPS counter (which is part of steam overlay????). Also my gamepad worked, with or without steam input.

Does not matter if it is a native game or not, the Steam client Overlay, which is not Proton related, does not support Wayland yet.

Does not matter if it is a native game or not, the Steam client Overlay, which is not Proton related, does not support Wayland yet.

To emphasize this: The critical point of failure is the overlay itself, the overlay is supposed to hook into functions that both native and non-native have to use, so it should behave the same for any title.

That said, it helps to minimize the surface area (reducing the possible points of failure), and the easiest path to doing this is with a native game using SDL3, with no custom environment variables or overrides set. FIFO-capable desktop environments (Plasma 6.4, GNOME 48) will default to Wayland WSI with SDL3, so it is easier to verify Steam's behavior with native games running on upstream SDL. Some games with public sdl3 branches include...

• Cattle Country
• Celeste
• FEZ
• Rogue Legacy 1
• Salt & Sanctuary
• Streets of Rage 4
• TMNT: Shredder's Revenge
• I MAED A GAM3 W1TH Z0MB1ES 1N IT!!!1

SDL2 games will continue to use X11/Xwayland, and AFAIK Sniper does not use sdl2-compat, so it needs to be a game directly using SDL3.

We can add one more to the list, and this actually affects core Steamworks functionality:

https://steamcommunity.com/app/2753970/discussions/1/591784051116939437/

When SDL3 is used, Steam Input cannot function by default without the use of an environment variable to work around the issue. Being able to control the game by default will be pretty important going forward!

I have the same problem after last updates of CS2. Overlay is crazy. I can't use steam client to check additional info about players or to check store, because screen become frozen when I tried to close the windows from steam...

Please Valve, the Linux version of the game must work perfectly, cause you are the leader in Linux gaming (Steam Deck and Proton). So please make it work properly. My system is Fedora Plasma 42 with the last patches (Wayland).

CS2 steam overlay is also broken on my setup (hyprland/wayland)

To be clear it does launch it just lags a lot. Launching with SDL_VIDEODRIVER=x11 does not make a difference.

It completely breaks co-op invitations and accepting invites in Elden Ring: Nightreign, at the same time enabling PROTON_ENABLE_WAYLAND=1 significantly reduces input lag and improves overall smoothness. Without even mentioning HDR.

I think fixing overlay functionality on Wayland has become almost critical at this point.

Well, I've been havings lots of issues and tried a lot of things, but I found this and I think it all comes to this. To the steamwebhelper crashing because some issue on the overlay. So I'm +1 looking forward something here.

It completely breaks co-op invitations and accepting invites in Elden Ring: Nightreign, at the same time enabling PROTON_ENABLE_WAYLAND=1 significantly reduces input lag and improves overall smoothness. Without even mentioning HDR.

I think fixing overlay functionality on Wayland has become almost critical at this point.

You have to realize that wine-wayland has only been possible with the last version of Proton-GE. Proton does not support it and officially Proton-GE doesn't support it either.

From the Proton-GE 10 release:

If a game or launcher isn't working, please DON'T come bugging us to fix it. Officially we're with Valve on this -- it's not supported.

I have the same problem after last updates of CS2. Overlay is crazy. I can't use steam client to check additional info about players or to check store, because screen become frozen when I tried to close the windows from steam...

Please Valve, the Linux version of the game must work perfectly, cause you are the leader in Linux gaming (Steam Deck and Proton). So please make it work properly. My system is Fedora Plasma 42 with the last patches (Wayland).

Did I say something wrong? 6 bad votes. Cause I really don't understand. Do I need to provide more info?

Terraria 1.4.5 will now experience this too, since it upgraded to SDL3 as part of the overall engine updates.

I have the same problem after last updates of CS2. Overlay is crazy. I can't use steam client to check additional info about players or to check store, because screen become frozen when I tried to close the windows from steam...
Please Valve, the Linux version of the game must work perfectly, cause you are the leader in Linux gaming (Steam Deck and Proton). So please make it work properly. My system is Fedora Plasma 42 with the last patches (Wayland).

Did I say something wrong? 6 bad votes. Cause I really don't understand. Do I need to provide more info?

This sounds like you have confused SteamVR's overlay system for Steam flatscreen overlay, two different issues

Another game with this issue, the new Scott Pilgrim EX.

It's unfortunate having to do more workarounds for native Linux games than games running under Proton.

In Hunt: Showdown is the same issue that the overlay doesn't work when wayland is enabled. No workaround found despite disabling it.

Within the last few weeks the steam overlay for cs2 (which i'm running on wayland) started working when it had been broken for over a year. Did they finally fix this with many of the larger distributions cutting off support and fully moving from x11 to wayland?

Within the last few weeks the steam overlay for cs2 (which i'm running on wayland) started working when it had been broken for over a year. Did they finally fix this with many of the larger distributions cutting off support and fully moving from x11 to wayland?

Doesn't seem to be a thing, you're probably running it with xwayland

So.... For those using Wayland natively or through the new Wine driver I guess the new Steam Controller doesn't make much sense until this get fixed, right?

So.... For those using Wayland natively or through the new Wine driver I guess the new Steam Controller doesn't make much sense until this get fixed, right?

This is my fear as well.

If it comes down to HDR or controller support then HDR for me wins as my Xbox controller does work in GE-Proton with Wayland but none of my other controllers do in either D or X input modes which truly sucks as I get disconnects with the Xbox controller and it's not comfortable after extended play sessions.

I was hoping that the Steam Controller would be the answer, but now I am uncertain and don't want to waste my money.

I believe the controller issue under Proton is solved with hidraw.

For those who want to attempt to get HDR and Steam input on Wayland, use the -steamos3 Steam launch flag. I run every game through forced Proton Wayland and use a DS4 with Steam input this way.

Steam Controller 2 complicates things a bit - in theory we have a driver for direct access in SDL3...

https://github.com/libsdl-org/SDL/blob/main/src/joystick/hidapi/SDL_hidapi_steam_triton.c

... but it'd be the same story with all the other controllers, which is that we're just reading raw data without the virtualized Steam Input device bindings.

If this doesn't sound terrible (it is!), you should be able to use the device with the Steam overlay on Wayland as long as SDL3 is in use, and then undo all the stuff Steam does behind your back to blacklist real devices and whitelist the virtual ones - for FNA games we automate this via FNA_NUKE_STEAM_INPUT:

https://github.com/FNA-XNA/FNA/blob/master/src/FNAPlatform/SDL3_FNAPlatform.cs#L105-L125

So there are definitely ways to access the raw device, even for Steam Controllers, but unless you know about everything above you'll probably be in trouble when running Steam in desktop mode (including on Steam Deck, as of SteamOS 3.8).

At the same time, this is all wild conjecture, since I don't have a controller to test anything yet.

For those who want to attempt to get HDR and Steam input on Wayland, use the -steamos3 Steam launch flag. I run every game through forced Proton Wayland and use a DS4 with Steam input this way.

steam -steamos3 and then launching a game with proton-ge and Wayland enabled does not give me steam input on any controllers :(

something has changed in the latest beta with steamrt3. shift tab doesn't work, but opening someones profile within CS2 does seem to bring up the steam overlay!!

however currently i am unable to click anything, or close the overlay with any bind. a restart of the game is required. The game captures all inputs through the overlay instead of the overlay itself.

The game is 100% running in native wayland. under xwayland, the fps counter on the top left, as well as the steam overlay would NOT be stretched.

Proof of native wayland is also shown here:

can anyone else confirm this or am i going crazy?

launch options:

SDL_VIDEO_DRIVER=wayland SDL_AUDIO_DRIVER=pulseaudio %command% +exec autoexec -w 1920 -h 1440

Seems to "work" on my end too, it displays stuff but you can't interact with it.
Isn't related to steamrt3 since it works the same without it

Isn't related to steamrt3 since it works the same without it

thanks for confirmation, hadn't tested without so just assumed so. the steam beta changelog mentioned some changes to the overlay for apple / metal, wondering why that helped? maybe just some overall version bump on something got it working.

One step closer!!

Awesome progress! I hope to someday make HDR screenshots with Wine + Wayland driver.
It's interesting that games with native screenshot key bindings like Overwatch 2 do actually trigger the Steam screenshot feature correctly in Wine + Wayland.

Can confirm again this does work, albeit without inputs and requiring a restart.

For those who want to avoid this half broken steam overlay, and revert to previous behaviour of the overlay not being available at all, unsetting LD_PRELOAD works for me. Trying to open profiles opens in steam itself now.

unset LD_PRELOAD; SDL_VIDEO_DRIVER=wayland SDL_AUDIO_DRIVER=pulseaudio %command% +exec autoexec -w 1920 -h 1440

Unsetting LD_PRELOAD sounds too much since it forces the native runtime. Can't one just disable the overlay in the game properties?

Yeah you're right, I missed that option and jumped straight to ld preload for some reason

Overlay in the big picture mode also shows up but doesn't allow to interact with it. I also tried using a controller to interact with the overlay (would kinda make sense) but no luck.

Can confirm 5/8/26 because i accidentally did it a while ago. when running CS2 with Wayland the shift tab steam overlay will not show up. clicking on somebody in the leaderboard and then viewing their profile brings up the steam overlay but at that point your stuck with it on your screen until the game is restarted.

I just want to add that with a Steam Controller 2 I can press the steam button and show/hide the steam overlay in games under wayland (PROTON_ENABLE_WAYLAND=1 and proton-cachyos-slr)!
The overlay can't be interacted with at all (controller or mouse/keyboard). Probably due to it being experimental and hyprland not supporting the input capture protocol yet.

@potatoattack same on KDE Plasma

I've just found that updating to the latest steam controller firmware available on the steam beta (May 21st) completely broke the overlay and the steam controller in PROTON_ENABLE_WAYLAND=1 games. The controller will not work at all in games running in wayland mode with this update. Luckily, going to the non-beta client rolled back the firmware and fixed it.

Should this be a new issue? Maybe this is a proton-cachyos-slr problem, not sure.

It turns out this was caused by the current version of proton-cachyos-slr (proton-cachyos-slr-1:11.0.20260506-1), I think PROTON_ENABLE_WAYLAND=1 also enables PROTON_NO_STEAMINPUT=1.

Running the game with the following fixed it (I have the other env vars set elsewhere):
PROTON_NO_STEAMINPUT=0 %command%

Wayland support finally got merged into Google's ANGLE framework today, which both Steam and the overlay use. That's likely what has been holding Wayland support back, and now that it's been resolved, I expect Valve to hopefully fix this issue.

source

Hopefully this comes soon because running a dual monitor setup with different resolutions is a nightmare. ~XWayland doesn't seem to know my monitors actual resolutions and the native isn't an available option in games, just way higher or lower. If I force Wayland on it fixes the issue but then I lose the overlay :(~

JK, if I tell KDE to have X11 apps scaled by the system instead of themselves it fixes the resolution issue.
This would still be nice for running HDR games with Proton-GE though.

It's good news that it's finally been merged. I would hold my horses though. Valve already uses a fork with custom patches. I can't imagine that they were unaware of this patch and haven't experimented with it. I fear that having it upstream is not the deciding factor here - we'll see. I hope they fix it soon.

pls valve fix. i want to play cs2 wayland native and not have the steam overlay cover my screen and get stuck losing me a round.

(no i don't want to switch to x11 rendering, it adds latency).

just wanted to say i am also having this issue with my steam controller, this effectively means i am unable to use custom configs and hdr which really sucks. the above mention is from a post i made that was marked as a duplicate of this one if any one wants to see more detail on my end

just wanted to say i am also having this issue with my steam controller, this effectively means i am unable to use custom configs and hdr which really sucks. the above mention is from a post i made that was marked as a duplicate of this one if any one wants to see more detail on my end

You can launch steam with -steamos3 and steam input will work, although you won't have on-screen radial menus or the overlay. You'll have to tab out of the game and click on the controller icon to the right of the play button to edit your config. It should update in real time as normal so you don't have to restart the game to apply it.

If you're on KDE you can duplicate the steam shortcut and edit it to make this easier.

You could also use gamescope for HDR.

@SpunkyMcGoo shouldn't it be, %U -steamos3 as the %U would get filled with the steam binary path and the -steamos3 is a parameter on that binary, i.e. path/to/bin/steam -steamos3

Edit I am wrong, apparently in KDE that would be the URL arguments that would get passed if handling steam:// so you are correct! -silent -steamos3 %U

i think the real solution is figureing out how to run gamescope with the -e flag while they are nested inside another compositor, was messing around and if steam is launched inside a gamescope session (not nested on a separate tty) everything just works, i get hdr and steam input works. issue is that when repeating this nested i am unable to get hdr work, and when launching a game it is done within the steam window, no new window is made for the game.

i think the real solution is figureing out how to run gamescope with the -e flag while they are nested inside another compositor

Just having Wayland support would be preferrable. No need to confuse it with janky workarounds.

i think the real solution is figureing out how to run gamescope with the -e flag while they are nested inside another compositor

Just having Wayland support would be preferrable. No need to confuse it with janky workarounds.

yes but that requires work on valves end, and seeing how long they have kept the steam client 32 changing to wayland doesn't seem like something that is going to happen soon. i am sure there is a janky way to get everything to work tho, and i would prefer a jank solution now then a real solution in 10 years

found a jank work around, make a entry on the gentoo wiki https://wiki.gentoo.org/wiki/Steam_Controller#steam_input

found a jank work around, make a entry on the gentoo wiki https://wiki.gentoo.org/wiki/Steam_Controller#steam_input

The workaround is simply running Steam itself, plus games inside of a gamescope session which adds another compositor layer (and it's overhead) on-top of everything. While this works, I think the ultimate goal of this ticket is to enable Steam Overlay/Input for Wayland.

found a jank work around, make a entry on the gentoo wiki https://wiki.gentoo.org/wiki/Steam_Controller#steam_input

The workaround is simply running Steam itself, plus games inside of a gamescope session which adds another compositor layer (and it's overhead) on-top of everything. While this works, I think the ultimate goal of this ticket is to enable Steam Overlay/Input for Wayland.

yes that would be preferable but doesn't seem like it's going to be happening anytime soon, tho maybe with what ever graphical environment the steam frame uses valve might give steam Wayland support for that.

There has to be a better way than using Xwayland, -steamos3, used to kind of work but you could not edit the config on the fly. Especially with steam controller there has got to be a way to get this implemented and working.

There has to be a better way than using Xwayland, -steamos3, used to kind of work but you could not edit the config on the fly. Especially with steam controller there has got to be a way to get this implemented and working.

ctrl+alt+f2 launch gamescope with steam.

or if you still wan to be able to user your other monitors and you have a second gpu and if you can run 2 display cables to your main monitor and if your monitor will swithc inputs nicely, you can use uwsm to run gamescope and your main graphical session at the same time. but that a pain in the ass to setup which is why i haven't done it

Seems like the experimental steam input for wayland was removed, desktop layouts on steam controller work now so it's not the end of the world but launching steam with -steamos will have the old behavior of only applying steam input to x11 apps launched from the steam context (some x11 games launched from non-steam apps like heroic via a shortcut in steam won't work)

Seems like the experimental steam input for wayland was removed, desktop layouts on steam controller work now so it's not the end of the world but launching steam with -steamos will have the old behavior of only applying steam input to x11 apps launched from the steam context (some x11 games launched from non-steam apps like heroic via a shortcut in steam won't work)

Yeah randomly broke on me within the past week. Have just moved back to Xwayland and dealt with the annoying windows behaviour for now.

Seems like the experimental steam input for wayland was removed, desktop layouts on steam controller work now so it's not the end of the world but launching steam with -steamos will have the old behavior of only applying steam input to x11 apps launched from the steam context (some x11 games launched from non-steam apps like heroic via a shortcut in steam won't work)

still unable to get games to work with steam input under wayland, using these launch options PROTON_ENABLE_HDR=1 PROTON_USE_WAYLAND=1 PROTON_FSR4_RDNA3_UPGRADE=1 PROTON_USE_NTSYNC=1 systemd-run --user --scope -p AllowedCPUs=0-7,16-23 gamemoderun %command%

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/8020#issuecomment-4818520370

I've been following this thread and I'm already starting to lose track of what's going on. Fedora 44 Plasma. I wanted to get the game running on the ancient Wayland so that the overlay would work properly, but there's a problem with the windows—they have to be closed one by one, otherwise they stay in the middle of the screen. It's really annoying. I’d like to run the game at its native resolution on a 21:9 screen, and the only way to do that is with Gamescope. But in this mode, after a few games, severe glitches start occurring, and I have to completely close the game and reopen it. I don’t know how to fix this:'. As for the Proton I think that CS2 official servers aren't support proton

The problem I've personally been having (which is related to this issue) is that Gamescope disables shift+tab Steam overlay.
I found a temporarily solution that works for me: Add this into steam launch options to fix it.
Code: env -u LD_PRELOAD ((gamescope text goes here)) -- env LD_PRELOAD="$LD_PRELOAD" %command%

It's structured like this:
Start LD Preload wrapper:
env -u LD_PRELOAD
Add gamescope parameter and start gamescope wrapper:
gamescope ((options options options)) --
End LD Preload wrapper:
env LD_PRELOAD="$LD_PRELOAD"
End gamescope wrapper and parameters:
%command%

I am being told that LD preload loads the steam libraries outside of gamescope in this scenario. Which is what fixes the overlay issue. However with it it seems we're fighting steam remote play because it's unable to properly focus the window due to being divided by a layer of load order.

Still can't make steam remote play work while Gamescope is running. When I attempt, the player joining my session can't see the game, instead seeing the error screen "Input is temporarily disabled while the host is busy," which is the error message it usually reserves for when the host is not currently focused in the game window.

Could we not clog this thread with workarounds? You're sending notifications to at least 50 people with all this random chatter that doesn't add anything to the issue.
Just like @RLB2310 said, having Wayland support would be preferable; there is no need to confuse things with janky workarounds.

It's done when it's done, and before that it's not.

The lack of Steam Overlay seems to break Steam Controller support for BeamNG.drive native Linux build (we use native Wayland if available). Users report that the controller does not switch to "game mode".

This is open now since years. Just saying nearly all big linux distro's removing old X11 and moving to Wayland. So it's really no option to "ignore" this one.

To boost it. Without overlay it is not possible to open cases. So you also loose money.

Whats the plan for Wayland-support? Is anyone monitoring this from Valve?

the truly unfortunate aspect is that with SteamOS there's really nothing pushing valve to make any changes whatsoever. they can just create whatever environment they need within it.

I absolutly agree with needed Steam Overlay Support. Im on CachyOS with KDE-Plasma on Wayland and with the Launch Option "PROTON_ENABLE_WAYLAND=1" i get like 20-40 FPS more than without and it is urgently needed, because it completely breaks the game, if the game itself opens the overlay. I have to completly close the game to close the Steam Overlay

i doubt valve is going to be adding any major linux features any time soon, i assume most of the steam client linux team is probably working on the steam frame and will be continuing to focus on polishing that for a while after it launches. at this point the only thing i can see happening that would have valve add wayland support is alot of community backlash which i doubt is going to happen

It may not have been obviously necessary in 2021, but it is now!

not implementing this, is hurting game developers who wants to support native wayland properly.
this is also probably the main reason why Counter Strike 2 is not launching in wayland by default.

This single fix will fix alot of jankyness with linux.

for anyone wondering why i'm not using xwayland on cs2. check this blog

this issue has been open for 5 years, and i bet all +300 people watching this issue are still following.

Edit: Valve PLEASE FIX

also not having this is making steam hardware like the steam controller mostly unusable as steam input dose not work under wayland and needs either x11 or game scope. so if you want to play a game that has features that don't work in x11 say hdr you need to pick between steam input or hdr. you can run a game scope session in a separate tty but that messes up mutli monitor setups

genuinely hurry up valve, we shouldn't have to rely on ai coded patches to get steam input working under wayland, get real

Overlay also works with cachyos-wineland Proton builds: https://github.com/nanomatters/proton-cachyos/releases/tag/cachyos-wineland-11.0-20260713.2-slr
It uses different solution compared to GE.

Unfortunately I can't use these type of solutions, cause I need to play cs2

You don't need to compile it yourself.
https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton11-6