protonscr

Steam GUI won't show when launching from XDG Desktop Entry, but launches fine via terminal

steamclosed Steam clientDistro Family: Ubuntu
ValveSoftware/steam-for-linux#8074 · opened 2021-09-14 by belthesar · updated 2021-09-15 · 6 comments · github
Bbelthesar 2021-09-14 github

Your system information

  • Steam client version (build number or date): Sep 13 2021, 22:01:31
  • Distribution (e.g. Ubuntu): Pop!_OS 21.04
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I've got a weird issue that I haven't been able to sort out here for a while. Steam's installed via the Ubuntu Repo, and for a good long while, everything worked great when launching via the desktop entry. However, for the past several months or so, Steam launches, but doesn't present a GUI when launched via the XDG Desktop Entry, but works as intended when launched via a terminal.

My work around process that I've been doing for a while has been to spawn a new terminal window, launch steam simply via steam, backgrounding the process with Ctrl+Z, disowning the process, and closing the terminal to avoid seeing all Steam's logs output to stdout.

I've checked ~/.steam/steam/error.log, but it only ever contains Installing breakpad exception handler for appid(steam)/version(1631572918) regardless of whether I launch via the XDG Desktop Entry or via terminal.

At this point, I'm looking to see what I can do next to try and get more data here, so any assistance would be appreciated. Thanks!

Steps for reproducing this issue:

  1. Launch Steam via XDG Desktop Entry
  2. Observe Steam does not present a GUI
  3. Verify that steam processes are indeed running by performing ps aux | grep steam
Kkisak-valve maintainer 2021-09-14 github

Hello @belthesar, there's not many things that would be different between starting Steam from a desktop shortcut and the terminal. Maybe there'd be a hint if compare the environment variables between the working client and the misbehaving desktop shortcut? If you have htop installed, in it you can navigate to the Steam process and press e to get a list of the process's environment variables.

Bbelthesar 2021-09-14 github

Heya @kisak-valve, thanks for the pointer there. The only thing I'm seeing that seems like it might be relevant is an environment variable for DRI_PRIME=pci-0000_00_02_0, which points to my discrete GPU. I do have my onboard GPU enabled as well (I don't use it for video work, just to leverage the Intel QuickSync codecs). Can you comment if setting DRI_PRIME to the path of the GPU would cause any expected issues, or am I going down a rat hole on this one.

EDIT: No, it appears Gnome is trying to pass to my Intel GPU for whatever reason. I'm going to try and update the Desktop file to use the PrefersNonDefaultGPU key to see if that helps, and if that works, I get to find out why Gnome is trying to pass to a disconnected GPU.

Kkisak-valve maintainer 2021-09-15 github

Sounds similar to https://github.com/ValveSoftware/steam-for-linux/issues/7089#issuecomment-903155719. If your system is configured to run X on an nVidia gpu, then PrefersNonDefaultGPU=true might cause trouble since I don't think that i965 / iris can render to an nVidia-controlled X session due to a lack of dri3 support. The integrated and discrete GPUs would be switched in terms of which one is default in that case.

Bbelthesar 2021-09-15 github

This system was originally installed with an Nvidia GPU, but I recently swapped out for an AMD RX 6800 XT. I'll do a bit more reading to see if disabling this on my system won't cause other complications, but this seems like the permanent fix. Thanks for your time today, Kisak!

Kkisak-valve maintainer 2021-09-15 github

Between an Intel and AMD, I'd expect for Intel to be able to PRIME render to an AMD gpu, but it's most likely not tested as often. There might be a video driver bug worth exploring there.

Bbelthesar 2021-09-15 github

I'll definitely poke at it. I've been getting some interesting driver-related crashes relating to Firefox and the AMD DRM library when rendering videos from Twitter, so I have some weird shenanigans to look at here. Regardless, it's not a workflow I'm super invested in getting working, so after looking at the package documentation, disabling switcheroo-daemon seemed to be a fine enough solution for my use case.