Introducing early access to the Steam snap!

Nope, steam handles updating itself within the snap, just like the deb does.


Thanks for that feedback, I just added removable-media which will make it to the store in a few hours. However, I think we’ll need to do a bit more work to make it support libraries on different disks. This is great feedback, thanks for helping!


On the topic of performance, it’s going to be on us to ensure that isn’t an issue. We need to gather that feedback in order to understand where there might be performance hits. The primary point of providing steam as a snap is to make it as easy as possible for users to get access to the games they want to play. We don’t want users to need to go add a PPA, or figure out what dependencies they might need. We want users to be able to get access to newer things that improve their gaming experience without causing stability issues outside of their games. For example, we’ll be providing an easy means to track more aggressive versions of Mesa and other userspace parts of the stack, for cases where some games may need that. This is a really great use case for snap, and it also nicely shields the rest of your system from random proprietary games you might be playing.

We will not ignore performance issues, we just need to know what they might be so we can address them.


I run it on Ubuntu 22.04 with Wayland.
I have all interfaces connected except bluez because I do not have any bluetooth devices.

I tried to run Adobe Substance 3D Painter (Native) it fails to start with output:

qt.qpa.plugin: Could not find the Qt platform plugin "wayland-egl" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: minimal, offscreen, xcb.

Blender starts with ALSA warning.

ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4732:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5220:(snd_config_expand) Evaluate error: No such file or directory
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM default

Also as far this is a snap configs are stored within snap directory, so you need to start customizing blender from scratch or copy configs into a new place. Anyway it’s not a big deal.

Most of the time I play Forza Horizon5 through Proton 7. I tried to run it, and it is crashes when 3D scene is finished to load: GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Also it tries to access overlay lib:
ERROR: object '/home/alex/snap/steam/common/.local/share/Steam/ubuntu12_32/' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Spawns fonts errors: Fontconfig error: Cannot load default config file

But hey it is great to have snap version I’m so excited!


This is obviously false. Please do not speak for “everyone”.

On-topic: will def. test the steam snap, would also be very cool if, after the snap is out of beta, you could try to get your hands on the blizzard launcher (I am a hopeless WoW addict :smile:)


I hope the APT package won’t be removed from multiverse so MOTUs could continue maintaining it (like @itzswirlz mentioned, the performance of snaps isn’t great although I hope it will be improved soon and the performance really matters to gamers). There could be FPS spikes when Steam is loading resources as the performance of compressed squashfs images which need to uncompress files on the go is nowhere near the performance of a regular partition on a disk.

@ogra it would be great if some snaps like the Steam snap had compression disabled and weren’t packaged as squashfs images.

I think it would be great if we kept Snap by default and added a GNOME Control Center panel (like the Yaru devs did for Yaru’s appearance panel) to toggle between snaps and flatpaks (there’s no Firefox deb, although a repo like the MPR could be added too to the panel). It seems like most people here are not sure how to remove the snapd package and replace it with Flatpak. Also, Flatpaks were built from the ground-up for desktops unlike Snap, which has only recently been developed for the desktop (and they aren’t even compressed and have near-native launch times or even faster than the native launch times). Snaps do have their advantages though, like not taking as much time to install, being much easier to package (it’s really easy to upload snap packages, similar to Google’s Play Store unlike Flatpaks, which are really hard to package for) and being smaller in side and having auto-updates (which could be seen as downside but is great for desktop users, especially with

Also, it would be great if the contents of the main page of are replaced with the new features in Ubuntu 22.04 and a link to download it (most people who visit it want to download the ISO and aren’t interested in any information related to WSL on Windows or Anbox Cloud). It would be great if Ubuntu Server, Anbox Cloud and Canonical’s other products are migrated from this Discourse instance to (with a link to it in Ubuntu’s headerbar). too does this, mainly promoting Windows on their main page but having links to their enterprise products too. This would bring many more users to Ubuntu. There could be a separate subdomain for Canonical’s enterprise offerings too (similar to

@ian-weisser and other mods: would be great if you could move these posts to another thread related to the Ubuntu Desktop

@sabdfl: it would be great if you could take a look at the suggestions above :slight_smile:


So far I haven’t been able to get the snap version of steam working. I’m on the edge version of snapd and the beta version of steam itself.

One curiosity that I have noticed is that sharing a game library with the flatpak version causes some issues. E.g., that if I try to run a game in the snap version, then close steam, and open the flatpak version, I can no longer run said game in flatpak either. It’s entirely possible that I’m the one doing something wrong here, but would love to know if anyone else has come up against this.

Right, I think I can see why games are no longer playable after I’ve tried running them in the snap version. A lot of the files, dlls, exes, etc, in the compactdata/${ID}/pfx folder have a size of 0 after trying to run the game in snap steam. In the flatpak prefix, these files all have non-zero sizes.

$ find 2310.flatpak -type f -size 0 | wc -l
$ find 2310.snap -type f -size 0 | wc -l 

I do wonder if this is because I’m running these games off a mounted disk, and not in the default location, so I will do some testing in a bit.

How does the Snap handle installing stuff like Proton GE and luxtorpeda? Both are key elements of using Steam on linux.

1 Like

I have two questions regarding this development.

  1. It was stated on the blog that

Snaps provide three key benefits that are relevant to Steam users.

Firstly they bundle dependencies. This means gamers don’t have to go hunting through out-of -date documentation, adding PPAs for Mesa drivers or 32-bit libraries to get their games to work. It also means the Steam snap will run on any distro that supports snapd without hassle.

I can read fine but just to ensure I understand right: Does this mean that games running in Snap’d Steam will use bundled mesa libraries instead of system and therefore there is no need to use eg. the Kisak PPA on LTS?

I don’t like snaps but if they can do this, I am sold on this.

  1. If the answer to question 1) is affirmative, is there any way to get non-Steam games onboard with this as well? Basically I’d like to use Ubuntu LTS as a daily driver with only official tools (eg. no random PPAs) but I’d like to be able to have an up to date graphics stack for games, including games I run through Lutris etc. This was a big reason for me running faster moving distros like Fedora or Arch before.

  2. Is Valve involved in this? Can we expect support from Valve for this Snap’d solution?


can we stick to facts here ? while the startup performance is measurably slower due to the squashfs compression, there is zero difference at runtime of snaps …

in fact runtime performance can even be faster because snaps do not have any (package archive induced) restrictions in compiler optimization you pick, if you want to go the “ricer way” and optimize the hell out of it you can, you could even use a different compiler (ICC vs GCC) that puts out higher performing binaries …

while you will likely not see squashfs going away (the tinker-proof GPG signed read-only images are a part of the security model), there have always been discussions about allowing more, different and even no compression for them though. but the snapd team is small and often focused on commercial and paid for features, if more community contributed code would land in snapd, that might free up some resources to work on such extra features :wink:


if they are actual key elements they should be bundled in the snap …

if they are not, but useful for many, there can either be additionally install-able content snaps you could install to provide them to the steam snap via a content-interface or an interface can be added to snapd that allows access to native installations of the two on your host machine. both is possible …


yes :slight_smile:

1 Like

hi @ogra :slight_smile:

while I do think this is applicable to regular apps, I’m not sure about Steam as there might be sudden FPS drops when the game attempts to load resources, which would be much slower in a compressed squashfs (as it tries to uncompress the resources when they are accessed). honestly, packaging Steam as a snap is a really great idea +1 (Snap’s auto-updates too would come in handy as gamers wouldn’t have to endure Steam’s painfully long startup updates). However, I do think it would make a huge difference in performance if the squashfs for Steam wasn’t compressed (I could do a PR with this change in snapcraft)

the games do not live in the squashfs, they just come from the steam directory on disk … would be very surprising if they behaved differently …

please start a discussion (with code examples or a link to a PR on github) on, such features will need discussion and review/confirmation of an architect to make sure they do not add regressions for existing use-cases and the like …

there are also many levels of integration (snapcraft will need to make use of such an option, the yaml format will need updating, the automated review tools will need to learn about it, etc, etc) that will need to be coordinated.


I had worked on a few Unity (the engine, not the DE) games earlier for Steam and many games do load Steam’s APIs when being played (for getting account information, checking if a Steam friend is playing the game and to ask the gamer if they want to play with them, as well as the Steam HUD, which would probably be affected the most by the compression).

sure, I’ll do that (currently busy with working on Unity 7.6)

Because of the slowness, I don’t really like snap either. But, if Steam snap can integrate Proton GE, Proton tkg, luxtorpeda and we don’t need additional 3rd party apps or copy/paste directories to install it separately then I have to admit it is better than steam flatpak or .deb file and I can give a try.

yep, it would be great if Proton GE was added, but I’m not really sure if Valve would be happy with that

EDIT: @dvdnet1 thanks for joining Discourse :slight_smile:

1 Like

if the ld linker functions properly they will pull the required libs into ram on startup, this will be quite different to “load all libs at once at the same time when launching the binary initially” that you see when a snap runs at cold start …

but feel free to measure this somehow, this is exactly the reason why this “call for testing” thread exists :wink: to gather feedback for improvements from testers …