[Feature Request]Need the client to support wayland(not through xwayland)
If I understand this request correctly, the specifics of this request is to build the SDL 2 library used with the steam client with wayland support.
Beyond the scope of the steam client itself, Xwayland is still needed for games that are not using a middleware library that supports wayland and interactions with wayland libraries from older distro releases may need to be checked.
@kisak-valve, yes, that's the goal, so that xwayland will used for games but not for client
This would be nice :)
@snj33v It must be used for games as well. glmark shows 2-3 times better OpenGL performance on wayland.
@snj33v It could be much better if there was no such thing as steam-runtime, it just deprecated copies of libraries that every GNU/Linux distro has.
If source code was open, community could fix this issue already. Proprietary software sucks.
@DmitryHetman without steam-runtime, you'll get stuck with glibc/openssl forever (or you'll have to use chroot / docker), and get a lot of problems on rolling distributions.
As soon as sandboxing becomes common for linux apps, for example with flatpak (which could solve the issue with the steam-runtime, btw), this becomes a security issue aswell.
Under X, there's no client isolation so any app could read inputs (of e.g. credit card information). Wayland prohibits that.
See #4473
Edit: ok this was a bit misleading. Sensitive information is usually only entered in the steam app, which would need to use wayland. Thats not the issue here. But it would be great for security if the steam client would also support wayland sometime soon, as people use it to enter sensitive information like credit card information.
I think it already works as is - I'm able to use Steam on KDE Wayland, when I launch it with environment variable SDL_VIDEODRIVER=wayland
Of course, actual games fail to run when you try launching them.
seems this is very dependent on CEF(Chromium Embedded Framework) to actually work, guess we should wait till CEF adopts wayland completely
@sandy-8925 I tried but it's on Xwayland
wayland support required, please.
CEF is on their way to support Wayland. A patch is already available to switch between X11 and Ozone backend. The patch has not been merged yet.
Combine that with ozone-wayland, CEF will work with Wayland protocol. In fact there is already a working branch for Chromium's Wayland support.
http://www.phoronix.com/vr.php?view=26841
Is anyone benchmarked games with SDL2 and SDL_VIDEODRIVER=wayland? Seems like Phoronix tested XWayland performance instead of Xorg vs. Wayland performance.
@RussianNeuroMancer Steam seems to launch and work fine with SDL_VIDEODRIVER=wayland set, but most (if not all) Steam games fail to launch in that case. They're all using older/custom versions of SDL that don't work under Wayland.
@sandy-8925 Does not work for me. Are you sure it is not running under xwayland? Try running WAYLAND_DEBUG=1 steam. If you get wayland debug output it is running under wayland otherwise it is using xwayland.
@sandy-8925 Im affraid its running still on xwayland. I know it because of this https://www.reddit.com/r/linuxquestions/comments/7d445v/does_my_app_run_on_wayland_or_xwayland/
I'd say the biggest blocker here is Chromium still. The entire Steam main UI will not work without X11. If that wasn't an issue, it might be be reasonable to aim for a setup where some games (whitelist) used Wayland but that seems ambitious for now. As for games that don't work: bundling libSDL in games (not Steam runtime) is by far the biggest compatibility issue I've seen
Seems like proton can't use OpenGl through Xwayland.
Sorry, I had another problem likely an outdated mesa or something.
@RussianNeuroMancer Steam seems to launch and work fine with SDL_VIDEODRIVER=wayland set, but most (if not all) Steam games fail to launch in that case. They're all using older/custom versions of SDL that don't work under Wayland.
It launches just fine but when I run xlsclients, it shows steam running under xwayland.
I would strongly urge everyone not to set SDL_VIDEODRIVER globally unless you're trying to test SDL2. There's a priority list inside SDL2 and no doubt when the devs consider Wayland support stable enough, it will take precedence over X11 without user interaction.
Update?
Hey, if any of you folks over at Valve need help with this, feel free to get in touch: [email protected]
If source code was open, community could fix this issue already. Proprietary software sucks.
contact chromium & Igalia team, they need help with wayland codebase
To be honest it also seems to me Chromium (or parts of it) have been suffering of inadequate amounts of competent reviewers so which has slowed down Wayland change integration speed. It will happen eventually.
They say proprietary software is good because it brings funding which brings support and bug fixes. Intellectual fascism, the more accurate term for IP, is a big black hole full of lies. Just look here, almost a year and a half, and nothing happens. Nothing. It is our job to kill IP, lest our descendants ridicule us forever. Even a child can easily understand that keeping knowledge a secret is not good. Anyone who believes the lies of intellectual fascism is really missing some bolts at this point.
Is there any progress on this? I am struggling to get Wayland working even when using the native version with the latest SDL preloaded
I think you should just give up on Wayland. It's MO is basically the same as X11, except in extreme cases.
If I want to use steam remote play I have to switch to X11 for hardware decoding, getting hardware decoding support in Wayland would be great.
@blotch That sounds like a driver issue? Also you should consider abandoning Wayland, the benefits it was supposed to have it doesn't... Native Wayland is effectively identical to X11 more than %90 of the time, but if you add in Xwayland usage it's a clear loss.
@cheako Please stop suggesting people abandon native Wayland. It might not be worth it now, but when compatibility issues are fixed it will be a lot better
Not directly related to the topic but for interested parties: Valve is working on it's own Wayland compositor for SteamOS at https://github.com/Plagman/gamescope
There's also a short explanation why Wayland compositor + Xwayland can be faster than pure X11 can ever be.
off-topic: @rhysperry111 I think you are mistaken. The idea that Wayland is somehow more performant over X11 is a myth. Wayland does have an API that could be used to surpass X11 performance, but it's usage is so rare that's it's not worth discussing. Normal Wawland usage is done using the same shared memory X11 has used for decades, offering no advantage.
"Normal Wawland usage is done using the same shared memory X11 has used for decades, offering no advantage." That's XWayland, not wayland, and this information is still incorrect.
Referring to this https://wayland-book.com/surfaces/shared-memory.html most every Native Wayland application uses it... and Native X11 applications use a similar transport(when running locally). The promise of Wayland was that https://wayland-book.com/surfaces/dmabuf.html would be used. What I'm referring too is that Wayland offers no technical advantage over X11... Real world testing is nice, but if you can't explain where the performance you are seeing is coming from then you can't do anything to keep the performance through upgrades... you don't know what to keep.
Can you please take the "which is faster" discussion elsewhere?
This issue is for tracking Wayland support. If you think Wayland is slow, this isn't the place to discuss it. If you think it's fast, it's not either. You're spamming everyone following this topic.
For many of us it's not possible to downgrade to X11 (e.g.: I'd have to find replacements for wayland-only apps). Discussion of which platform is better is off-topic here. This feature is needed because Wayland is a successor to X11, and works on specific hardware setups where X11 does not.
You're free to use whatever you prefer in the meantime, and discuss this preference in the appropriate places.
Minor nitpick: this is tagged as "feature request", since op wants multi-gpu support and alike.
On many scenarios, the lack of wayland-native support results in blurry and almost unreadable text from the steam client (since XWayland doesn't support scaling). I'd argue this is a bug, not merely a feature request.
I am getting to the point I need to use a 100% wayland system and having issues running steam on it.... :( please hurry up on wayland native support. X11 has no future
TBH, I honestly don't see why Steam can't release more of the source to their client so we can address much of this ourselves ("we" as in "the community").
There's really no benefit for Steam to keep it closed source.
@WhyNotHugo Chromium is opensource. You are free to contribute in its Wayland support.
Chromium can now work natively on Wayland, iirc CEF had some Wayland bits in place already
Not sure how relevant it is, but it seems that from Chromium 87 ozone can be enabled in regular build and wayland can be enabled on the same build, see https://aur.archlinux.org/packages/chromium-ozone/#comment-776085
@Faalagorn Yup, the upstream chromium snapshots already work fine on Wayland, and as of Chromium 89, the stable builds will too.
The work on the chromium / electron side is all done; it's a matter of Steam not adopting it (I do wish they'd open source parts of their clients so we, the community, could just address this ourselves).
Slightly offtopic for interested readers: there's is a PR for glfw to use libdecoration to provide window decorations on the Wayland backend on compositors not offering system decorations (SSD). Notably Gnome/Mutter and Weston. The same library could also used by SDL2, clearing a major blocker to enable the Wayland backend by default.
Looks like the X11 servers are in a state of disowned... So time has run out?
@rmader, think valve is already working on a compositor and providing inputs to wayland(xwayland included) community, for games, (important on vsync situation, backward compatibility)
@cheako just a nitpick but this is nothing new. X.org X11 has been in this state for years now.
The same library could also used by SDL2, clearing a major blocker to enable the Wayland backend by default.
IMHO, I don't think the lack of decorations is a blocker. Steam could well support Wayland and later deal with these, since they're really not a dealbraker -- Steam would work fine without these.
The work on the chromium / electron side is all done;
not quite, Electron 12 is needed and that will ship in March 2021
Really we are still in this state? then people wonders why linux gaming adoption is still so low... You are making millions with this, get ddevault offer for help, he is an expert in Wayland and Wayland compositors
Really we are still in this state? then people wonders why linux gaming adoption is still so low... You are making millions with this, get ddevault offer for help, he is an expert in Wayland and Wayland compositors
I hope it's planned, just Valve Time™ and stuff.
TL;DR: Want something to be added, put more effort than just say said feature. It helps both sides, the user and the developers.
This is not really a social commentary but:
The code is there to read, analyse and promote/improve/request (actual code). But of course that takes time, but effort has to be put. I doubt asking for it to be implemented won't help, at least bring a dialog of a solid argument which include; reasonable way to implement of the said feature.
As long as people just say "add this, add that" you bring nothing to the table but (add) to (bottom of) the list of priorities.
If I'm correct, I think that right now there are a few things happening on XWayland that are not happening on a Xorg session:
- Notifications are a hit/miss. The animation to show them is choppy and clicking on them to go to a conversation is laggy.
- Having multiple windows (Client + Friend List/Chat/Store site opened in a window) makes Steam unresponsive.
- Some buttons also have a weird behavior (Like clicking on "Friends" on the top side of the client, and clicking again doesn't close it)
TLDR: Little annoyances, but nothing that block using Steam, if something, the steam chat, since the client becomes unresponsive having that second window.
PD: People are talking a lot about the Ozone layer since Chromium 87, but I've been using it and it still has some minor things to get fixed, and I'm not sure what's the status on HW acceleration for video. (If I remember correctly Chromium 88 now comes with VAAPI acceleration for X264 videos, but it's disabled on Ozone/Wayland mode)
- in a Hidpi mode steam is blurred and the games too
1. in a Hidpi mode steam is blurred and the games too
Games should still launch as Wayland clients. At least they do for me.
1. in a Hidpi mode steam is blurred and the games tooGames should still launch as Wayland clients. At least they do for me.
AFAIK Games launch in XWayland mode since launching Wine apps natively in Wayland is still WIP.
1. in a Hidpi mode steam is blurred and the games tooGames should still launch as Wayland clients. At least they do for me.
AFAIK Games launch in XWayland mode since launching Wine apps natively in Wayland is still WIP.
Sorry, I meant games with Linux support. Those launch fine under Wayland for me.
As far as I understand, Wine won't have Wayland support any time soon...
As far as I understand, Wine won't have Wayland support any time soon...
There's https://github.com/varmd/wine-wayland and also this proposition from Collabora for Wine itself: https://www.winehq.org/pipermail/wine-devel/2020-December/178575.html
Update? Steam is still in xWayland as of today.
Update? Steam is still in xWayland as of today.
Yes, of course. Just go in settings, graphical and then "enable wayland".
Joke apart, this is not about "enabling" wayland… Could you all stop complaining or raging about the process being slow ? If you dislike the development workflow behind Steam or Steam games, you still are free to play games elsewhere.
If you are like me, waiting for wayland to completly and finaly erase and replace all X11 shit :
- subscribe to threads like this and be patient or
- work on it to make it happen
Valve decided to make Steam out of the parts they did and it's up to Valve to ensure the parts they've chosen meet design requirements. This bug is about Steam not meeting the design requirements it should, given the changing Linux landscape. It's an excuse to redirect blame, however valid that redirection sounds or looks. Valve could place the blame on a changing landscape, but that too is just an unhelpful redirection.
Xorg has already been effectively canceled. At some point it becomes essential that there is a constant pressure/outrage that no solution, even one in beta, exists. At this point we are well past waiting silently for attention. It might even be time to stand outside Valve's headquarters with signs.
The idea that one software package shouldn't be championed for, because other software exists is just wrong. I don't know how to explain this without effectively saying that everything blue is not red. I end up wanting to acknowledge that Xfree86 is a bluish red with Xorg, so it doesn't follow that bugs in Xfree86 shouldn't be championed because of Xorg. That viewpoint is valid. What's not valid is for bugs in minesweeper to be accepted because of a free-mine alternative, that's total BS. It should be obvious to everyone why that's true. I'm sure someone else will be able to explain better.
The problem doesn't actually seem to be with CEF. Steam will still launch with X if you delete ~/.steam/steam/ubuntu12_64/libcef.so and then run it with steam -noverifyfiles. The main content will just be blank.
It looks like the window is actually rendered with ~/.steam/steam/ubuntu12_32/steamui.so and it seems to be using GTK2. If that's the case, then Valve will have to update it to use GTK3 (or GTK4).
EDIT: steamui.so uses VGUI2 to render the window, not GTK2. GTK2 is only used for the libappindicator tray icon https://github.com/ValveSoftware/steam-for-linux/issues/6953#issuecomment-803413183. So, vgui2_s.so should be updated to support Wayland.
> patchelf --print-needed ~/.steam/steam/ubuntu12_32/vgui2_s.so libdl.so.2 libstdc++.so.6 libpthread.so.0 librt.so.1 ld-linux.so.2 libtier0_s.so libvstdlib_s.so libX11.so.6 libXrandr.so.2 libXext.so.6 libXrender.so.1 libGL.so.1 libfontconfig.so.1 libfreetype.so.6 libgtk-x11-2.0.so.0 libglib-2.0.so.0 libopenal.so.1 libXinerama.so.1 libSM.so.6 libICE.so.6 libXtst.so.6 libm.so.6 libc.so.6
Looks like VGUI2 is proprietary Valve software, so we're basically just in the dark on any potential future Wayland support, right?
Sucks.
Xorg is basically done for and major distributions and desktop environments are moving over to Wayland. With intermediate release 21.04 of Ubuntu and Fedora 34 being two large ones it's not as much a question of "supporting Wayland as a feature" as it is supporting Linux onward with it's shiny new display communication protocol - just as if macOS or Windows (10?) went on to newer, shinier technology.
I am very grateful of all things Valve and what has been done for Linux so far. Just wanted to chip in with a less privileged and snotty attitude of communication.
I'm confident you(valve) are aware of Wayland and its importance within Linux - take your time, open up source code if deemed useful. Other than that I'd just like to say thanks and good luck with the onward support for the new modern Linux desktop paradigm.
@kisak-valve Please, don't keep us in the dark. Just a quick update, a few words is enough :)
Hello @ChazyTheBest, friendly reminder that I'm a moderator for Valve's issue trackers on Github, and not a Valve dev myself. We'll need to hear from a Steam dev if/when there's something new to test related to this feature request.
@kisak-valve My bad, didn't read the profile note.
Steam deck is expected to be released in December. It runs plasma under wayland but steam (still) under xwayland and I've read there are a few minor problems specific to xwayland (not happening in x11). Maybe, just maybe, they intend to support wayland by then. 🤞
even X-Moto works on wayland nowadays:
https://github.com/xmoto/xmoto/issues/23
I'm having terrible performance with Steam on Wayland, very unresponsive.
I'm having terrible performance with Steam on Wayland, very unresponsive.
My guess is you do not have hardware acceleration on XWayland for some reason. That is not really related to this feature request though...
I'm having terrible performance with Steam on Wayland, very unresponsive.
My guess is you do not have hardware acceleration on XWayland for some reason. That is not really related to this feature request though...
Sorry, the games working perfectly fine with XWayland, it's the Steam app itself, i will try to search better for any solution, thanks :)
Hello @KibaGasteiz, there's a good chance you're looking for the discussion on #7245 instead of this issue report.
Hello @KibaGasteiz, there's a good chance you're looking for the discussion on #7245 instead of this issue report.
Yes, thank you, disabling animated avatars fixed it.
Steam needs this, not just for the client, but the games as well. Lutris and some other launchers support wayland completely . As of now, playing games on wine through xwayland makes the game appear to be running at half or less than half of the displayed framerate. Playing the same game through lutris (using full wayland) renders perfectly and as smooth as ever. Minecraft for example, is a terrible experience on wayland cause it uses xwayland, but someone made a patched version of minecraft with wayland suppoort and it fixes the horrible choppiness. Hope this gets fixed soon
Need is a strong word, it's more likely that you should stop using Wayland and instead base your shell off of Xorg. or more accurately, could you please use Xorg and IPv4 for the foreseeable future?
wayland is such a fun, better, and (almost) complete experience. I use multiple monitors, so it helps maintain snappiness and performance, unlike xorg. Everything just feels so much more responsive, and honestly, I only experience one bug on wayland. That's not enough for me to switch back. It's so awesome being able to run games smoothly without having to turn off the compositor and having those black bars I love it!
Could we all agree to stop feeding trolls about this eternal debate ? This isnt fun anymore
Something which I recall was not mentioned here but was brought to my attention is that Steam Overlay has hard dependency currently on X11. That needs fixing for using Wayland with any games. Making Steam client itself support native Wayland is probably not blocked by this.
Need is a strong word, it's more likely that you should stop using Wayland and instead base your shell off of Xorg. or more accurately, could you please use Xorg and IPv4 for the foreseeable future?
Gaming on native Wayland would make gaming as a whole a better experience than Windows can currently offer (and no need to mention Xorg or even X-Wayland). So, why should people stop pushing it?
Beats me... why would anyone say "keep using dead and crappy old software for the foreseeable future". please, stop discouraging people from trying/wanting better software.
Also, what does the internet protocol version have to do with any of this? Just FYI, IPv6 has been working in production for more than 10 years. The problems so far are first, greedy bastards ISPs that have been selling IPv4 addresses every time more and more expensive than the last (the other possible explanation being the engineers working for most ISPs are fkng useless, but we all know the only reason is money, same as data selling) and second, dumb lazy ass sys admins not wanting to do their job properly... they'd know that linux/network software (dhcp) configures IPv6 addresses automatically at boot time (again, for more than 10 years), the only "work" being clicking a fkng button in the hosting provider website to get the fkng range, which is free, btw. And even then, if a sys admin doesn't know how to configure the addresses manually (statically) in less than 1 min with their eyes closed then they really can't be called sys admins...
Why are you so in favor of keeping alive deprecated technologies, when the jump has been possible for some time now?
And yes, these two are deprecated. They require hacks upon hacks that not only make them sloppy but worsens the usability, quality and user experience. They were created for an older century, that alone makes them useless, not only today but they've been for a while now. Suitable alternatives were developed long ago and they are more than ready to be deployed mainstream to replace the old ones. That's more than enough criteria to declare something deprecated.
And sorry for the tone, but this is really annoying. Like pouring so many resources into deprecated software? Seems to me some people really don't care about wasting their time with useless work as long as they're getting paid... What a pity.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1160785534
Please don't bump this topic discussing with obvious trolls
Me, and most of the people following this issue, are waiting for an official feedback from Valve developers on the matter. Until then, it's pointless to discussing about it here, since we pretty sure Valve devs are already very aware of the necessity to support Wayland in the future, and in this issue we all hope to help with useful feedback once they finally decide to invest on it.
Please do keep in mind that this thread is about Steam itself supporting Wayland, not games themselves.
Games are free to implement Wayland already (Steam requires no dedicated support, other that passing down the WAYLAND_DISPLAY environment variable. But don't count on it any time soon; devs would need to target Wayland as a distinct platform, meaning the need to account for two "Linux" platforms: Linux+X11 and Linux+Wayland. I can't imagine game devs and studios taking the time to do this unless they're hardcore Linux fans who can afford to do work that will never pay off money-wise.
It is highly unlikely that existing games will ever support Wayland natively. The libraries and engines used be games would need to support Wayland and then the games need to be recompiled with those (and very likely, lots of testing and bugfixing). It sounds like a lot of work that game devs are highly unlikely to want to sink time into.
@WhyNotHugo we were having discussion about Wayland by default in SDL2 with @smcv and realized Steam Overlay which is these days more or less mandatory requires X11 and as such Steam might have to enforce X11 if default changes before Steam Overlay starts supporting Wayland. It is not as simple matter as "games just need to support Wayland separately".
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1161446917
It's at that point where running games through Wine will be "more native" than native Linux games, ironically. Wine on Wayland is a work-in-progress project at the moment, being led by Alexndros Frantzis from Collabora [1]. If one aims to run a Wayland-only system, all native games only supporting Xorg (which I presume will be almost all), will have be to be run on Wine using their Windows version. If the game is Linux-only, bad luck.
@nanonyme You're quite right. I completely forgot about the overlay, since I've only used it like twice in who knows how many years.
I guess that games targeting Wayland will have to assume there's no overlay (for now). I don't think this is a dealbreaker for many games, TBH.
The only one that comes to mind is MSFS, which requires it to pay for marketplace transactions.
The client should be a set of pure and simple elf64 binaries, which do statically load from the user system only libdl, and have undefined symbol in their elf dynsym section from only those very distributed binaries.
They would load everything they need from the system with libdl symbols (dlopen/dlsym/dlclose) and implement proper fallbacks with runtime tables of functions:
wayland (statically linked code) -> x11 (dynamic loading of xcb client libs)
vulkan->GL->cpu (only a cpu rendere may be required for the basic functions of the client).
The input key symbol state machine is provided by the dynamic loading of libxkbcommon(-x11) (the xkb configuration are provided by x11 or wayland based on user choice).
The sound is provided by the alsa-lib (pulseaudio/pipewire/jack/blahblahsoundserver are hidden behind the alsa api).
joypad: linux event devices in /dev/input
Most of this is already done in libSDL2.
This goes to show that Wayland is not well-supported and should be abandoned because of lack of adoption. The problems that plague Wayland currently is that every compositor is essentially a bespoke island and would need to be supported separately.
The lack of wayland support makes Steam near unusable. This is what is looks like in a 13" screen:
I literally have to hold the screen next to my face to read Steam's text.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1223708645
GNOME scaling works fine for me
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1223708645
See https://github.com/ValveSoftware/steam-for-linux/issues/5362 where starting steam with the environment variable GDK_SCALE=2 will increase the text render scale, useful on high-dpi/4K displays. Yes, there are related issues where fractional scaling (e.g. 1.5, 1.7, etc) do not yet work with Wayland-- but its not entirely a Steam issue.
See #5362 where starting steam with the environment variable
GDK_SCALE=2will increase the text render scale, useful on high-dpi/4K displays. Yes, there are related issues where fractional scaling (e.g. 1.5, 1.7, etc) do not yet work with Wayland-- but its not entirely a Steam issue.
In fact, after turning on the scaling according to the screen in the settings, if GDK_SCALE is not set, steam will find the appropriate scaling by itself.
Replying to [#4924 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1223708645)
See #5362 where starting steam with the environment variable
GDK_SCALE=2will increase the text render scale, useful on high-dpi/4K displays. Yes, there are related issues where fractional scaling (e.g. 1.5, 1.7, etc) do not yet work with Wayland-- but its not entirely a Steam issue.
This is not true. For example, the notoriously bad scaling in gnome is actually great in all wayland applications.
The only problem is once again xwayland. And this includes steam since there still is no wayland support. You get the expected blurry text.
So please valve, I know it isn't your priority, but now that every second distro ships wayland by default, please implement it.
Valve is getting outdated, employees must be a lot of old work tired of work without motivation and salary
Valve is getting outdated, employees must be a lot of old work tired of work without motivation and salary
Maybe they should learn from Google and Microsoft and fire thousands of workers. This old people don't deserve a job to be honest, I won't be an old guy in the future, that's gross.
Someone read the truth and did not like so I will talk otherwise these people do not feel offended.There is no point in chargeing this kind of Valve thing because it has reached her technological limit, people ask for this kind of thing since 2017, or if he has turned 6 and no one should ask for the evolution of technology, Valve has a lotMoney but the limit has come, so competition is so important to us customers.
@dinhokusanagi, no, you've just chosen to insult the group of people you're trying to get to support you, in no connection to this issue report. This is trolling, and not any form of encouragement to provoke a positive change.
This goes against the conduct guidelines for this issue tracker, specifically "Do not insult, harass, or demean anyone."
Consider yourself warned, if you choose to continue, there will be consequences.
@dinhokusanagi, your choice to continue has resulted in a 24 hour timeout.
It's not like I'm not also annoyed that this native Wayland mode is still not supported, but this dude really has to be blocked.
BTW: IIRC what we are currently waiting for is CEF implementing their native Wayland mode for applications who embed CEF in a (Non-View) custom top level window or application. This issue is tracked here and unfortunately hasn't got much attention in the last years...
So it's not even Valves direct liability that this still doesn't work, which makes the insulting comments even more inappropriate.
In addition, I don't know if Valves own windowing library VGUI, which is to my knowledge used by Steam, supports Wayland at all.
So it's not even Valves direct liability that this still doesn't work, which makes the insulting comments even more inappropriate.
CEF is an open source community driven project. So, Valve could, if they wanted to, task one of their employee developers or possibly even hire someone to develop this functionality for CEF.
I'm not familiar with the codebase, so this idea might be trash, but, has using a platform-specific webview been considered? E.g.: kinda like what Tauri does.
I'm not sure CEF gets any love at all nowadays, and wayland support is a pretty big undertaking.
So it's not even Valves direct liability that this still doesn't work, which makes the insulting comments even more inappropriate.
Of course, but this doesn't seem to be their intention (yet).
This will most likely cost them some money, and maybe they just don't see the financial benefit (which is not really that suprising as the Linux userbase in general is pretty small and XWayland works for most Wayland users more or less).
@WhyNotHugo while that is a great out of the box idea, I can easily see it taking ridiculous amount of development time to do it the switch.
Even if CEF and VGUI could be updated to support Wayland easily, Gamescope currently does not support Wayland clients, so there is no incentive here to add a Wayland backend to Steam.
IMO, it would be way more interesting to see official Wayland support for Steam games (i.e., compile the Steam runtime with Wayland support built-in), because most if not all Steam games run in X11-mode only anyway. And let's not start talking about the state of Wayland support for Wine and by extension Proton.
Wow. Very interesting timing, apparently we will get Wayland apps in Gamescope soon: Plagman/gamescope#759
Is there anything new in this regard? Are there any plans for Steam to get native Wayland support or only when the native Wine Wayland driver becomes stable?
The Steam client itself does not use Wine. Wine is only when running Windows games via Proton, so those will hopefully get Wayland support once the driver is stabilized, but Steam itself has no such requirement as far as I know.
Is there anything new in this regard? Are there any plans for Steam to get native Wayland support or only when the native Wine Wayland driver becomes stable?
This is probably the same thing as 64-bit Steam client - it will come eventually, however it is not a priority for Valve.
Its been 6 (!!!) years now, can we please get an update? Timeline? Anything?
@burghoffdavid it's been much longer for IPv6 request (still untouched), Valve has its priorities straight and this is not one of them :P
@rail01 sadly I think you are right... I still don't get it, it's not like Wayland is this "beta, super new technology", it's been the DEFAULT on both KDE and Gnome for quite some time now. There are NO EXCUSES to keep ignoring this Valve!
Even Steam already supports PipeWire, which is a newer technology
cmon valve... do something we beg you 🥺👉👈
Could you please stop with the +1 comments? There's probably hundrets of people subscribed to this issue. There have been 8 comments in the last week or two and none of them added anything new.
i think it's good to bring more attention to the issue. besides you can unsubscribe at any time so it's your problem.
We are subscribing the progress of Wayland support, not random nonsense messages.
@DeedleFake I know that Steam does not use Wine for itself, I meant that we are currently in a time where Wayland and Wine are in good shape and Linux gaming is getting better every day. There is a Wine Wayland driver in the works that will make Wine working native on Wayland. So maybe it would make sense to consider native Wayland support for Steam as well.
@jplatte First of all, one or two questions about the status are perfectly fine especially if the last comment was a while ago. I find your statement completely disrespectful and out of place "There have been 8 comments in the last week or two and none of them added anything new.". Don't get me wrong, I don't like comments on irrelevant topics either. But my comment wasn't that, I would say that right now we are in an interesting time for Wayland where we can see the end. So I would say that asking Valve if there is any progress on this is a valid point, especially considering that we are talking about Valve where they are known to be more quiet about what they are doing behind the scenes (no hate).
@Kimiblock Asking a question is part of making progress on a problem, especially in open source and on GitHub and other Git platforms.
So please, if you have a problem with this, make a custom notification rule and don't be so negative about things like this. Thank you very much.
Best regards.
We are subscribing the progress of Wayland support, not random nonsense messages.
This is so true.
Hopefully with the new UI beta we will be seeing strides towards the wayland client
I also hope for wayland. id like to see remote play and everything be native.
I really would appreciate Wayland support too. And now that this issue is open for about 6 years, please Valve, it's time...
See, unless Valve has wayland as a strict technical requirement for the viability of steam on Linux (or a commercial product requiring wayland....) there's no compelling reason for them to invest any effort in such project? Just hard reality.
The strict technical requirement is that X11 is quickly becoming "no-more"
Strictly speaking, X11 is not going away for the foreseeable future. Xorg yes, but the protocol X11 will stay with us for a while in the form of Xwayland. Because there are a lot of apps and toolkits that will not be ported to Wayland (probably ever).
That said, it's still reasonable to pressure Valve to provide us Wayland support in the Steam client and also in the Steam runtime (so that native Linux games would run natively on Wayland, if possible) and in Proton (as soon as the Collabora Wayland driver is merged in Wine).
We don't know that, the Wayland group of authoritarians is free to end support of Xwayland at any time. As they are seen as volunteers it's their right. They can on their own make life difficult for the masses and even though I can see where ppl are coming from, it's indefensible.
Edit: As this post says a lot in a few words, I'm not sure what ppl are thumbs downing. Find me on chat somewhere as this isn't the place for this discussion.
It will happen eventually but right now it is not a priority. They have better things to work on. Valve know what they're doing, they know about Wayland, and if it proves inevitable, they will make that decision. We'll get there when we get there
In the meantime, are bugs related to Xwayland going to be addressed? It's fine to "say" the Wayland group will provide support for that, but actually they are just as likely to "say" apps should be altered to support Xwayland. Both would be correct, but that answer is unsatisfying for users.
I have switched to Wayland a few months ago, and all I do now is when I buy a game and it does not work properly under Wayland I ask for a refund.
This hopefully will inform the people at Steam that they are losing money by dragging their feet on Wayland support. :)
It will happen eventually but right now it is not a priority. They have better things to work on. Valve know what they're doing, they know about Wayland, and if it proves inevitable, they will make that decision. We'll get there when we get there
It's probably gonna be implemented when Wine will have Wayland support.
It will happen eventually but right now it is not a priority. They have better things to work on. Valve know what they're doing, they know about Wayland, and if it proves inevitable, they will make that decision. We'll get there when we get there
It's probably gonna be implemented when Wine will have Wayland support.
Luckily Wine has been merging in Wine Wayland patches in the recent releases. Hopefully by the Wine 9.0 release (in early 2024) there will be solid native Wayland driver support.
There is a lot more work to get that not only into proton, but to fix issues with specific programs... that can't easily be tested because the most ppl run steam games in proton.
Having wayland support would be quite beneficial for HiDPI displays with fractional scaling. Many compositors do not support fractional scaling with XWayland.
Having wayland support would be quite beneficial for HiDPI displays with fractional scaling. Many compositors do not support fractional scaling with XWayland.
It would probably also solve a lot of displaying issues with the proprietary nvidia driver running a Wayland session too.
With XWayland there is sometimes a lot of jumping or parts of the interface to flicker which might be related to the lack of Glamour support for the proprietary driver as described here: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317
Or like:
It appears Vulkan swapchain presentation was recently merged for the Wine wayland driver, so some games should work.
To quote the developer:
With this MR you can start enjoying some of your games with the Wayland driver (either directly with Vulkan or with a D3D->Vulkan translation). Please note, however, that we don't currently support what's needed for mouselook (you will currently get erratic view movement), so most first-person 3D games are not playable yet.
@kisak-valve I understand that you are doing your job and I am very grateful for that. You are responsible for these sections and your interactions with Linux users. You can just say it, this feature (wayland support) changes the entire architecture of interaction with Steam and games. A lot of people are waiting for it. Maybe there is information about the development or consideration of this feature in the company, so to speak?
Sadly libcef and chromium’s Wayland support is… very bad compared to Firefox
Not only having input method issues, but also lacks the ability to use VAAPI hardware acceleration. These features works under X
Yeah I must agree unfortunately.
For example when using Spotify Wayland the native drop down menus are not working and the title bar looks completely alien.
So I can somewhat understand why the Steam devs have not made the switch yet.
Still, the fractional scaling support is great and would be nice to have for Steam as well.
I guess this will become more of a priority when X11 support is discontinued in Debian. It is just a pity that this issue is not being looked at now, and the various issues sorted out ahead of time.
Steam has dropped support for Windows 7, 8, 8.1 on 01-01-2024.
Part of the reason will be, that Chrome/Chromium dropped support in version 110 at 01-02-2022.
Microsoft dropped official support in 01-2020 and the extended support 01-2023.
This might be a good signal for us, as Valve can finally update the CEF to a recent version.
They also dropped VGUI2 (almost?) completely from the client.
So we might see some news about Wayland support soon, as the support in Chromium also improved a lot.
The only problem that comes into mind is the Steam overlay, but that's a different issue.
Is there a non-zero chance of Valve publishing the steam client source code under a BSD license?
Seems like a low threat way for the community to offload work off of client team.
bump. valve please add this
(disclaimer: not an admin/maintainer, no affiliation with valve)
As per the Conduct guidelines document: do not repeatedly update an open issue remarking that the issue persists.
I ask everyone to kindly refrain from adding unhelpful comments and spam subscribers' notification / mail boxes.
Thanks
+1
+1
@jthoward64 They do not care. I think Valve should introduce some moderation, and ban those who does "+1" comments. They do not respect others, so why the community should tolerate them?
I am sorry, my comment also does noise, but I want to stop the noise.
@kisak-valve would be possible to lock the comments in this issue, until we have a proper feedback from Valve?
Me and most of the others following this issue are expecting an official feedback from developers, and those people who treat git issues as Reddit aren't helping.
Personally I think would be better to remain locked (or open just for those already following this) until Valve decide to publicly announce they made a progress on it.
As it is now, we are just receiving emails about off-topic discussion and people bumping it without new useful information.
We got some kind of an official statement, just as anticipated..
Updated embedded Chromium build in Steam, clearing path for further updates soon.
Source: https://store.steampowered.com/news/app/593110/view/4161959294800836361
In fact, it would be nice to get an "official" official statement.
Manually patching the ~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.sh script to add the --ozone-platform=wayland flag and then starting steam with the -noverifyfiles flag does make the main steam window run as a native Wayland client.
However, a lot of other windows (most of them corresponding to the drop-down menus) also get automatically opened in the process and various other stuff seems to be broken.
# Patch `steamwebhelper` wrapper script to add Chromium Wayland flags
sed -i '1 aset -- "$@" "--ozone-platform=wayland"' \
~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.sh
# Run steam with the `-noverifyfiles` flag so that the patched script doesn't get reverted
steam -noverifyfiles
# Enjoy the fireworks!
But I still think this is a great progress overall and maybe with some custom windows rules it might actually become usable for some people.
Have to test the patches posted here but I would LOVE to develop VR games on Wayland. Right now it's not 100%. Valve has been great patching a few bugs for Xorg but running VR Preview in UE5 doesn't seem to work correctly just yet.
VR Room Setup is still borked for me on both X and Wayland.
Manually patching the
~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.shscript to add the--ozone-platform=waylandflag and then starting steam with the-noverifyfilesflag does make the main steam window run as a native Wayland client.
On my NVIDIA card / Arch Linux / Plasma 6.0.1,, this just results in a completely black screen :sweat_smile:
There are two XWayland windows and about...17 Wayland windows?
I was hoping it might fix the flickering issue (#10313), but no dice.
How recent is the Electron version used by Steam? Would it understand and respect export ELECTRON_OZONE_PLATFORM_HINT=wayland?
How recent is the Electron version used by Steam? Would it understand and respect
export ELECTRON_OZONE_PLATFORM_HINT=wayland?
Steam does not use Electron AFAIK, it is Chromium Embedded Framework
I was hoping it might fix the flickering issue (#10313), but no dice.
That will be addressed with the new implicit sync wayland protocol for Linux drm backend.
Steam does not use Electron AFAIK, it is Chromium Embedded Framework
That is correct.
Steam does not use Electron AFAIK, it is Chromium Embedded Framework
Then this PR is probably relevant
From PR:
CEF on Wayland is already there. It’s just it doesn’t support proper embedding (aka client is creating a wl_surface and embeds that into Chromium). If I’m not mistaken, it’s the views usage that works.
Regarding what’s missing - everything was OK except that some demo clients were not updated. But I doubt it’ll work well now is is as we have done quite a few of refactorings in the Chromium upstream so this implementation for CEF has to be revisited.
Unless Valve is working in a in-house fork of CEF with those patches merged, this one it appears to be stuck due to nobody working on it currently.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1975248612
This still doesn't work. With Xwayland support completely disabled, and doing the above trick Steam just crashes with this error:
Unable to open a connection to X
I wonder if there is any way to to launch and play wayland native games like TF2 without running the steam client on Xwayland.
I wonder if there is any way to to launch and play wayland native games like TF2 without running the steam client on Xwayland.
This seems to be possible. I haven't tried TF2, but I've definitely seen Factorio running as a native Wayland app without without doing anything special to Steam. I just had to set an environment variable for it, SDL_VIDEODRIVER=wayland according to https://www.gamingonlinux.com/2023/03/factorio-gets-official-wayland-support-on-linux/
I wonder if there is any way to to launch and play wayland native games like TF2 without running the steam client on Xwayland.
This seems to be possible. I haven't tried TF2, but I've definitely seen Factorio running as a native Wayland app without without doing anything special to Steam. I just had to set an environment variable for it,
SDL_VIDEODRIVER=waylandaccording to https://www.gamingonlinux.com/2023/03/factorio-gets-official-wayland-support-on-linux/
Yes I can run both TF2 and CS2 under wayland without xwayland, the issue is that steam itself needs xwayland.
Btw I tried launching tf2 outside of steam like so:
$HOME/.steam/steam/steamapps/common/SteamLinuxRuntime_sniper/run -- $HOME/.steam/steam/steamapps/common/Team\ Fortress\ 2/tf.sh
And tf2 ran on wayland without xwayland, but it crashes after the loading screen due to the missing steamapi.
[S_API FAIL] SteamAPI_Init() failed; create pipe failed.[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
If there was a way to run steamapi without xwayland / xorg, we could easily play games that support wayland, without the need of xwayland.
Ah sorry, I misunderstood what you were saying.
So the official page of CEF project states:
- Vote for issues in the CEF issue tracker that are important to you. This helps with development prioritization.
and this one is the issue relevant to us.
So I think it would be nice if people following this issue could go there and give a thumbs up in the first comment, to signal developers that this request is relevant to us.
(please do not spam comments asking for when it'll be ready or something like that)
Also if anyone following this issue has technical knowledge, would be great if you could help them with code and tests, because unlike the steam client, we actually have access to the source code of CEF and this could result in better feedback.
Hopefully this could speed up the implementation of a steam wayland client.
[Wayland] Implement IME support.
Running steam through gamescope on a Hyprland session with xwayland disabled works:
gamescope --steam -- env steam
Running: hyprctl clients | grep 'xwayland: 1' returns nothing when Steam is open.
Running steam through gamescope on a Hyprland session with xwayland disabled works:
gamescope --steam -- env steamRunning:
hyprctl clients | grep 'xwayland: 1'returns nothing when Steam is open.
I haven't tested but that is almost certainly just because XWayland is running inside of Gamescope now
Any progress on this?
SDL_VIDEODRIVER=wayland works for me if i boot steam with it but games dont have the overlay. otherwise its fine?
if games fail, use wayland,x11,windows
SDL_VIDEODRIVER=wayland works for me if i boot steam with it but games dont have the overlay. otherwise its fine? if games fail, use wayland,x11,windows
Has no effect for me on build 1726604483
Switching from cef to qt6 (which is the native toolkit of KDE - steamOS default desktop) would solve this issue. Plus, qt6-webengine is chrome-based and does display web content very well. Just sayin.
nah i think making steam an electron app would 100% be the most obvious solutions
:)
Still better, than relying on an ancient piece of code.
I wouldn't call CEF an ancient piece of code. It's still actively developed: https://bitbucket.org/chromiumembedded/cef/commits/branch/master
The Wayland support not being ideal is a different story.
By ancient code, I meant Xorg.
Guys this is an issue tracker and not a discussion forum. Please stop spamming everybody inboxes who want to keep an eye on this issue for an official response from a Valve employee.
Guys this is an issue tracker and not a discussion forum. Please stop spamming everybody inboxes who want to keep an eye on this issue for an official response from a Valve employee.
For the record, imho I'm not bothered by discussions of workarounds and potential fixes. It doesn't have to be from a Valve employee as long as it's actually adding something substantial to the discussion. That hasn't been the case here lately though.
KDE 6.2 released on the main branch of SteamOS. But it still defaults to X11. I believe that this makes the release of a native wayland steam client closer.
Sorry for pinging y'all but just wanted to say that spotify uses CEF and the flatpak (idk about the other pkgs) does have wayland support (Please see spotify-flatpak )
Apparently we're seeing some progress on the CEF side...
A developer made a patch that he claimed it successfully worked rendering a native wayland window.
But before this could be merged in the main CEF, the Chromium project need to accept a PR that includes the necessary dependencies.
Once this PR eventually get merged, we might start to see some fixes for some OBS resources for linux (and hopefully some progress in the long-awaited wayland version of steam)
Now that Proton-GE and every modern Unity and Godot game can run natively on Wayland it would be nice to get Steam input and Steam overlay on these games, I can't play on most controller compatible games because Steam Input doesn't work under native Wayland games.
Now that Proton-GE and every modern Unity and Godot game can run natively on Wayland it would be nice to get Steam input and Steam overlay on these games, I can't play on most controller compatible games because Steam Input doesn't work under native Wayland games.
Exactly. I use the env var to enable the wayland driver on all my games (still think its not the time to make it default tho) since they all work fine. Steam is the only reason why I have xwayland installed
As most game are available on Windows only, running them on Linux is done via Proton / wine. So outside the need for the steam client itself to support wayland, there is the need for proton to support it too.
For that matter, Vulkan supports wayland
- https://github.com/SaschaWillems/Vulkan/issues/299
- https://github.com/SaschaWillems/Vulkan/blob/master/BUILD.md#-linux
While DXVK is agnostic to this matter since it is not operating on that level.
Is there a roadmap somewhere for everything that need to be done?
Is there a roadmap somewhere for everything that need to be done?
Probably no. This is just valve being mysterious.
CEF Upstream needs to be updated to support wayland. @LinuxBoy-96 @Twig6943 I believe that is the only blocker for the steam client being on wayland. this is out of Valve's hands at the moment.
CEF Upstream needs to be updated to support wayland. @LinuxBoy-96 @Twig6943 I believe that is the only blocker for the steam client being on wayland. this is out of Valve's hands at the moment.
Spotify has wayland support?
The Flatpak is running under XWayland and not Wayland natively.
Edit: I see it has a wayland flag, but when running under said flag the window is just completely transparent much like the issues within OBS and its browser docks under wayland
The Flatpak is running under XWayland and not Wayland natively.
Edit: I see it has a wayland flag, but when running under said flag the window is just completely transparent much like the issues within OBS and its browser docks under wayland
Runs fine + xprop doesn't detect the window (Meaning its 100% a wayland window)
Can confirm, nearly every CEF/chromium application I have access to either runs under wayland by default, or does so when --enable-features=UseOzonePlatform --ozone-platform=wayland is added to the command line. This includes Spotify, VSCode, Obsidian, Discord, Signal, Chromium itself (of course), and many other smaller CEF-based programs.
This does not work with Steam. Even when I run steam with those flags, steam and steamwebhelper show up under xlsclients.
Looks like is an issue under Sway then. But this is unrelated to the issue.
Can confirm, nearly every CEF/chromium application I have access to either runs under wayland by default, or does so when
--enable-features=UseOzonePlatform --ozone-platform=waylandis added to the command line. This includes Spotify, VSCode, Obsidian, Discord, Signal, Chromium itself (of course), and many other smaller CEF-based programs.This does not work with Steam. Even when I run steam with those flags, steam and steamwebhelper show up under
xlsclients.
Discord, signal, vscode, obsidian (?) are not CEF applications, but run on Electron which is a completely different framework.
Command line arguments that work there, do not necessarily have the same effect on CEF.
The Wayland support for Spotify is also far from perfect. Try selecting an entry in the Dropdown menus in the settings for example, and you see what I'm talking about.
I guess Valve thinks the CEF implementation is not mature enough yet.
The Wayland support for Spotify is also far from perfect. Try selecting an entry in the Dropdown menus in the settings for example, and you see what I'm talking about. I guess Valve thinks the CEF implementation is not mature enough yet.
Been using spotify like this for over a year no issues. Would be cool if valve added some sort of flag at least
Can confirm, nearly every CEF/chromium application I have access to either runs under wayland by default, or does so when
--enable-features=UseOzonePlatform --ozone-platform=waylandis added to the command line. This includes Spotify, VSCode, Obsidian, Discord, Signal, Chromium itself (of course), and many other smaller CEF-based programs.
This does not work with Steam. Even when I run steam with those flags, steam and steamwebhelper show up underxlsclients.Discord, signal, vscode, obsidian (?) are not CEF applications, but run on Electron which is a completely different framework. Command line arguments that work there, do not necessarily have the same effect on CEF.
The Wayland support for Spotify is also far from perfect. Try selecting an entry in the Dropdown menus in the settings for example, and you see what I'm talking about. I guess Valve thinks the CEF implementation is not mature enough yet.
Electron is effectively just Node and a CEF-equivalent - they're different implementations, but they still both use Chromium under the hood, which is where Ozone (the layer actually implementing Wayland/X11) sits. Fair enough though. In any case, there's enough evidence that CEF as a framework supports Wayland, and if CEF is at fault, it's up to Valve to update it.
Try selecting an entry in the Dropdown menus in the settings for example, and you see what I'm talking about.
Yep, I see that - they instantly disappear when opened. While I can still use arrow keys on the dropdown at least, that's still very broken.
What about https://github.com/ValveSoftware/Proton/issues/4638 ?
IIRC, the issue is not that CEF doesn't support Wayland, but rather that it doesn't support embedding under Wayland. See: https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1975248612 and https://github.com/ValveSoftware/steam-for-linux/issues/4924#issuecomment-1998544728
Chromium seems to ready in supporting Wayland at this point. I guess this is a good indicator of progress on the building blocks for Steam client. I guess we are close to ready.
https://issues.chromium.org/issues/40083534
@kisak-valve Any update on this?
Chromium now defaults to Wayland.
CEF doesn't yet though.
i wonder if steam toast and overlay are even possible on wayland, not that i would miss it
i wonder if steam toast and overlay is even possible on wayland, not that i would miss it
Mangohud-like and a layer-shell popup don't seem difficult
Mangohud-like and a layer-shell popup don't seem difficult
Layer-shell is not for this. It's only for shell apps like panels and notification daemons.
Mangohud-like and a layer-shell popup don't seem difficult
Layer-shell is not for this. It's only for shell apps like panels and notification daemons.
yes, he was talking about the popups... mangohud for the overlay, layer-shell for the notifs
yes, he was talking about the popups... mangohud for the overlay, layer-shell for the notifs
No. Steam shouldn't use layer-shell for its notifications. Steam should send the notifications through the SNI dbus interface and the notification daemon will show them with layer-shell or whatever.
yes, he was talking about the popups... mangohud for the overlay, layer-shell for the notifs
No. Steam shouldn't use layer-shell for its notifications. Steam should send the notifications through the SNI dbus interface and the notification daemon will show them with layer-shell or whatever.
obviously they should but they are clearly unwilling, my point was that it was ali possible to replicate on wayland.
And you know who doesn't support Layershell protocol? GNOME :)
Every other popular desktop or compositor supports it.
Until GNOME decides to support it I bet this won't happen.
obviously they should but they are clearly unwilling, my point was that it was ali possible to replicate on wayland.
Steam-overlay is possible on wayland, with that I agree. But use of layer-shell by an application (as opposed to a shell component) - is a big no-no.
And you know who doesn't support Layershell protocol? GNOME :)
Every other popular desktop or compsitor supports it.
Until GNOME decides to support it I bet this won't happen.
Honestly the first time this has been a good thing, valves notification system is horrible.
obviously they should but they are clearly unwilling, my point was that it was ali possible to replicate on wayland.
Steam-overlay is possible on wayland, with that I agree. But use of layer-shell by an application (as opposed to a shell component) - is a big no-no.
Is there anything preventing it though?
Is there anything preventing it though?
Currently nothing AFAIK. Only policy. But it's supposed to be a privileged protocol. Or even more restricted than that, limited to only specific clients.
The compositor may choose to restrict this protocol to a special client
launched by the compositor itself or expose it to all privileged clients,
this is compositor policy.
https://chromium-review.googlesource.com/c/angle/angle/+/6164683 seems to be the last puzzle piece before valve just needs to do it
It's 2026, and native Wayland hasn't came yet to Steam, where many other applications does, and with most compositors already supporting Wayland as either default/stable, or experimental.
That is quite depressing, and such matter should been given attention by Valve, especially with their machines which will use Linux -- are they going to keep with Xwayland "forever"?
We sould make a list of everything that is missing to make this possible to at least keep track of the progress on that matter.
I would like to say that ranting, in general, are of no use. People need time to work.
The current blocker, if you didn't gather from previous comments, is that Chromium Embedded Framework (CEF), that Steam Client based on, do not support Wayland yet. And the working branch for this is on the merge request 6164683. The work was started in 5th Jan 2025. 3 patchset was added in Jan and then things seems to stop on it. It might be because the developer (jwinarske) had other priorities. Or he might be working on it a while and got stuck. He announced on 5th Dec 2025 that he will get back to work on this.
Might I add development of such feature do not fall from a tree or magically appear in front of a pile of cash. It takes time to things right. That is to keep the software out of bugs and be backward compatible. The current patchset seem to break non-wayland build. And that's why it is not merged yet.
The best I think we can do is either:
- Wait for jwinarske; or
- Help with the coding and testing.
I am one of the eagerly waiting people like probably all of the people here. I am using a Wayland desktop everyday. I understand the urge. I had my fair share of ranting in the past. But in the end, I have to understand lashing out on people never help. And I'd keep these to myself. I'd mildly suggest all fellow gamers / linux users to do the same.
It is sure that he (jwinarske) is doing his best to allow this to happen, however, it is quite curious how that was left behind -- not by him, but by CEF devs and Valve.
Not that I blame the CEF devs, quite the opposite, bugs are surely higher priority than a matter of native compatibility, to avoid the usage of Xwayland, but Valve which benefits from this, hasn't contributed much themselves, or actively spoken about that -- transparency is key, and they don't seem to be doing that (for ref, the last message of a Valve dev here was from 2023, that is around 3 years ago)
So, yes, people need time to work, but it has been quite a lot of time already, way too much, and Valve should (as they have all the resources and money to, and do earn money from it) contribute to this matter be resolved more quickly.
Again, I am not criticizing any Valve or CEF dev, as I am very grateful for their work, however that won't stop people from getting frustated on an issue that has been around for so many years.
Valve which benefits from this
Do they? It’s not like anyone runs off to use Epic instead.
Do they? It’s not like anyone runs off to use Epic instead.
Well, as far as I know they didn't have to pay money to use it, where they would if they had to build a similar framework.
Yeah... 10 years later I tend to avoid the gamescope as much as I can, sadly. Frame timings with xwayland are just awful. Especially when Pronot natively supports wayland now. Hope this gets more attention.
Edit: I am so sorry, I was looking for the gamescope wayland client support and accidentaly replied here!
Seems like the newest SteamOS version is now defaulting to Wayland. Now the issues should become very noticeable there.
Which I hope it means we will get proper Wayland support soon~ish.
Having Steam running in wayland removes some painful hurdles and hoops Valve has to go through with regards to HDR and gamescope. I'm sure Valve wants to replace x11 with a wayland native client. It's the only logical step forward.
steamos 3.8 will be wayland by default, i'm sure they are working on it
Manually patching the
~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.shscript to add the--ozone-platform=waylandflag and then starting steam with the-noverifyfilesflag does make the main steam window run as a native Wayland client.
I still try this every once in a while, and while it’s still insanely broken (it opens about a dozen extra blank windows, web sites (including the store) don’t work, menus don’t work) it is so. incredibly. satisfying. to have my library display in all it’s 4k glory instead of blurry 1080p …
to have my library display in all it’s 4k glory instead of blurry 1080p …
Well, you can do it without patching Steam. Just use
"org/gnome/mutter/experimental-features" = ["scale-monitor-framebuffer", "xwayland-native-scaling"]
(if your 1080p blurriness is because of the fractional scaling on Gnome)
Manually patching the
~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.shscript to add the--ozone-platform=waylandflag and then starting steam with the-noverifyfilesflag does make the main steam window run as a native Wayland client.I still try this every once in a while, and while it’s still insanely broken (it opens about a dozen extra blank windows, web sites (including the store) don’t work, menus don’t work) it is so. incredibly. satisfying. to have my library display in all it’s 4k glory instead of blurry 1080p …
How do you exactly patch the file, if you don't mind me asking?
How do you exactly patch the file, if you don't mind me asking?
Editing the file ~/.local/share/Steam/ubuntu12_64/steamwebhelper_sniper_wrap.sh:
exec ./steamwebhelper --ozone-platform=wayland "$@"
Since these files are actually SUPER predictable, I've cooked up a quick and dirty "patcher"
It, renames the steamwebhelper to steamwebhelper.real, creates a steamwebhelper script for injection which checks for a flag so you can still run it normally as needed, creates two .desktop files, SteamW.desktop (wayland) and SteamX.desktop (xWayland), and this will be added to your startmenu for whatever DE you're using. Which should make it just, run the script every update, and you're good to go.
Is there a current way to force SteamOS’s GameMode to exclusively run through Wayland instead of xwayland, or is that something we just have to wait for Valve to implement on their end?
Regarding CEF's Wayland support :
13th of May 2026 -
Dianda Lin - I'd like to help get Wayland support landed. Joel, are you still able to drive this, or would you be okay with me picking up the remaining review comments and pushing new patchsets?
Shahbaz Youssefi - This has been stalled for more than a year now, I'd say go for it (unless somehow Joel's just got back to this).
https://chromium-review.googlesource.com/c/angle/angle/+/6164683?tab=comments
If you are wanting to keep track of this, the new CL is: https://chromium-review.googlesource.com/c/angle/angle/+/7844989
Wayland support merged for CEF!
Wayland support merged for CEF!
Not yet
What was merged is a dependency, so the code made by @jwinarske could work with CEF. The issue remains open
What was merged is a dependency, so the code made by @jwinarske could work with CEF. The issue remains open
If I'm correct the patch that got merged is a direct fork of jwinarske's patch, so his patch doesn't need to be merged anymore because the more complete fork of his patch just got merged
What was merged is a dependency, so the code made by @jwinarske could work with CEF. The issue remains open
If I'm correct the patch that got merged is a direct fork of jwinarske's patch, so his patch doesn't need to be merged anymore because the more complete fork of his patch just got merged
Yeah it seems that was actually the wayland support that got merged but only time will tell whenever it will get to steam.
If I'm correct the patch that got merged is a direct fork of jwinarske's patch, so his patch doesn't need to be merged anymore because the more complete fork of his patch just got merged
What was merged is a patch that makes Angle compatible with Wayland. You can check this post for context.
But in short:
- Steam needs CEF to be compatible with Wayland (allegedly)
- jwinarske claimed he managed to run CEF with wayland
- In order to make his code work with main CEF, he needed to have Angle compatible with wayland first
- He posted a MR to chromium, but it was (allegedly) abandoned, so someone else made a fork and got it merged (we are here)
What still needs to happen:
- jwinarske still need to send a MR to CEF
- CEF still needs to approve it and make a new wayland compatible release
- Applications who depend of CEF (like Steam, Spotify, etc..) will need to update to said release
It's important to remind you all that this CEF situation doesn't necessary mean we'll get / won't get a Wayland version of Steam, we're only speculating about it because Valve itself is avoiding the subject.
Valve could send a beta update tomorrow saying "Here's our wayland compatible client", in the same way that they could still not do anything even with the CEF fully patched.
CEF being wayland compatible is only a component that could get us near that.
- Applications who depend of CEF (like Steam, Spotify, etc..) will need to update to said release
Spotify uses CEF and runs perfectly on Wayland already
Spotify uses CEF and runs perfectly on Wayland already
Runs yes. Perfectly no.
Now that Wayland has an upstream Angle option, CEF needs Angle enabled for Wayland etc.
Not really "ideal". But I've been running Steam (Windows) through winewayland with some recent cross progress rendering work someone have been making and sharing for people to test at the CachyOS community discord. It works fine in my system.
If anyone wants to try by themselves:
Everything is done now, right? 🤞
https://chromium-review.googlesource.com/c/angle/angle/+/8073441
Gaming on wayland is becoming the mainstream with proton/wine supporting wayland. Linux distros are shipping wayland.
I do not see why this is not a thing yet.
Spotify uses CEF and works under wayland. Why cant we get the same with steam?
This is a good time to start supporting wayland.
Gaming on wayland is becoming the mainstream with proton/wine supporting wayland. Linux distros are shipping wayland. I do not see why this is not a thing yet. Spotify uses CEF and works under wayland. Why cant we get the same with steam? This is a good time to start supporting wayland.
Let me guess you bumped this because of the vid brodie just uploaded xD
Gaming on wayland is becoming the mainstream with proton/wine supporting wayland. Linux distros are shipping wayland. I do not see why this is not a thing yet. Spotify uses CEF and works under wayland. Why cant we get the same with steam? This is a good time to start supporting wayland.
Let me guess you bumped this because of the vid brodie just uploaded xD
I don't know who you are talking about tbh. I bumbed this because I switched off xwayland on my hyprland configuration to later found out that all my applications including discord (vesktop), spotfiy, firefox (zen), lutris, and my password manager are working fine. But steam can't even launch. I was in the process of moving strictly to wayland since most of the applications I use on the daily driver supports wayland. I only run xwayland because of the games. This is why I bumped this.
Xwayland is bad https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/
Sure it's not a lot, But Why should I use Xwayland or allow apps to use it when I already have wayland working?
This is called bloat. And I don't like that.
This was surprising to find out that steam client doesn't support wayland while proton does.
If the software was open source I would happily implement the Wayland support…
If the software was open source I would happily implement the Wayland support…
Just do what you can with CEF and see if Valve do their part. Keep up the good work.
C'mon steam, you old geezer, it's 2026!
People, please, please, please stop spamming in comments. Do you understand that such comments are got notified to everyone who is subscribed to the bug?
Possibly, it does not work this way. This should be human moderated, and such spam comments should be deleted, and posters blocked for some time.
@VixiKitsune Github issues are not Reddit, it's a place to discuss news and technical subject related to the issue.
Please stop bumping this topic without necessity, there are a lot of people who are subscribed to this issue and receive notifications every time someone post here.
@VixiKitsune
If Valve doesn't care about Wayland, then any insults you post here will simply be ignored by them.
However, your insults will spread negativity to all the regular users subscribed to this issue.
Please stop this behavior—pretending to act in the name of justice when you're really just venting your personal frustrations.
If you use this library the majority of the work is already done:
https://github.com/jwinarske/wayland-cxx-scanner
It would take less than a day to implement. Seriously.
https://docs.github.com/en/communities/maintaining-your-safety-on-github/reporting-abuse-or-spam#reporting-a-user
I just reported VixiKitsune spam. In case you want to do the same, use "Spam or inauthentic Activity" as a problem category. Also, you can link his comment, and indicate misbehavior (posting series of nonsense comments after being asked to not do so).
P.S. I am sorry to post once another post. Just wanted to give a link for reporting abuse for those who search for it.
Please don't get this thread locked in case the community has an actual progress update to post.
fully agree. Where possible, always use pure wayland without xwayland.
https://www.newinlinux.com/the-dream-of-steam-on-wayland-just-got-closer-to-reality/
Games running on Wayland through Proton-GE fork soon get support for Steam Overlay and Steam Input!
https://nitter.net/GloriousEggroll/status/2090300144151372032
Games running on Wayland through Proton-GE fork soon get support for Steam Overlay and Steam Input!
https://nitter.net/GloriousEggroll/status/2090300144151372032
Just note that work was heavily assisted by IA.
Launch options
SDL_VIDEODRIVER=waylandx4 2024-10SDL_VIDEODRIVER=wayland`x3 2024-06SDL_VIDEODRIVERx1 2018-11SDL_VIDEODRIVER=wayland?x1 2018-09
Upstream links
- ValveSoftware/steam-for-linux/issues/4924x7 2025-07
- ValveSoftware/Proton/issues/4638x2 2025-07
- doitsujin/dxvk/issues/1592x1 2025-06
- doitsujin/dxvk/issues/4692x1 2025-06
- ValveSoftware/steam-for-linux/issues/5362x1 2022-08
- ValveSoftware/steam-for-linux/issues/6953x1 2021-03
This is feature request
This will greatly help users with multi-gpu setups like optimus / SLI and developrs to move forward with wayland adoption