New steam UI does not open if run with DRI_PRIME=1

[koresh-krasa]

Your system information

• Steam client version (build number or date): 1682634349
• Distribution (e.g. Ubuntu): Fedora Silverblue 38
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Similar symptoms as https://github.com/ValveSoftware/steam-for-linux/issues/9381 Login prompt displayed correctly but than main window tries to appear but crashes and goes into loop. This issue is happening if DRI_PRIME is set to non 0 (e.g. DRI_PRIME=1, DRI_PRIME=pci-0000_03_00_0) DRI_PRIME=0 works fine.

In journalctl I was able to find some error logs related to steamwebhelper crash. steam_journalctl.txt

Optput from DRI_PRIME=1 com.valvesoftware.Steam steam_output.txt

Steam client is flatpak

System information: https://gist.github.com/koresh-krasa/b9a7a4c486ff061b9823aea6ce44f65b

DRI_PRIME=1 was working before this update

Steps for reproducing this issue:

1. Open steam with DRI_PRIME set as non 0 / from Gnome application menu
2. Login splash window works as expected
3. Main window is not appearing Screencast from 2023-04-28 11-23-06.webm

[arrowgent]

can you test

DRI_PRIME=1 glxgears

[koresh-krasa]

https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1527215827

This works fine from flatpak sandbox with same runtime as Steam

[kisak-valve]

Hello @koresh-krasa, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

Blind guess that this is related to https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19101.

[bessman]

please copy your system information from Steam (Steam -> Help -> System Information)

Since I'm also seeing the same behavior, I figured I'd provide my own system information. But due to #9398, I cannot :disappointed:

[koresh-krasa]

@kisak-valve System information from stable client https://gist.github.com/koresh-krasa/b9a7a4c486ff061b9823aea6ce44f65b

DRI_PRIME=1 was working before this update. Also similar behavior was present with new gamepadui before (similar to https://github.com/ValveSoftware/steam-for-linux/issues/9190)

[jntesteves]

@kisak-valve I see 2 issues here:

1. In the new UI framework, Steam can't create a window using a dGPU. That's the most obvious problem, Steam should be able to use any GPU. I'm sure Valve's developers are already looking for a solution to this.
2. That Steam is requesting a non-default GPU in the first place is an issue in itself. There's no reason for Steam to wake-up a dGPU in a laptop, that's wasteful. Only games should require using a dGPU, and even then, not all games require that.

Solving issue 2 is pretty easy, just remove the options from the desktop file. I've sent a PR to fix that in the Flatpak package for now, until it's removed upstream: flathub/com.valvesoftware.Steam/pull/1086

[kisak-valve]

Re-reading this issue report, it should be noted that the common case where DRI_PRIME gets set is from the desktop environment seeing PrefersNonDefaultGPU=true in Steam's desktop shortcut. As a workaround, this can be set to false or removed to avoid this issue.

[TimTheOverlord]

Re-reading this issue report, it should be noted that the common case where DRI_PRIME gets set is from the desktop environment seeing PrefersNonDefaultGPU=true in Steam's desktop shortcut. As a workaround, this can be set to false or removed to avoid this issue.

Not sure if I necessarily executed the above workaround correctly, but I could not get it to work. What I was able to do was run Steam from the terminal with the argument -vgui and that successfully got Steam to open again. The only downside to the -vgui workaround is that the Friends UI fails to connect. Not sure if this is technically the appropriate workaround, but it worked for me.

My setup is Ubuntu 20.04 with Steam installed via the .deb package from here and I am opted into the Steam Beta releases.

[kisak-valve]

Hello @TimTheOverlord, with regards to this issue report, running steam from the terminal should workaround the common case, unless you're setting DRI_PRIME globally somewhere. If you need to pass launch options to steam, then you're seeing a different issue.

[Slider-Whistle]

Hey all, I'm sure you guys are all still cracking at it either way, but I just wanted to mention there's a specific use case for users deliberately launching steam under the DRM_PRIME=1 variable. There's power saving in general of course, but it's also a popular choice with users who utilise full GPU passthroughs to virtual machines, effectively allowing them to pass control of their GPU between the guest or host operating system on the fly, just depending on what they're doing with it (which game they're playing) at the time.

https://help.steampowered.com/en/faqs/view/145A-FE54-F37B-278A ^ This official article doesn't get as far into the motivations of it, but it basically outlines a NVidia-specific method of doing the exact same thing, and mentions the convenience of launching steam under the variable rather than setting it on a per-/every-game basis.

