We also need a native Wayland client for Steam, though it’s tied to Chromium Embedded Framework’s native Wayland support. Probably it will come with Electron’s support. No idea when.
It’ll be more performant, lower latency, have proper HDR support (current method is a hack), scale properly based on your displays, and probably be generally less buggy long-term (probably more buggy when it first gets added since it’s a pretty fundamental change).
You’re currently using a compatibility layer called xwayland to run it, which adds a ton of cruft.
Yes, but it’s a hack, when it’s properly implemented you won’t need gamescope and it won’t have to be fullscreen as far as i’m aware, although i could be wrong about the fullscreen thing.
Ah, I guess the HDR support in Wayland is still exposed via an “experimental” interface. But it looks like a handful of Wayland compositors support it, including wlroots which a bunch of smaller compositors are based off of.
No way. Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.
It makes running additional programs harder (opentrack for example)
Then we need better tooling and documentation to interact with the container, not to get rid of them. I don’t see any technical limitation that would prevent your use case. It’s just not implemented or maybe simply undocumented.
our computers less ours
How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.
Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.
We are going through more or less Wine anyway, the libraries on the system don’t matter as long as Wine compiles
In ideal world it would be pure Wine, with Valve putting merge requests for things they want to change, instead of another EEE that’s only waiting to happen. More like AMD interacts with kernel driver. Valve already runs SteamOS, they can use it to have a stable 100% supported platform for their decks etc
better tooling and documentation to interact with the container
One of the core features of containers is process and process memory separation from host. So in case of headtracking (accessing game’s shared memory), containerization is directly working against it working. It’s not the tooling, it’s the choice of what to use
Linux has had chroot since a long time if we are really afraid about supporting dwindling native client games
How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.
We have no control over what they put in those containers. Similar (to put perspective) as we have no control over what Google does in their Gapps (and app developers neither have!), So far we can go inside and inspect what are they running apart from the game’s exe directly. Once they disable the PRESSURE_VESSEL_SHELL=instead we will have no insight into what’s inside. And the other option - if it doesn’t work for some reason (with Wine I don’t really see it happening as what we run doesn’t rely on our OS libraries directly), you can create chroot, additional library packages with old versions, etc. Worst case scenario, Linux community will figure something out
We are going through more or less Wine anyway, the libraries on the system don’t matter as long as Wine compiles
Which wine though?
The one pre-packaged by your distro? That doesn’t work because Valve needs to control the version you use and to provide additional stuff not part of vanilla wine.
The one part of proton that is built and delivered to your system by Valve? They would have to compile and support it for every set of dependency versions out there.
One of the core features of containers is process and process memory separation from host.
As far as container technology is concerned, the isolation is configurable. pressure-vessel is most likely using (possibly indirectly) namespaces and/or cgroups to achieve the isolation. I don’t see a technical reason that you can’t disable the isolation of shared memory or any other resource. The issue is whether you are given access to disable it.
According to the docs the runtime is based on flatpak and uses bubblewrap and libcapsule. I don’t know about libcapsule, but I recall that bubblewrap has granular control over what resources it isolates.
We have no control over what they put in those containers.
Apparently, you can modify the container as shown here. But there’s no reason why you shouldn’t be able to install custom containers alongside the default ones in the same way that you can install custom proton versions. Steam just doesn’t provide the interface for it.
Once they disable the PRESSURE_VESSEL_SHELL=instead we will have no insight into what’s inside.
There already exists an alternative that is “more likely to be extended in future” rather than being removed as shown [here](more likely to be extended in future). But I believe you would always be able to gain access to the container because it remains a chroot + namespace + cgroup isolation, all of which you can control on your system.
and app developers neither have!
App developers don’t control what’s on your system either. The container is a huge improvement for them because it at least gives them a known target to build for. They can still bundle dependencies in any way that they would on a non-containerized system. There’s no loss of control from their perspective.
if it doesn’t work for some reason (with Wine I don’t really see it happening as what we run doesn’t rely on our OS libraries directly), you can create chroot, additional library packages with old versions, etc.
That’s what pressure-vessel is and as shown above you can modify it. And if you couldn’t it would be a tooling issue, not an inherent container disadvantage.
Worst case scenario, Linux community will figure something out
No, they won’t. Compatibility significantly increased after Valve got involved. In fact, the linux community is porting pressure-vessel outside of Steam to use it across different launchers as umu. The community is headed towards using pressure-vessel for everything.
Now I replied to each claim individually, but it’s not really about any specific point you’re making. The general idea is that there’s nothing inherent to container technology that prevents you from tinkering with it. Anything that you can’t do currently is because Steam is not designed to allow you to do it. It’s got nothing to do with whether Steam uses containers or not. Any control that you’ve lost over your system is because you’re using a proprietary app. They could remove the containers and still prevent tinkering, eg by using a bundled wine with no way for you to modify it or its launch options. It’s not about what Steam does, but about how it does it.
Does it? What containerization does it use? I thought it was similar to wine, just a process pointed at a windows exe, and an environment to make the app think it’s running in a windows filesystem.
It’s a custom solution called pressure-vessel, which seems to be based on flatpak. You can read about it here. This is used to create a reproducible linux environment and has nothing to do with the windows translation layer. They run wine (proton) inside the container as you would expect.
There is a recent effort to port this solution outside of steam in the form of umu. As far as I know it’s in a working state but I don’t know if it’s at feature parity with steam, especially on the game-specific fixes front. The end goal is to be a universal launcher that can be used from all frontends, so that all windows games run reliably and identically regardless of which GUI you use to manage your games.
EDIT: welp, I just now noticed this info has already been posted by another user 🤷
Something internal. In order to run a third party app with access to the process (like headtracking), the only way I’ve found out to achieve that was to download a windows version of opentrack too and run it twice. One on Linux side, one inside the container and make them talk to each other via UDP
I really hope Proton 10 will have some sort of Wayland support, even if it would be hidden behind an environmental variable
We also need a native Wayland client for Steam, though it’s tied to Chromium Embedded Framework’s native Wayland support. Probably it will come with Electron’s support. No idea when.
Could you elaborate on the advantages, I’m using wayland and steam for games, no issues so far.
It’ll be more performant, lower latency, have proper HDR support (current method is a hack), scale properly based on your displays, and probably be generally less buggy long-term (probably more buggy when it first gets added since it’s a pretty fundamental change).
You’re currently using a compatibility layer called xwayland to run it, which adds a ton of cruft.
HDR support
Doesn’t valve already use gamescope (Wayland compositor) with HDR support? And KDE?
Yes, but it’s a hack, when it’s properly implemented you won’t need gamescope and it won’t have to be fullscreen as far as i’m aware, although i could be wrong about the fullscreen thing.
Ah, I guess the HDR support in Wayland is still exposed via an “experimental” interface. But it looks like a handful of Wayland compositors support it, including wlroots which a bunch of smaller compositors are based off of.
Even with support from the compositor, you need support for it in every part of the graphics pipeline.
Currently you can either use Wine with Wayland + Vulkan layers + KDE or gamescope + KDE (or gamescope directly in TTY).
wlroots doesn’t support HDR.
Ooo, the MR it links to is 10mo old and still open.
And the most recent comment indicates that it’s not currently being worked on by someone.
Fractional scaling
xwayland*
I really hope Proton would stop running a container. It makes running additional programs harder (opentrack for example) and our computers less ours
No way. Containers are absolutely necessary to provide reliability across a wide range of distros and to keep games working in the future.
Then we need better tooling and documentation to interact with the container, not to get rid of them. I don’t see any technical limitation that would prevent your use case. It’s just not implemented or maybe simply undocumented.
How so? The end result is probably the opposite. Without the containers Steam would be less reliable on unsupported distros, which might mean your only choice would be to use Ubuntu LTS. That would be a much bigger loss of control.
We are going through more or less Wine anyway, the libraries on the system don’t matter as long as Wine compiles
In ideal world it would be pure Wine, with Valve putting merge requests for things they want to change, instead of another EEE that’s only waiting to happen. More like AMD interacts with kernel driver. Valve already runs SteamOS, they can use it to have a stable 100% supported platform for their decks etc
One of the core features of containers is process and process memory separation from host. So in case of headtracking (accessing game’s shared memory), containerization is directly working against it working. It’s not the tooling, it’s the choice of what to use
Linux has had
chrootsince a long time if we are really afraid about supporting dwindling native client gamesWe have no control over what they put in those containers. Similar (to put perspective) as we have no control over what Google does in their Gapps (and app developers neither have!), So far we can go inside and inspect what are they running apart from the game’s exe directly. Once they disable the
PRESSURE_VESSEL_SHELL=insteadwe will have no insight into what’s inside. And the other option - if it doesn’t work for some reason (with Wine I don’t really see it happening as what we run doesn’t rely on our OS libraries directly), you can create chroot, additional library packages with old versions, etc. Worst case scenario, Linux community will figure something outWhich wine though?
The one pre-packaged by your distro? That doesn’t work because Valve needs to control the version you use and to provide additional stuff not part of vanilla wine.
The one part of proton that is built and delivered to your system by Valve? They would have to compile and support it for every set of dependency versions out there.
As far as container technology is concerned, the isolation is configurable. pressure-vessel is most likely using (possibly indirectly) namespaces and/or cgroups to achieve the isolation. I don’t see a technical reason that you can’t disable the isolation of shared memory or any other resource. The issue is whether you are given access to disable it.
According to the docs the runtime is based on flatpak and uses bubblewrap and libcapsule. I don’t know about libcapsule, but I recall that bubblewrap has granular control over what resources it isolates.
Apparently, you can modify the container as shown here. But there’s no reason why you shouldn’t be able to install custom containers alongside the default ones in the same way that you can install custom proton versions. Steam just doesn’t provide the interface for it.
There already exists an alternative that is “more likely to be extended in future” rather than being removed as shown [here](more likely to be extended in future). But I believe you would always be able to gain access to the container because it remains a chroot + namespace + cgroup isolation, all of which you can control on your system.
App developers don’t control what’s on your system either. The container is a huge improvement for them because it at least gives them a known target to build for. They can still bundle dependencies in any way that they would on a non-containerized system. There’s no loss of control from their perspective.
That’s what pressure-vessel is and as shown above you can modify it. And if you couldn’t it would be a tooling issue, not an inherent container disadvantage.
No, they won’t. Compatibility significantly increased after Valve got involved. In fact, the linux community is porting pressure-vessel outside of Steam to use it across different launchers as umu. The community is headed towards using pressure-vessel for everything.
Now I replied to each claim individually, but it’s not really about any specific point you’re making. The general idea is that there’s nothing inherent to container technology that prevents you from tinkering with it. Anything that you can’t do currently is because Steam is not designed to allow you to do it. It’s got nothing to do with whether Steam uses containers or not. Any control that you’ve lost over your system is because you’re using a proprietary app. They could remove the containers and still prevent tinkering, eg by using a bundled wine with no way for you to modify it or its launch options. It’s not about what Steam does, but about how it does it.
Containers are good for a number of reasons, and definitely will not and should not be going away, instead use one of these tools to bypass it:
https://github.com/jcnils/protonhax
It’s a real hassle for running headtracking. And once they take away the possibility to run xterm instead, we won’t even be able to take a look inside
I’ll take a look at protonhax, thanks. But I’m afraid that will still require to run opentrack twice
Does it? What containerization does it use? I thought it was similar to wine, just a process pointed at a windows exe, and an environment to make the app think it’s running in a windows filesystem.
It’s a custom solution called pressure-vessel, which seems to be based on flatpak. You can read about it here. This is used to create a reproducible linux environment and has nothing to do with the windows translation layer. They run wine (proton) inside the container as you would expect.
There is a recent effort to port this solution outside of steam in the form of umu. As far as I know it’s in a working state but I don’t know if it’s at feature parity with steam, especially on the game-specific fixes front. The end goal is to be a universal launcher that can be used from all frontends, so that all windows games run reliably and identically regardless of which GUI you use to manage your games.
EDIT: welp, I just now noticed this info has already been posted by another user 🤷
Something internal. In order to run a third party app with access to the process (like headtracking), the only way I’ve found out to achieve that was to download a windows version of opentrack too and run it twice. One on Linux side, one inside the container and make them talk to each other via UDP
Wow, I’m impressed you actually got that working. Sounds like quite a hack.
Yes it does.
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/container-runtime.md
I believe there is a project to add a Steam independent version of it to Bottles, Lutris, and other proton guis.
https://github.com/Open-Wine-Components/umu-launcher
Ahh, I always wondered what “pressure-vessel” was. Thanks for the resources.