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.

[DreamingCuttlefish]

I found another temporary fix. At least in gnome, you can right click an application and click "launch using integrated graphics card. This makes it launch normally for me. If I click it normally it launches on the dGPU and crashes like others here have described.

[DreamingCuttlefish]

New steam client update didn't fix the issue :(

[ndavd]

New steam client update didn't fix the issue :(

I rly appreciate that Steam supports Linux and contributed to make gaming on Linux a thing. But man this is why I prefer open source software, if the client truly was open source we'd have at least gotten an answer from a dev by now

[ndavd]

Guys, this comment on my issue solved it for me, perhaps it also applies to this issue -> https://github.com/ValveSoftware/steam-for-linux/issues/9692#issuecomment-1605607970

[TimTheOverlord]

Guys, this comment on my issue solved it for me, perhaps it also applies to this issue -> #9692 (comment)

Followed that and can't even get to step 4 because the windows still open transparently and then close themselves after a few seconds, same goes for the Steam settings window. Only way to open anything so far is with -vgui. I followed those steps and then did -vgui to follow from step 4 forward, and it still didn't work. I'm just gonna play OpenTTD until they get it fixed (which hopefully happens before the Steam Sale).

[ndavd]

Guys, this comment on my issue solved it for me, perhaps it also applies to this issue -> #9692 (comment)

Followed that and can't even get to step 4 because the windows still open transparently and then close themselves after a few seconds, same goes for the Steam settings window. Only way to open anything so far is with -vgui. I followed those steps and then did -vgui to follow from step 4 forward, and it still didn't work. I'm just gonna play OpenTTD until they get it fixed (which hopefully happens before the Steam Sale).

I see, maybe I should share exactly how I solved it on my machine because it wasn't exactly like the comment. I simply:

• steam --reset (or steam-runtime --reset, can't recall which one I did, but I think they kind of do the same thing)
• Steam -> Settings -> Interface

• Enable Enable GPU accelerated rendering in web views (requires restart) (in the original comment it says disable, but I had it disabled by default and what solved it for me was enabling it)

  EDIT: I don't know if it matters but perhaps it's worth noting that I added back the settings in the steam.desktop file:

  PrefersNonDefaultGPU=true
  X-KDE-RunOnDiscreteGpu=true

  I'm on X11, NVIDIA.

[Candyhands]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1605700376

Thank you so much, this finally worked for me. Steam seems to be okay at the moment!! On Nvidia

[chinoto]

@TimTheOverlord There might be too many layers of other stuff going on when launching via GUI, try launching it from a terminal with either env --unset=DRI_PRIME steam, env DRI_PRIME=1 steam -vgui, or env --unset=DRI_PRIME steam -vgui. -vgui breaks the "Friends Network" for me, but I suggest it just in case it might get something to work.

[TimTheOverlord]

@TimTheOverlord There might be too many layers of other stuff going on when launching via GUI, try launching it from a terminal with either env --unset=DRI_PRIME steam, env DRI_PRIME=1 steam -vgui, or env --unset=DRI_PRIME steam -vgui. -vgui breaks the "Friends Network" for me, but I suggest it just in case it might get something to work.

Ran all three of these, only one that worked was the command with -vgui and yes, the "Friends Network" is broken as I noted in my OG comment in this chain. After running the above commands, even with the -vgui flag, it is still broken.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1605700376

Ran those, no change either. To clarify I am running on an AMD GPU with Wayland and Ubuntu 20.04. I do have AMD-Pro drivers installed.

[ndavd]

Ran those, no change either. To clarify I am running on an AMD GPU with Wayland and Ubuntu 20.04. I do have AMD-Pro drivers installed.

That's interesting because I thought Steam was working fine with Wayland non-NVIDIA setups

[DreamingCuttlefish]

Ran those, no change either. To clarify I am running on an AMD GPU with Wayland and Ubuntu 20.04. I do have AMD-Pro drivers installed.

That's interesting because I thought Steam was working fine with Wayland non-NVIDIA setups

I'm experiencing this issue on an all-amd laptop (Asus G14 2022) on gnome wayland.

[TimTheOverlord]

Ran those, no change either. To clarify I am running on an AMD GPU with Wayland and Ubuntu 20.04. I do have AMD-Pro drivers installed.

That's interesting because I thought Steam was working fine with Wayland non-NVIDIA setups

Ah, I was mistaken. It is X11, not wayland.

[266-750Balloons]

I'm experiencing the same issue as well. Using the previously mentioned work around of running DRI_PRIME directly on the games from game settings rather than on all of Steam. I'm on a dual AMD GPU setup with Debian Trixie. (Both Polaris, I think)

[ghost]

Same issue for me on Arch Linux using the latest steam update (the one with the new UI). By default Steam tries to launch with the dedicated gpu (Radeon RX 6800XT). It works fine when launching with integrated gpu (Raphael (rev c1) integrated amd gpu of ryzen 9 7950x).

[Mergpijp]

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1605700376

This seems to work once but not reliably. For me removing the two booleans works for xwayland when i run with my igpu from amd. However VRR/gsync no longer works the performance is lower and screen flickering. Disabling VRR seems the only way. There goes my nice X11, Nvidia setup.

[wojtbar]

Intel + AMD graphics card. DRI_PRIME=1 doesn't start steam ui and I can't launch the game. This command works fine for me: DRI_PRIME=1 steam -silent steam://rungameid/{game number}.

[romeroFan6268]

So, has anyone managed to fix this yet? It seems you cannot access the Steam icon from the panel, or the start menu shortcut (although the command line and selecting it from the desktop works). Also, the game "Dying Light" has some issues playing on Steam. It appears that Steam is having issues running on the new Linux Mint 21.2 "Victoria" Cinnamon Edition, which came out a few days ago. Any solutions, workarounds?

UPDATE: I forgot to mention that if you right-click the Steam icon and select "Settings," it will work. Apparently doing so bypasses the problem. Still, some problems persist. "Dying Light" has issues loading and it appears that you cannot quit the game without it crashing. I don't know if this issue is related the graphics problem that apparently is causing the problem with the Steam icon, but I thought I should mention this just in case. Again, there was never an issue like this in the previous Linux Mint version. Hopefully, this issue will be fixed soon...

[murphcid]

I have the same issue on POP!_OS 22.04 with both the repo and flatpak version of steam, it goes into a complete boot loop and after the initial start screen never comes up.
System 76 Thelio MIra AMD 7700x AMD 6600 32 gb ram POP 22.04 with all updates. Kernel 6.2.6.xxxx

I have tried it from the repo, flatpak, and direct from Steam. Any possible fix???

[266-750Balloons]

Right now, the workaround I’ve been using is to remove DRI_PRIME=1 on the Steam client, and then go into each game’s properties and add “DRI_PRIME=1 %command%” to launch options (just add DRI_PRIME=1 at the beginning of commands).

[chinoto]

@wojtbar Does env --unset=DRI_PRIME steam bring up the Steam UI? If so, you can use DRI_PRIME=1 %command% for each game's launch options like @266-750Balloons mentioned.

I mentioned env DRI_PRIME=1 %command% in an earlier comment because some shells don't provide the convenience of setting variables for a command without env, but I bet Steam runs everything through bash instead of whatever shell it was run from.