I confirm and can reproduce the same behavior. These issues have persisted since the beta version, then the soft launch of the beta version, and now the forced update into the mainline stable branch of Steam. The new client is rife with blocking issues that prevent basic functionality of the app and should have been held back. Many users explicitly opted out of the beta because it is in a premature state, but now the change is irrevocable unless you use this escape hatch to load the legacy GUI.
Temporary workaround (restore bare minimum functionality) is being discussed at #9592
I confirm and can reproduce the same behavior. These issues have persisted since the beta version, then the soft launch of the beta version, and now the forced update into the mainline stable branch of Steam. The new client is rife with blocking issues that prevent basic functionality of the app and should have been held back. Many users explicitly opted out of the beta because it is in a premature state, but now the change is irrevocable unless you use this escape hatch to load the legacy GUI.
Workaround is being discussed at #9592
My question is, how a company like Valve, forces a bugdate like that one, with those bugs, hangs, errors? "Stable" they say? Hahahahahahahaha.
Additional data point: on DISPLAY:0.0, large mode etc. do not freeze/hang/crash, and the client is usable, although the various components still sporadically exhibit the "black screen until navigating to other components of the client" bug reported elsewhere (e.g. #9598). (Don't have a reliable way of triggering this behavior right now.)
I always run Steam on display 1, not 0 (entirely different session, window manager, and Xorg screen layout).
Additional data point: on DISPLAY:0.0, large mode etc. do not freeze/hang/crash, and the client is usable, although the various components still sporadically exhibit the "black screen until navigating to other components of the client" bug reported elsewhere (e.g. #9598). (Don't have a reliable way of triggering this behavior right now.)
I always run Steam on display 1, not 0 (entirely different session, window manager, and Xorg screen layout).
It has been that way for a while. So this behavior isn't new just worse. I have an open ticket about having to kill and relaunch Steam on 0.0 if you want to right click anything and manage the proton version, opt into / out of a beta, set launch params. Steam has been broken to some degree now for a year on any XScreen other than 0.0 but works on 0.0. I suspect in part due to the GTK issues I noted but also the horrid "we're thinking ahead to Wayland" BS the eco system is latching on to. Meanwhile Wayland is by design the Death of Multi GPU and workload segregation. This might change in the future but for now Wayland turns thousands of dollars in GPU's and turns them into crappy output splitters and dumps all the work on the primary. Somehow this is seen as "the future."
It has been that way for a while. So this behavior isn't new just worse. I have an open ticket about having to kill and relaunch Steam on 0.0 if you want to right click anything and manage the proton version, opt into / out of a beta, set launch params. Steam has been broken to some degree now for a year on any XScreen other than 0.0 but works on 0.0.
Anecdotally, the legacy client does work for me on display 1 (including changing options/etc.), but I've been deliberately holding it back for some time now until today's update eradicated that version.
There have been a few times the old client would function on 0.1 for me but without rhyme or reason then it wouldn't. In some cases it was so bad it would draw garbage to all displays connected to the GPU running 0.1 and I'd have to reboot. I still worry if I go to change launch params or proton version and right click it might nuke everything. Best case it crashes the library view and restarts. https://github.com/ValveSoftware/steam-for-linux/issues/9300
For what it is worth, I created a Xorg config for display 1 that isolates each monitor in a multi-monitor setup to a discrete screen so that they do not share their geometries with each other. I originally did this for the sake of G-sync (required a single contiguous X screen, not one spanning multiple monitors), but as a side effect, it ensures that Steam is also isolated to this screen, the cursor is pinned to the monitor, etc.
That isn't a feasible fix for me, nor should it be for anyone to appease one poorly done application. My XScreens primarily segregate GPU's so workloads can be run independently and there is no "weakest sets the bar" performance issues from xrandr "provider" or Xinerama setups. Most the things I do require all the screens on a given GPU to be usable by a single program. Like Blender requires 3 screens easy (unless you like working on uselessly small cramped spaces with everything hidden behind menus.) Same with my DAW, Inkscape...(suppressing throw up in my mouth)...Unity.
With *nix we have this power of design and flexibility but some organizations cough Gnome cough Steam are trying to Apple us...Sorry for anyone that sees this as off topic or ranty...to me it's on topic in that Games are supposed to be fun. However these days I spend exponentially more time debugging them than playing. Every update is filled with dread. What used to be "OH WOW, what great new features have they added!?" has been replaced with "Oh CRAP what did they break now!?" Steam has become a tomb of gotchas and glitches.
fwiw, starting steam with the command
DISPLAY=:1 steam
from the cli works for me
fwiw, starting steam with the command
DISPLAY=:1 steam
from the cli works for me
That syntax says you are running Gnome (see my OP ***** about XScreen syntax and Gnome) i.e. you are running Steam on 0.0 so of course it works.
That isn't a feasible fix for me, nor should it be for anyone to appease one poorly done application. My XScreens primarily segregate GPU's so workloads can be run independently and there is no "weakest sets the bar" performance issues from xrandr "provider" or Xinerama setups. Most the things I do require all the screens on a given GPU to be usable by a single program.
Certainly not, and having to do such incantations for the sake of Nvidia's haphazard driver implementation is not viable for most people, either. I offer this merely in the spirit of mentioning workarounds. Like I said above, I physically drop into a separate tty session, WM, user, and different Xorg conf when using Steam (or any native game, for that matter). I can't use Blender multimonitor or spreadsheets while playing a game, so switching between these "workspaces" isn't blocking using any other applications per se. (Might be a different story if any game actually relied on multihead.) I get that other people have different workflows and may want to jump in and out of applications, though.
I started doing this prior to the advent of gamescope, so it may be easier to properly nest applications into the right display container now. But in practice, this has been a good solution and I continue to use it even with native Wine or other applications which want to bind to the full display. Just jury-rig a script to jump between virtual ttys and you are good to go. I also prefer this because I don't think mixing tiling WMs works well with games, which oftentimes expect more of a floating window layout, and I had a whole host of problems with trying to run games in the normal workspace.
I wouldn't say this is an nVidia problem. ATI has completely broken the ability to define screen layouts in xorg making multi GPU useless on AMD. (one caveat being you have matched model/brand cards and "xinerama/provider" them) nVidia is the only manufacturer that still allows proper screen layouts in xorg. With the AMD/ATI driver it ignores anything in X and only conforms to what xrandr says which does not play well with ordering much less other GPU's. I've run dual/triple GPU (matched and mixed brand) for over 20 years but the ecosystem is slowly trying to kill the users ability to do this.
This is squarely a Steam + GTK problem. GTK broke XScreen enumeration back around 3.1-3.2. It's now hard coded and any application using various GTK functions will freak out and/or crash if it's called on anything but 0.0. Since Steam uses GTK when it calls on those functions sensitive to the hard coded single XScreen bit the "fun" happens.
Steam no longer opens at all if run on XScreen other than 0.0
Aug 02 22:39:24 localhost dbus-daemon[6818]: [session uid=1000 pid=6818] Activating service name='org.freedesktop.portal.IBus' requested by ':1.13' (uid=1000 pid=73538 comm="$HOME/.local/share/Steam/ubuntu12_32/../ubunt")
Aug 02 22:39:24 localhost org.freedesktop.portal.IBus[73540]: Not connected to the ibus bus
Aug 02 22:39:24 localhost dbus-daemon[6818]: [session uid=1000 pid=6818] Activated service 'org.freedesktop.portal.IBus' failed: Process org.freedesktop.portal.IBus exited with status 1
Aug 02 22:39:25 localhost rtkit-daemon[7029]: Successfully made thread 73546 of process 72607 owned by '1000' high priority at nice level -10.
Aug 02 22:39:25 localhost rtkit-daemon[7029]: Supervising 10 threads of 4 processes of 1 users.
Aug 02 22:39:25 localhost dbus-daemon[6818]: [session uid=1000 pid=6818] Activating service name='org.freedesktop.portal.IBus' requested by ':1.14' (uid=1000 pid=73632 comm="$HOME/.local/share/Steam/ubuntu12_32/../ubunt")
Aug 02 22:39:25 localhost org.freedesktop.portal.IBus[73634]: Not connected to the ibus bus
Aug 02 22:39:25 localhost dbus-daemon[6818]: [session uid=1000 pid=6818] Activated service 'org.freedesktop.portal.IBus' failed: Process org.freedesktop.portal.IBus exited with status 1
Aug 02 22:39:36 localhost kernel: steamwebhelper[73356]: segfault at 8 ip 00007fcc09be4d84 sp 00007ffc5cd33348 error 4 in libX11.so.6.4.0[7fcc09bd5000+8b000] likely on CPU 5 (core 5, socket 0)
Aug 02 22:39:36 localhost kernel: Code: 00 c3 0f 1f 40 00 f3 0f 1e fa 8b 87 00 01 00 00 89 06 8b 87 04 01 00 00 89 02 b8 01 00 00 00 c3 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 08 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 87 60 09 00
Aug 02 22:39:36 localhost systemd[1]: Started Process Core Dump (PID 79507/UID 0).
Aug 02 22:39:36 localhost systemd-coredump[79508]: Resource limits disable core dumping for process 73356 (steamwebhelper).
Aug 02 22:39:36 localhost systemd-coredump[79508]: [🡕] Process 73356 (steamwebhelper) of user 1000 dumped core.
Aug 02 22:39:36 localhost systemd[1]: [email protected]: Deactivated successfully.
Aug 02 22:39:39 localhost kernel: steamwebhelper[79515]: segfault at 8 ip 00007f1447d2fd84 sp 00007ffc5eef8f78 error 4 in libX11.so.6.4.0[7f1447d20000+8b000] likely on CPU 13 (core 5, socket 0)
Aug 02 22:39:39 localhost kernel: Code: 00 c3 0f 1f 40 00 f3 0f 1e fa 8b 87 00 01 00 00 89 06 8b 87 04 01 00 00 89 02 b8 01 00 00 00 c3 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 08 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 87 60 09 00
Aug 02 22:39:39 localhost systemd[1]: Started Process Core Dump (PID 80081/UID 0).
Aug 02 22:39:40 localhost systemd-coredump[80082]: Resource limits disable core dumping for process 79515 (steamwebhelper).
Aug 02 22:39:40 localhost systemd-coredump[80082]: [🡕] Process 79515 (steamwebhelper) of user 1000 dumped core.
Aug 02 22:39:40 localhost systemd[1]: [email protected]: Deactivated successfully.
Steam Version: 1694466342 ...STILL...
Just installed Steam to a VM to jerry rig game updates...same same but there is only one "XScreen" (technically none since it's an xrandr setup) and still hangs. Just sitting there at the Loading User Data spinning. Reboot, now I get a tray icon but nothing works. Kill it, restart...it signs into chat, feeds me the ad popup...nothing else and you can't interact with the UI correctly, Library/Store won't open...settings will but again the UI is dead.
I have another ticket open about Steam Survey ignoring hardware and choosing the wrong GPU. Given the issue were CS2 also "grabs" the wrong GPU combined with some complaints about Vulkan in the VM I'm starting to suspect this is all because Steam does a half a$53d job with hardware. It locks onto whatever it finds first initializes various things like Vulkan/OGL for that device then craps itself when you launch it on the intended device.
TL;DR Steam makes the wrong assumptions about hardware then poops its nappies.
...hmmmm I tried my normal launch but this time denoted the vulkan device as the original GPU I've launched on for years. Fired it up on DISPLAY=:0.1 and VOI...la? Kinda? It renders the main window with nothing in it. I get a tray icon, but the UI is borked. So more and more yeah, Steam is just not enumerating hardware, making stupid assumptions and then fails to work. YAY! Given all the back and forth where Steam Support constantly assumes multi GPU means Optimus and don't understand xrandr vs fully configured xorg.conf I'm guessing this will never be addressed...
Your system information
Steam Client Build Date: Wed, Jun 14 14:18 UTC -08:00
Steam Web Build Date: Wed, Jun 14 15:41 UTC -08:00
Steam API Version: SteamClient020
Please describe your issue in as much detail as possible:
Steam now loads the window frame but where the Store or Library should be is an empty dark blue area. The client hangs and is a PITA to kill.
Steps for reproducing this issue:
pidof steam; kill -9pidof steamwebhelperFull launch Log https://gist.github.com/nPHYN1T3/2fa7b88350372caa55987f3455212418
** As a secondary issue launching Steam on XScreen 0.0 I noticed it constantly launches the obnoxious chat window with no option to disable it. (That I could find anyhow) Launching with the -vgui also suppresses this terrible new behavior.
*** I still have an open Ticket about not being able to right click or manage things as several updates ago that was broken if not on 0.0. Like wise Steam has had another obnoxious bug that sees you with a blank white area where the Library, Store, etc should be until you click something else and come back. i.e. Steam has been injecting more and more bugs and problems with every update.
**** Steam is using GTK for various things and GTK broke (by choice) XScreen enumeration around GTK 3.1 or 3.2.
***** Denoting XScreens as 0.1 or 0.2 etc is not accurate for Gnome users as Gnome for some reason will call 0.0=1 and 0.1=2...Gotta love Gnome and their Apple like disregard for anything outside their "organizational direction."
****** kisak-valve Using "DISPLAY" is the wrong term. I have 12 screens or "DISPLAYS" this has nothing to do with the issue. The issue is when you have more than one XScreen defined. For some users they will give a GPU output "head" their own XScreen but in my case each XScreen is on a separate GPU for workload segregation. (no Xinerama) i.e. Steam runs on a "secondary/tertiary" GPU to not tax the GPU the games are launched on.