[Candyhands]

I have no clue what

Re-reading this issue report, it should be noted that the common case where DRI_PRIME gets set is from the desktop environment seeing PrefersNonDefaultGPU=true in Steam's desktop shortcut. As a workaround, this can be set to false or removed to avoid this issue.

Not sure if I necessarily executed the above workaround correctly, but I could not get it to work. What I was able to do was run Steam from the terminal with the argument -vgui and that successfully got Steam to open again. The only downside to the -vgui workaround is that the Friends UI fails to connect. Not sure if this is technically the appropriate workaround, but it worked for me.

My setup is Ubuntu 20.04 with Steam installed via the .deb package from here and I am opted into the Steam Beta releases.

'v-gui' argument is the only way to get Steam to launch for me as well. 'DRI_PRIME' and modifying 'PrefersNonDefaultGPU=true' do absolutely nothing

[jntesteves]

@Candyhands @TimTheOverlord are you guys by any chance using KDE or one of the other Qt-based DEs? If that's the case, besides removing PrefersNonDefaultGPU=true from Steam's .desktop file, you might also need to remove X-KDE-RunOnDiscreteGpu=true. Can you try removing both options from the desktop file and test if that solves the problem.

Note that this test might require a logoff/login or a reboot because DEs often have trouble live reloading .desktop files.

[Seb-Solon]

Re-reading this issue report, it should be noted that the common case where DRI_PRIME gets set is from the desktop environment seeing PrefersNonDefaultGPU=true in Steam's desktop shortcut. As a workaround, this can be set to false or removed to avoid this issue.

Can confirm that changing /usr/share/applications/steam.desktop as described above works for me. I have a config quite close to OP

Operating System Version:
Debian GNU/Linux 12 (bookworm) (64 bit)
Kernel Version: 6.1.0-9-amd64
X Window Manager: GNOME Shell
Steam Runtime Version: steam-runtime_0.20230509.49499

Video Card:
Driver: AMD AMD Radeon RX 6950 XT (navi21, LLVM 15.0.6, DRM 3.49, 6.1.0-9-amd64)
Driver Version: 4.6 (Compatibility Profile) Mesa 22.3.6

[Candyhands]

@Candyhands @TimTheOverlord are you guys by any chance using KDE or one of the other Qt-based DEs? If that's the case, besides removing PrefersNonDefaultGPU=true from Steam's .desktop file, you might also need to remove X-KDE-RunOnDiscreteGpu=true. Can you try removing both options from the desktop file and test if that solves the problem.

Note that this test might require a logoff/login or a reboot because DEs often have trouble live reloading .desktop files.

I have done this, and no dice. I'm on xfce, so it's gtk based rather than qt based. Running 'steam-runtime --reset' fixed the problem for me, but only for once launch. When I closed it, I couldn't open it back up.

[mwprado]

Same problem here, with DRI_PRIME=1, steamwebhelper chash.

OS: Fedora release 38 (Thirty Eight) x86_64 Host: HP ProDesk 600 G1 SFF Kernel: 6.3.8-200.fc38.x86_64 Resolution: 1920x1080 DE: GNOME 44.2 WM: Mutter WM Theme: Adwaita Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] CPU: Intel i7-4770 (8) @ 3.900GHz GPU: Intel HD Graphics GPU: AMD ATI Radeon Pro WX 4100 Memory: 4059MiB / 11835MiB

[ndavd]

Removing PrefersNonDefaultGPU and X-KDE-RunOnDiscreteGpu from the .desktop file worked for me. Is there any drawback to that? That is, once this issue get solved, should I bother to add it again or not really?

[chinoto]

If I simply run steam all is well; but if I run env DRI_PRIME=1 steam; steamwebhelpers spawn and die, systemd-coredump runs for a bit, and this repeats until I close Steam. Here's neofetch --off output:

OS: openSUSE Tumbleweed x86_64 
Host: ROG Strix G513QY_G513QY 1.0 
Kernel: 6.3.7-1-default 
Uptime: 37 mins 
Packages: 3589 (rpm), 15 (flatpak) 
Shell: fish 3.6.1 
Resolution: 1920x1080 
DE: Plasma 5.27.5 
WM: KWin 
Theme: Breeze [Plasma], Adwaita [GTK2/3] 
Icons: breeze [Plasma], breeze [GTK2/3] 
Terminal: konsole 
Terminal Font: DejaVu Sans Mono 8 
CPU: AMD Ryzen 9 5900HX with Radeon Graphics (16) @ 3.300GHz 
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 
GPU: AMD ATI Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT 
Memory: 5062MiB / 15376MiB

