# Valve Is Making Some Big Changes To Steam On Linux ## Метаданные - **Канал:** Brodie Robertson - **YouTube:** https://www.youtube.com/watch?v=6KX58rBgy7s ## Содержание ### [0:00](https://www.youtube.com/watch?v=6KX58rBgy7s) Segment 1 (00:00 - 05:00) Guys, I can't believe it is actually happening. Whilst I do love the work that Valve has done for Linux, it has brought gaming actually to Linux. Yes, WINE already existed, but actually made it easy and viable for the average person. There are some things that they kind of lag behind on that the rest of us on Linux have been doing for a very, very long time now. And some of that is changing, likely due to the Steam Machine and the Steam Frame coming up this year, but who cares about why? So this is a recent update to SteamOS. 3. 8. 0 preview, second clutch. Firstly, we have initial support for upcoming Steam Machine hardware. So this means sometime this is happening. Basically, they are moving their testing of the Steam Machine hardware onto the production version of SteamOS. When this means it's actually going to have the hardware come out, I don't know, but it means we are getting somewhat close. Hopefully this year, but maybe not hopefully this year, considering how much it's probably going to cost with RAM prices being the way they are. But that is not what I want to talk about. Right down here in the middle of the page, desktop mode. KDE Plasma updated to version 6. 4. 3 from 6. 2. 5, which is still not the most up-to-date version, very far from the most up-to-date version. However, it now uses Wayland by default. But that is not the main thing I wanted to talk about. And KDE Plasma updated to version 6. 4. 3 from 6. 2. 5, which is still very far from the most up-to-date version. They're being very conservative on what version they run, probably doing a lot of internal testing to make sure things are stable. But more importantly than that, now uses Wayland by default. Take note of the by default there. Let's scroll down just a bit further. Under developer, desktop mode now uses Wayland by default. X11 Support may still be selected via Steam Developer Settings or via the SteamOS CTL. If for some reason you still want X11 on your Steam Deck, that is still there. That is still fine. You can use it. But pretty much everybody else is going to be using Wayland now. So you probably know that KDE split the X11 session into an optional dependency. So now if you install KDE, you don't actually have to have X11 available whatsoever. This does produce some interesting numbers where on Arch Linux, we now know exactly how many people go out of their way to install X11 and the number is somewhere around 10 to 15%. But with that change, come sometime in 2027, KDE will be completely dropping support for the X11 side. What then happens for SteamOS is kind of a mystery. Now, considering they are defaulting to Wayland, they're not going to obviously default to something they know is going to give their users a bad experience. So from their perspective, and from my perspective as well, it's pretty much fine for the majority of users. But as we saw, they are lagging really far behind on updates. So even when that update comes out that completely drops X11 support, that's still going to be present on SteamOS. How long that's going to be the case and how long it takes them to get to a version that doesn't have X11 support? Honestly, it could be six months, a year. I don't really know. Going to this version, even though it isn't the latest version, does come with some nice additional things that do make a lot of sense for the Steam machine. Improved support for rotated displays, which is something that every desktop struggles with. If you like vertical monitors, hey, that's cool. Better scale factor out of the box on TVs. Add support for external HDR displays. Add support for VRR displays. And support for per display scale factor. All of which are quite nice. Also fixing various performance issues in the desktop mode that were also there. Now, the Steam frame is also going to have a desktop mode available. I'm not sure how exactly they are handling that. Because obviously, Plasma, doesn't have a VR mode. There is that like third party VR patch that was being worked on for a while, not related to what Valve is doing. But I don't know if they're just going to have a big virtual display, or they're going to try to do something else with it. All I know is doing it in Wayland is probably going to make that considerably easier. ### [5:00](https://www.youtube.com/watch?v=6KX58rBgy7s&t=300s) Segment 2 (05:00 - 10:00) There is one more change that is really cool, but maybe not as cool as you might initially think when you first see it. From gaming on Linux, new Steam beta can run the Linux client inside a 64-bit container. Going over to the update page on the Valve website, we have the Steam client beta March 19th. There's a bunch of other random things we don't really care about here. We care about the Linux Steam RT3 beta. The Steam client on Linux can now be run inside a Steam runtime container. This will help the Steam client provide a more consistent experience across multiple distributions. This is the same technology we use for Steam games. So like how you run a native Steam game inside of the Soldier runtime, or the Sniper runtime, or whichever runtime you happen to need for that game, this is going to run the Steam client itself inside of a Steam runtime container. So one of the problems that Steam has is you have to have it working across every distribution, right? And it's fine on Ubuntu. It's fine on Arch. But that doesn't just come magically. It relies on dependencies like any other application is going to rely on. So some distro is going to have weird packaging problems where they have weird out-of-date dependencies or dependencies that are too new and all of these weird things where it just makes issues for both the Steam developers and the distro developers. So the aim here is to make the experience across Ubuntu, Arch, Debian, SteamOS, all pretty much as similar as possible by just providing everything Steam needs to run inside of a little container. Do note, it is container, not a sandbox. So some of you might point to the Steam Flatpak. This is both a container and a sandbox. It is a container. It has the dependencies needed to run the application. It is a sandbox. It stops the application from accessing everything on your system. You might notice this is unverified because this is not a Flatpak made by Valve, made by the Steam developers. Over the years, Valve engineers have pretty much said they don't want to deal with Flatpak. They're like willing to consider it over some other options, but it's not a recommended way to install Steam. They already sandboxed their games. So putting a sandbox inside of a sandbox, things can get a little bit funky there. Also, over the years, the Flatpak sandbox has broken some functionality within Steam. I know at one point, VR just didn't work in the sandbox, for example, and various other things have caused an issue. Basically, Valve are not planning to officially support the Flatpak anytime soon. And if I understand it correctly, this change basically eliminates the need for the Flatpak. The Steam RT3 beta client is distributed alongside the regular beta client. You can opt into the beta client via the Use Experimental Steam RT3 Steam Client Toggle in Settings Interface. That is right here over into the picture. Do note, okay? Do note right down here. This is a beta client. Now, most Steam beta clients are fine and they're not going to crash cause issues, but it is a beta, okay? Things might go wrong. Your Steam client might crash. It might not open. Things might go wrong for you. So test it out. If it's okay, use it. If it's not, report bugs and don't use it. And the big one, the Steam RT3 beta client has been updated to 64 bits. The new Steam client is 64-bit. Finally. Finally, it is 64-bit. So this is following an update that happened on the Windows side back in December. Steam client update December 19th. Right about here. The Steam client is now 64-bit on Windows 11 and Windows 10 64-bit. Systems running 32-bit versions of Windows will continue receiving updates to the 32-bit Steam client until January 1st, 2026. So about three months ago now. But on Windows, the Steam client is 64-bit only. On macOS, it's been the case for a very long time, actually. At the time this happened, I was asking, hey, when is this going to happen on Linux? We didn't know. And now we do. Well, okay. We know when it's in the beta. We don't actually know when the beta update fully releases, but it should be a couple of weeks. Now, don't be too excited, okay? Whenever this topic comes up, there are two things people constantly misunderstand. ### [10:00](https://www.youtube.com/watch?v=6KX58rBgy7s&t=600s) Segment 3 (10:00 - 15:00) Firstly, this means we can finally do away with the 32-bit dependencies on our system, get rid of all the multilib stuff, because Steam is basically the only thing that still needs the multilib stuff. On the flip side, this means my 32-bit games will no longer work. So, when it comes to the 32-bit dependencies, the Steam client being 32-bit was annoying, okay? And that was something that did need the 32-bit dependencies. The far more annoying problem were the games. Not because dropping 32-bit would break the games, but because there is a solution to play the 32-bit games on Linux, and Valve knows the solution exists, but they aren't using it. When we are talking about native games, so a game that has a Linux executable, that's not a concern. That is the whole point of the Steam runtime, to provide dependencies, to provide the environment for a native game to run, and not have to worry about what you're doing on your system, because in the past, we'd have a native game where it was built against Ubuntu 10. 04, and then after that point, good luck! Good luck and see what happens. But now you build a native game against a specific Steam runtime, and as long as that runtime is available, the game should theoretically always work. But No Tux, No Bucks is long dead, and most of the games we play on Linux are Windows titles. They're Windows titles we play through WINE, or in the Steam case, the fork of WINE, called Proton. To ensure 32-bit games worked with WINE, this is why we had the 32-bit dependencies available. However, when I say there is a solution available that Valve wasn't using, this is what I am talking about. So, there is a system in WINE called Wow64. Basically, it lets you run 32-bit Windows software inside of a 64-bit version of WINE, which, WINE, again, is what Proton uses, and in WINE, okay, in regular old WINE, you've been able to use Wow64 for a long time now, and so much so that about a year ago, Arch Linux did enable it by default. However, and this is why Proton hadn't been using it, it has some issues. Firstly, OpenGL performance. 32-bit applications are gonna run a bit slower than they otherwise would if you're running them natively. When we're talking about anything else is pretty much fine, but for OpenGL performance, it is gonna be a little bit scuffed. The more annoying problem existing 32-bit prefixes need to be recreated. So a prefix is the environment that you're running the game in. So each game has their own separate WINE prefix, their own separate WINE, their own separate Windows system, effectively, that the game is being run inside of. If you go from native to 32-bit WINE compatibility with WoW 64, those old prefixes don't just work. So they have to be recreated, and if you're modding games, if you're doing things like that, like, it can be a little bit scuffed. With Steam Cloud saves, your save files are pretty much fine, but it's not something that they just have a guaranteed conversion system working for. They're probably looking at a way to deal with that, because I don't think they're just going to at some point say, okay, your 32-bit games, we don't care, just deal with it yourself. So they're probably spending a lot of time trying to work out a clean migration path where the user can just click play, and everything is fine. Now, we know for a fact they are testing things, and if you are okay with things breaking, what you can do is use proton use wow64 as an environment variable, and it will go and use that. Again, do note, you have to be on proton10 or newer, or proton experimental, this is from a year ago, so any reasonably up-to-date version of proton is going to be fine. Also, your 32-bit prefixes will need to be regenerated, this is not going to fix things for you, so, yeah. But, we know they're at least playing with it, so hopefully it some point, that's no longer a problem. However, in the current state of proton, it still does need those 32-bit dependencies, those multi-lib ### [15:00](https://www.youtube.com/watch?v=6KX58rBgy7s&t=900s) Segment 4 (15:00 - 17:00) dependencies, for those older 32-bit games. Even though that option is there, it is not the default setting. Whilst the Steam client itself eliminates the 32-bit dependencies, the thing you actually care about, playing the games, that still has 32-bit dependencies, and multi-lib is sticking around at least for a while longer. Hopefully, by, I don't know, the next major version of proton, maybe the version after that, finally, we can actually change this, but we'll have to wait and see. There's one more little thing, but this one isn't actually happening. So, whilst SteamOS is going Weyland, what about the Steam client? So, this is a problem. This is the same problem for why OBS browser docs do not work on Wayland. It actually has nothing to do with the project, it has dependency. CEF, the Chromium Embedded Framework, for, this has been reported for six years now, seven years now, actually, seven years now, six and a half years, we'll say. It just doesn't work on Wayland. There's been maybe three or four different patches to fix this, and for one reason or another, whether it doesn't get fixed, whether it has a little bug here and there, it's still a problem on Wayland and it still doesn't work, and it's pretty much the major blocker for Steam. Hopefully, at some point, that gets resolved, so then we don't need XWayland for Steam. Also, if you run the games inside of Gamescope, you could then just run them entirely with Wayland, or there is the WINE Wayland stuff where you can actually run your WINE games, your Windows games, in a native Wayland window, so we're actually getting to a point where you could possibly, eliminate XWayland from your system. It's not, like, soon, it's not guaranteed to be happening like in a year or two, but we are getting very close to that actually being possible. With that being said, let me know your thoughts down below. Do you care about these changes? Do you care more about the 64-bit change or SteamOS going Wayland first? I'd love to know, and would you like the Steam client to also be Wayland first? So, let me know your thoughts down below. If you liked the go like the video, go subscribe as well, and if you really liked the video, and you want to become one of these amazing people over here, check out the Patreon, SubscribeStar Liberapay linked in the description down below. That's going to be it for me, and they are running out of --- *Источник: https://ekstraktznaniy.ru/video/23253*