Open flibitijibibo opened 3 years ago
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.
@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?
Your system information
Please describe your issue in as much detail as possible:
The Steam overlay currently depends on GLX and X WSI for OpenGL and Vulkan respectively. As a result, when running a Wayland-native application the overlay will not appear.
For OpenGL, gameoverlayrenderer.so overrides glX but not egl. For Vulkan, steamoverlayvulkanlayer.so only overrides the functions for VK_KHR_xcb_surface and VK_KHR_xlib_surface, not VK_KHR_wayland_surface.
This will take time to write (mostly for input handling I imagine) so a workaround would be for Steam to set
SDL_VIDEODRIVER
tox11
if it's unset, being sure to only do this for native applications.Steps for reproducing this issue:
SDL_VIDEODRIVER=wayland %command% /gldevice:XXX
as a launch option, whereXXX
can beOpenGL
orVulkan