Steam call for testing!

Did you know we are aiming to move the Steam snap out of “Early Access” to stable soon?

Did you know today is the first day of the Steam spring sale?

Have you ever wanted to combine playing video games with contributing to the Ubuntu ecosystem?

Well you’re in luck!

Since publishing Steam as a snap under the “Early Access” banner, we’ve been working feverishly to resolve issues and ensure it works well. We’ve done our own testing of the most popular Steam titles which should ‘just work’ based on reports on ProtonDB. You can find game reports for those on GitHub discussions.

Now we need your help to provide game reports for your favorite games and make sure we’ve got maximum coverage of as many Steam titles as possible!

How to get involved?

Install Steam from the candidate channel, play your favorite games and submit a game report with our tool which is included in the Steam snap.

If you haven’t installed Steam as a snap yet, grab the version from candidate:

sudo snap install --candidate steam

If you already have the Steam snap installed, quit Steam and switch to the candidate channel:

sudo /usr/lib/snapd/snap-discard-ns steam
sudo snap refresh --candidate steam

Launch Steam, download your favorite games, and enjoy!

To report your results (positive or negative are appreciated).

sudo snap connect steam:hardware-observe
sudo snap connect steam:system-observe “Your Title”

The two snap connect commands only need to be run once, it enables the script to collect some information from your system, including things like GPU info. Don’t worry, the report will open a web browser with some information pre-populated which can edit as you like. You’ll have an opportunity to see everything that will be submitted.

When filling out the game report post on GitHub, please add a rating in your title, similar to what protondb uses. For example: platinum, gold, silver, bronze, or borked.


Looking forward to seeing everyone’s results! I just picked up Battlefleet Gothic 2 and Space Marine because I’m in a 40k mood at the moment but will also try a few RTS’s over the weekend as those aren’t usually a big focus on the Steam Deck.

Don’t forget you can read more about the work going on behind the Steam snap, including how we enable users to get bleeding edge Mesa for their games in our blog post here!


I sadly don’t have the availability to do some beta testing on this, but I AM curious how Steam in Snap handles the fact that Steam uses Bubblewrap (part of Flatpak) for their Steam Runtime on Linux. This has been a problem for users that install Steam via Flatpak, how will Snap address this?
Especially since Flatpak and Snap installs of Steam are not officially supported by Valve

1 Like

snap confinement provides similar features to bubblewrap transparently to the packager. It has been a core feature of strict snap packaging since day one and you do not need any extra wrapper tools for it.

snaps do run by default on top of the defined (read-only, gpg signed squashfs) base: runtime in namespaces with apparmor and seccomp profiles and are using device cgroups.

While bubbewrap is an after-the-fact addition to flatpaks, snaps have always had these features built-in by default, so something like calling bwrap ... <command> is not necessary at all …

For more detailed info see:

The built-in interface system snaps can use provide your app (mediated) direct access to the hardware under the permissions of the running user. So the steam snap can access things like your graphics hardware, controllers etc directly as if it would be running unconfined, this guarantees for example no performance impact … more info at:


I think what the previous poster was asking was, What compatibility problems are there when Steam tries to use Bubblewrap while running under Snap.

1 Like

Well, why would it try to use bubblewrap if it does not need to ? :slight_smile: For the steam binary the system looks like a native install …

The job of a snap packager is to make sure the runtime environment is on par with that expectation though and that the picked interfaces provide all the right bits and pieces …

To find out if all requirements are fulfilled for all corner cases a lot of user testing is necessary … thus this post so the team creating the package gets feedback for all use-cases and can adjust the packaging if necessary.


Why wouldn’t it try to use bubblewrap if it looks like a native install?

because bubblewrap is a flatpak feature that is explicitly wrapped around commands when packaged in a flatpak ?

an install of the steam deb on a native machine will not use it … nor will a snap packaged steam deb … (and it would be odd to use it since there is already proper sandboxing in place, you really do not want to stack them)


I’m looking forward to do some testing :​)

Thank you for all of the hard work you all do!


IIRC some versions of Proton (if not all) and the Steam Runtime will run games in bubblewrap whether you want it or not. Even then some older linux native games will ONLY run well when using Steam Runtime - Soldier.

Valve builds Steam with the assumption that it is not already running in some sort of sandbox/containerized system like Flatpak or Snap. The issue isn’t who includes it, the issue is that running Steam in Flatpak will actually make some Steam features unusable. I haven’t checked with Steam on Snap and don’t have time, so that’s why I’m asking.

Basically, what effect will running Steam as a Snap on features that are built with the assumption that Steam is just installed as a system application?

Valve assumes with Proton >= 5.13 all use a container runtime (bwrap) to run the Windows games in Linux.

More info on this can be found at:

1 Like

I have this bug in other versions of steam too, but if I add Firefox as a non-steam game, and then I “Stream” it from another computer, I get the notification of “Press Esc to control your session” that persists forever instead of going away.

Hmm that’s not how I understood it. I understood it as this:
Bubblewrap (or bwrap) is something that Steam bundles and uses for it’s Steam Runtimes, both the new Linux runtimes that are sometimes used and for Proton. It might be derived from Flatpak, but it’s a part of Steam that Steam always uses. It’s part of the Pressure Vessel stuff.

I’ll leave details to the actual packagers to answer. I’m pretty sure we do not stack any sandboxes and looking at the github code of the snap it does nothing fancy to the steam deb, it just unpacks it into the snap… perhaps there are additional patches to pressure vessel or proton outside of the snap packaging (even upstream) to suppress bwrap calls though…

1 Like

The steam runtime does use bubblewrap, even in the snap. It’s not flatpak specific.


Oops, I’m sorry for causing confusion then… mea culpa…


I’m sorry if I seemed combative. I just want to make sure people are aware of the fact that Steam in a Snap might come with features that don’t work. It’s why I’m sometimes hesitant to use Snaps or Flatpaks that aren’t supported by the software vendor/FOSS project as there’s always a risk that the vendor/community won’t support that kind of packaging format.

1 Like

Has anybody tried Steam in a snap having a multiple separate game libraries distributed on various drives? I have three game libraries stored on my main NVME SSD, larger SATA SSD and “backup game library” on a dedicated 4TB HDD. With Flatpak, I was unable make steam recognize those libraries even following a guide on using flatpak override command.

@Tylnesh I have managed to create new game folder installation locations in Steam and have them working just fine (although I have not tried mapping an existing game library to the Snap). I also have the Steam deb installed for comparison testing and I was able to have them both share the same library.

@dhollinger the goal of this thread is to test the features of the snap in comparison to the deb to explicitly identify any features that may not work so we can commit to resolving them :slight_smile:

1 Like