Open koresh-krasa opened 1 year ago
can you test
DRI_PRIME=1 glxgears
https://github.com/ValveSoftware/steam-for-linux/issues/9383#issuecomment-1527215827
This works fine from flatpak sandbox with same runtime as Steam
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.
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:
@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)
@kisak-valve I see 2 issues here:
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
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.
Re-reading this issue report, it should be noted that the common case where
DRI_PRIME
gets set is from the desktop environment seeingPrefersNonDefaultGPU=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.
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.
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.
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 seeingPrefersNonDefaultGPU=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
@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.
Re-reading this issue report, it should be noted that the common case where
DRI_PRIME
gets set is from the desktop environment seeingPrefersNonDefaultGPU=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 @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 removeX-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.
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
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?
If I simply run steam
all is well; but if I run env DRI_PRIME=1 steam
; steamwebhelper
s 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.
Removing
PrefersNonDefaultGPU
andX-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.
Thanks! And actually I just realized that today it's not opening again, even with those options set.. Any idea?
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
@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.
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:
/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
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
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
@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.
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'
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?
@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!
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
@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.
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.
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.
New steam client update didn't fix the issue :(
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
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
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).
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 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.
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
@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 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
, orenv --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.
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
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.
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.
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)
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).
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.
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}.
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...
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???
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).
@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.
Your system information
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.txtSteam 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: