I made a post (#10555) that was marked as duplicate, so here are my logs in case it helps. One is what happens when I run 'flatpak --user run com.valvesoftware.Steam' , which is that the popup happens and will continue to try and start steamwebhelper infinitely until I control-C. The second log is my steamwebhelper.log, which says that pressure-vessel has no version information available (required by /bin/bash). I'm not sure the significance of pressure-vessel not having version info available, but I wanted to bring it up in case it helps.

https://gist.github.com/T-Quill/e4df450dba966fded2922c3ff49f825b

/bin/bash: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libtinfo.so.6: no version information available (required by /bin/bash)

This particular message is only a warning, you can safely ignore it.

pressure-vessel has no version information available

No, it's libtinfo.so.6 that has no version information available.

Thank you for clarifying, I'm glad that warning's safe to ignore. If any other logs would be helpful lmk and I'll provide them

@four-griffins, I think the problem here is that the DISPLAY is not present in the activation environment of your systemd --user if you are using systemd, or your D-Bus session bus (dbus-daemon --session) if you are not using systemd. Either way, the solution would be to make sure that something like

dbus-update-activation-environment DISPLAY

is invoked after starting Xwayland and setting DISPLAY. (Or your desktop environment could implement the equivalent of that command internally, by making the equivalent D-Bus calls itself, like gnome-session does - but Hyprland probably doesn't do this.)

When it's running inside a Flatpak app, Steam's container runtime framework needs to start a new Flatpak sub-sandbox, which it does by sending a D-Bus method call to flatpak-portal. On systems that use systemd --user, the message bus (dbus-daemon --session or dbus-broker) automatically asks systemd --user to start flatpak-portal. Or, on systems that don't use systemd --user, the dbus-daemon --session will start flatpak-portal as a direct subprocess of its own.

flatpak-portal inherits environment variables from whichever system component started it, and that includes the DISPLAY. The new Flatpak sub-sandbox that is used to run steamwebhelper needs to inherit the DISPLAY from the flatpak-portal. If the flatpak-portal doesn't get the DISPLAY from its parent then that can't work.

The Flatpak 1.15.x development branch has a change which would avoid this problem (https://github.com/flatpak/flatpak/issues/5278) but it's probably too intrusive to backport to the 1.14.x stable branch.

@T-Quill, I suspect you probably have the same problem as @four-griffins, but I can't say that for sure from the information available. Please try the same solution: making your desktop environment upload the DISPLAY into the activation environment after it starts Xwayland, via dbus-update-activation-environment DISPLAY or similar, and then restarting the desktop session.

A well-integrated desktop environment should have automatically set this up for you, but Sway or Hyprland on Alpine is probably more of a "some assembly required" environment.

If that doesn't work, the next thing to try would be running Steam with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment, and collecting the steamwebhelper.log (which should be much larger with that environment variable set, similar to the one @four-griffins provided).

(Or your desktop environment could implement the equivalent of that command internally, by making the equivalent D-Bus calls itself, like gnome-session does - but Hyprland probably doesn't do this.)

You are right, Hyprland isn't exactly batteries-included and does not do that automatically. For anyone else reading this, the Hyprland-endorsed way to do it is to add an exec-once to the configuration file at ~/.config/hypr/hyprland like so:

exec-once = dbus-update-activation-environment DISPLAY

(In fact I already had a line like that that updates WAYLAND_DISPLAY and XDG_CURRENT_DESKTOP, maybe I should try to find where I got that suggestion and tell them to add DISPLAY too :smile: )

In any case, adding this worked for me (on a non-systemd distro) and Steam now starts as expected again. @smcv thank you so much for your helpful and detailed answers!

It worked! Similarly to four-griffins I had a line in my ~/.config/sway/config with exec dbus-activation-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=sway so I just added DISPLAY and restarted, then bam! Steam works! What a relief. I'll update our wiki with the new instruction. Thanks for your time explaining @smcv!

(In fact I already had a line like that that updates WAYLAND_DISPLAY and XDG_CURRENT_DESKTOP, maybe I should try to find where I got that suggestion and tell them to add DISPLAY too 😄 )

Please do! These self-assembly, batteries-not-included desktop environments tend to be accompanied by a lot of copying and pasting instructions around, which makes them take up a disproportionate amount of support time for the rest of the Linux ecosystem if those instructions are incomplete or wrong.

Or, if you can encourage the upstream project and/or your distribution to include the necessary batteries, that would also benefit the whole Linux ecosystem.

It isn't really sustainable to outsource the support burden to maintainers of unrelated projects who never intended to be responsible for Sway or Hyprland.

on a non-systemd distro

To be clear about this, the need to get DISPLAY into the activation environment is equally important on systemd and non-systemd distros. The only thing that changes between systemd and non-systemd is the precise mechanics of whose activation environment is the relevant one (systemd or dbus-daemon) - but with a modern version of dbus, dbus-update-activation-environment ends up affecting both in any case, so it's equally valid either way.

Is dbus-activation-environment only for X11 or also within Wayland/ xWayland?

Is dbus-activation-environment only for X11 or also within Wayland/ xWayland?

Both. DISPLAY is used by traditional X11, but also by Xwayland.

It worked! Similarly to four-griffins I had a line in my ~/.config/sway/config with exec dbus-activation-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=sway so I just added DISPLAY and restarted, then bam! Steam works! What a relief. I'll update our wiki with the new instruction. Thanks for your time explaining @smcv!

For anybody else seeing this issue on sway, I had to add update to dbus-activation-environment, as well as DISPLAY on the end.

exec dbus-update-activation-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=sway DISPLAY

Hello! Maybe someone can help, I believe my problem is related with this bugreport, but I can't realize how to implement the fix. I am running Fedora 40 with default GNOME 46 on wayland, and filled bugreport with Cartridges software here https://github.com/kra-mo/cartridges/issues/258
Thank you for your attention!

I'm having a similar issue after a steam vr crash caused by alvr on on fedora 40 kde spin. I just updated for fedora 41 and the same issues are happening.

Edit: I just threw in the towel and re-installed it. It works fine now. I'd say try it if you haven't already.

In hopes it may be useful to others - this was apparently happening to me because at some point I had manually enabled the permission that Flatseal calls "Fallback to X11 windowing system". Curious why exactly that was (I guessed that if it was disabled, xwayland would run, which seems false) but Steam works now.

Flatseal

In general, adjusting Flatpak apps' sandboxing parameters with Flatseal is something that can very easily break the app, especially if you take away permissions that the app had by default: usually they are there for a reason.

this was apparently happening to me [presumably under Flatpak] because at some point I had manually enabled the permission that Flatseal calls "Fallback to X11 windowing system". Curious why exactly that was

This is presumably Flatpak's fallback-x11 sandboxing parameter, which means:

• if your host system has native Wayland, Flatpak will only provide the Wayland socket to the app, and not the X11 socket and Xauth token provided by Xwayland; native Wayland will work, but X11 will not work
• or if your host system only has X11 (Xorg), Flatpak will provide the X11 socket and Xauth token to the app instead, and X11 will work

This is sufficient for most simpler "modern" apps, for example using GTK or Qt, which automatically try to use native Wayland, falling back to X11 if that isn't possible.

But it is not sufficient for Steam, which uses older UI toolkits that require X11 (even on a Wayland desktop). It is also not sufficient for the games that Steam launches, many of which also require X11 and would not work correctly without it, even if Steam did.

I guessed that if it was disabled, xwayland would run, which seems false

Flatpak never runs Xwayland on a per-app basis. If you are using a Wayland desktop environment like GNOME, the desktop environment is responsible for running a single global instance of Xwayland, which is shared by all apps. It has to be this way because X11 window management is done for the desktop as a whole.

Gamescope (as used on Steam Deck) does start a separate instance of Xwayland for each game, but it can only do this because it doesn't do normal window management: instead it makes every window behave as though it was fullscreen. This is enough for a games-console-style interface to fullscreen games, but would not be enough for Steam, which does have more than one window.

In hopes it may be useful to others - this was apparently happening to me because at some point I had manually enabled the permission that Flatseal calls "Fallback to X11 windowing system". Curious why exactly that was (I guessed that if it was disabled, xwayland would run, which seems false) but Steam works now.

Same issue here, after fiddling with a bunch of different settings combinations this was the only one that was killing things for me following a recent Bluefin update. So "in hopes it may be useful to others" indeed, thanks @99jte! (And @smcv's follow-up context clarified things a lot too, so cheers to you both)