More details found here, but the problem is all about DRI_PRIME, so anything else is likely irrelevant.

[jntesteves]

Removing PrefersNonDefaultGPU and X-KDE-RunOnDiscreteGpu from the .desktop file worked for me. Is there any drawback to that? That is, once this issue get solved, should I bother to add it again or not really?

For most games that won't make a difference, since games using Vulkan, DXVK and VKD3D will choose the dGPU on their own. The only difference in behavior you will see is with OpenGL games that will now default to the primary GPU, which on a laptop will be the iGPU. If you want to launch an OpenGL game on the dGPU you must set DRI_PRIME=1 %command% on its launch options.

On a desktop PC you don't need these options, so it's better to keep them off, independent of this issue.

I'm of the opinion these options should never have been added to the desktop file in the first place. They do more harm than they help.

[ndavd]

Thanks! And actually I just realized that today it's not opening again, even with those options set.. Any idea?

[ndavd]

Even with those options set in the .desktop file the only way I have to make Steam open is with the -vgui flag ...

EDIT: Apparently, I had to change another desktop file located in /usr/lib/steam/steam.desktop

[chinoto]

@ndavd, thanks for the workaround. For others who want to try it, do this: env DRI_PRIME=1 steam -vgui. I am not sure why, but the "friends network" doesn't work when I do this.

Edit: fossilize_replay has been running for a long time, this concerns me because I think it's pre-compiling shaders for the iGPU, which for most games is undesirable, and probably isn't pre-compiling anything for the dGPU. This would be a good reason to have DRI_PRIME working again (or be able to specify which GPU/driver to compile for) because otherwise I might as well turn off the shader caching feature.

[winchjr]

xpost from https://github.com/flathub/com.valvesoftware.Steam/issues/1103

Similar issue, only happened in the past day or so. I am not using Flathub. Core output of inxi -Fxz:

System: Kernel: 5.10.0-23-amd64 x86_64 bits: 64 compiler: gcc v: 10.2.1 Desktop: Cinnamon 4.8.6
Distro: Debian GNU/Linux 11 (bullseye)
Machine: Type: Portable System: Alienware product: Alienware 17 v: A17 serial:
Mobo: Alienware model: 068R5X v: A00 serial: UEFI: Alienware v: A17
date: 07/22/2019
CPU: Info: Quad Core model: Intel Core i7-4700MQ bits: 64 type: MT MCP arch: Haswell rev: 3
L2 cache: 6 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 38311
Speed: 3303 MHz min/max: 800/3400 MHz Core speeds (MHz): 1: 3303 2: 3381 3: 3218 4: 3266
5: 3267 6: 3268 7: 3226 8: 3280
Graphics: Device-1: Intel 4th Gen Core Processor Integrated Graphics vendor: Dell driver: i915
v: kernel bus ID: 00:02.0
Device-2: NVIDIA GK106M [GeForce GTX 765M] vendor: Dell driver: nvidia v: 470.182.03
bus ID: 01:00.0
Display: x11 server: X.Org 1.20.11 driver: loaded: nvidia resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 4600 (HSW GT2) v: 4.5 Mesa 20.3.5
direct render: Yes

I've had issues with Bumblebee before, but this doesn't seem to be related to Bumblebee. Core symptoms:

• Have to start any steam application with primusrun like usual
• Doing so will run the application like usual, but every 5-10 seconds, the center of the screen will freeze (approximately where the Steam desktop UI should be, if it were open) briefly, and interrupt whatever task I am doing for a split second as described in OP
• Since I have to run everything from terminal, I can see the output that repeats every 5-10 seconds:

/bin/bash: /home/user/miniconda3/lib/libtinfo.so.6: no version information available (required by /bin/bash)
steamwebhelper.sh[234335]: Runtime for steamwebhelper: defaulting to /home/user/.steam/debian-installation/ubuntu12_64/steam-runtime-heavy
/bin/bash: /home/user/miniconda3/lib/libtinfo.so.6: no version information available (required by /bin/bash)
steamwebhelper.sh[234335]: Using CEF sandbox (try with -no-cef-sandbox if this fails)
BuildCompleteAppOverviewChange: 166 apps
RegisterForAppOverview 1: 4ms
RegisterForAppOverview 2: 4ms

• I've tried using -no-cef-sandbox and it merely changes that line to saying "cef sandbox already disabled", but still freezes the screen/system periodically
• System monitor shows spikes in cpu usage when the screen freezes, as well as numerous (going from 1 to 10,20,30 etc) steamwebhelper processes appearing briefly when the cpu spikes, then returning back to 1 steamwebhelper process
• Opening Steam by "running with dedicated gpu" option on start menu, or running via terminal without primus will not open the application correctly (this was the case before as well; always have to open with primusrun )
• the libtinfo line was there before this problem, and probably unrelated
• Even if I minimize the Steam UI, it will still interrupt. The only thing that prevents the interruption is shutting down Steam entirely.
• Judging by the other threads I've found, this seems to be a linux issue in general. Possibly a library update that came with the new GUI update?
• The GUI itself loads fine, and I can access it as long as I don't open Steam with primusrun, and instead open it without primus (yet of course I can't open any application without primus)

Here are other related threads that I've found that seem to be related: https://github.com/flathub/com.valvesoftware.Steam/issues/1104 https://github.com/flathub/com.valvesoftware.Steam/issues/1103 https://bbs.archlinux.org/viewtopic.php?id=286571 https://forums.linuxmint.com/viewtopic.php?p=2339619

Let me know which logs might be useful.

Edit: Have not tested -vgui flag, will give it a shot tomorrow

[ndavd]

Even with those options set in the .desktop file the only way I have to make Steam open is with the -vgui flag ...

EDIT: Apparently, I had to change another desktop file located in /usr/lib/steam/steam.desktop

On doing some more testing apparently it only opened with those options once.. Today I couldn't open it again, even though those options were set. So for me, currently, using the -vgui option is the only way I can open Steam

[chinoto]

@winchjr Have you tried running Steam without primusrun, then use in each game's launch option primusrun %command% (syntax may be incorrect, never used primusrun)? Would be nice if you could set a global Steam game launch option.

[Candyhands]

Okay, launching Steam from the command line finally does something for me. Before it just returned a message saying the runtime was all good. But now, these are the errors I get. Arch w/ XFCE on a 3060ti

(steam:9387): GLib-GObject-CRITICAL **: 21:06:27.063: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Could not connect to X session manager: Authentication Rejected, reason : None of the authentication protocols specified are supported and h

(steam:9387): Gtk-WARNING **: 21:06:56.305: gtk_disable_setlocale() must be called before gtk_init()
RegisterForAppOverview 1: 7ms
RegisterForAppOverview 2: 7ms

(steam:9387): GLib-GObject-CRITICAL **: 21:06:56.877: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

(steam:9387): GLib-GObject-CRITICAL **: 21:06:56.877: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
steamwebhelper.sh[10034]: Runtime for steamwebhelper: defaulting to /home/jonah/.local/share/Steam/ubuntu12_64/steam-runtime-heavy
steamwebhelper.sh[10034]: glibc >= 2.34, partially disabling sandbox until CEF supports clone3()
BuildCompleteAppOverviewChange: 241 apps'

[ndavd]

For me the biggest issue with the -vgui flag is that I can't open properties of a game, it just opens a blank window. And that's a problem because I need to specify things like Proton version and DRI_PRIME=1 %command%. Is that happening to you as well?

[winchjr]

@chinoto Strangely, this works! I have no more issues.

For others using Bumblebee/Primus like me, if running from terminal doesn't work, put

primusrun %command%

in the game launch option commands.

Thanks @chinoto!

[DreamingCuttlefish]

The only ways I can get steam to open are if I open it with the commandline or with -vgui parameter set in the .desktop file. Hope to see a fix for this soon

[chinoto]

@winchjr What was happening before is that Steam, and everything it spawned, ran through primusrun, now you're only running the individual games through primusrun.

For those working around this bug for Steam by disabling DRI_PRIME, but still want/need a game to use DRI_PRIME, use env DRI_PRIME=1 %command% in the launch options, which is nearly the same as the primusrun %command% workaround I suggested to @winchjr.

[hermestrimegistus]

I am using nvidia-drivers from gentoo overlay on a PC. No primus or bumblee installed. Steam was working fine few hours ago ~20 hours. Now it won't launch. Similar errors: crash log about "libcef", SharedJSCo': ERROR: https://steamloopback.host/chunk~2dcc5aaf7.js 403 error. -no-cef-sandbox just changed a line as someone mentioned. I am able to open steam with -vgui flag but I can't run any game. It says wrong elf class for both 32 and 64 bit paths: ERROR: ld.so: object '/home/jesus12/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.