(Flatpak/Wayland) steamwebhelper fails to launch, seemingly missing $DISPLAY

[four-griffins]

Your system information

• Steam client version: 1.0.0.78 (flatpak latest)
• Distribution : Alpine edge, Hyprland 0.35.0 with xwayland installed, flatpak 1.14.5
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes
• Steam Logs: steam-logs.tar.gz (this is with STEAM_LINUX_RUNTIME_VERBOSE=1 set)
• GPU: AMD R6800XT

Please describe your issue in as much detail as possible:

steamwebhelper fails to start on a completely fresh Steam Flatpak install, on a completely fresh Alpine install as well:

It still worked 3 days ago when i downloaded Elden Ring without playing it, and even yesterday, when I was trying to get the game to launch. At some point i closed Steam and it hasn't worked once since. I have uninstalled Steam and even reinstalled my OS entirely, still nothing. I assume it updated when it started up again, but I don't remember for sure (my memory sucks 😅)

I've seen plenty of people have issues with the newest version of steamwebhelper, but I haven't seen anyone with these lines in particular in steamwebhelper.log:

[0229/142354.032593:ERROR:ozone_platform_x11.cc(238)] Missing X server or $DISPLAY
[0229/142354.032616:ERROR:env.cc(255)] The platform failed to initialize.  Exiting.

The terminal output shows that Steam tries to launch steamwebhelper via the sniper runtime 3 times before giving up and displaying the error popup.

Some other recent issue mentioned running run-in-sniper vkcube which also fails with:

Environment variable DISPLAY requires a valid value.
Exiting ...

even when explicitly setting $DISPLAY to :0.
Curiously, out of the 3 env variable dumps that appear in the verbose steamwebhelper.log, only the 3rd one seems to be missing DISPLAY.

Steps for reproducing this issue:

1. Install Steam via Flatpak (flatpak install com.valvesoftware.Steam)
2. Run Steam

[T-Quill]

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

[smcv]

/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.

[T-Quill]

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

[smcv]

@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 (flatpak/flatpak#5278) but it's probably too intrusive to backport to the 1.14.x stable branch.

[smcv]

@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).

[four-griffins]

(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 😄 )

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!

[T-Quill]

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!

[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.

[ryanmusante]

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

[smcv]

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

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

[kingprawn22]

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