Wake me up when Steam gets native Wayland support, adds a native middle mouse autoscroll function that doesn’t rely on third party addons, AND adds a checkbox to start minimized. Then I might start using it more often. 100% native 64-bit without needing multilib repos would be nice too.
Odds are, I’ll still balk at having to use a separate DRM launcher to run my games, because I’m oldschool, but the more effort Steam puts towards feeling like a native app and not a shoehorned-in Rube Goldberg, the better.
I wonder when Valve will enable IPv6 for Steam
Original announcement instead of blog spam: https://store.steampowered.com/news/app/593110/view/678515036155543747
I wouldnt call linuxiac blog spam, but youre entitled to your opinion. Thanks for the primary source.
I have yet to encounter anything that borders on original reporting. Phoronix at least do their benchmarks.
It seems that multiarch and 32 bits packages are unfortunately still needed: https://mixed-news.com/en/steam-linux-client-64-bit-runtime-container-multilib-still-required/
Probably will be up until 2036
“and it requires an X11 server, “either Xwayland or an X11 session”, which leaves a pure Wayland session with no Xwayland unsupported.”
and still no native Wayland.
Doesn’t fix the dependancy issue but you can make your life easier by adding PROTON_ENABLE_WAYLAND=1 to /etc/environment
At least then it defaults all proton games to pure Wayland instead of XWayland so you don’t have to manually do it for every game.
I’ve been running it as a Flatpak, I wonder if this changes anything.
The beta failed to load fo Flatpak Steam.
Are you able to confirm if this full release works correctly in Flatpak steam?
I have version 1794424036 running (just updated) and I can’t say I notice anything different.
Anyone know if this removes the need for the Bubblewrap container on NixOS? That causes issues with asynchronous reprojection in Steam VR meaning you have to circumvent it with a different runtime (not ideal for if they ever let me order my Steam Frame)
I don’t remember having to do that on my “Steam Machine” which is a desktop running NixOS. This is most of my “VR” module:
environment.systemPackages = with pkgs; [ iw ]; nixpkgs.config.allow32Bit = true; # Steam Frame dongle requires a region be set to work boot.extraModprobeConfig = '' options cfg80211 ieee80211_regdom=ES ''; # SteamVR requires CAP_SYS_NICE, this patch allows it to have it # WARNING: This allows any application to create high priority contexts boot.kernelPatches = [ { name = "amdgpu-ignore-ctx-privileges"; patch = pkgs.fetchpatch { name = "cap_sys_nice_begone.patch"; url = "https://github.com/Frogging-Family/community-patches/raw/master/linux61-tkg/cap_sys_nice_begone.mypatch"; hash = "sha256-Y3a0+x2xvHsfLax/uwycdJf3xLxvVfkfDVqjkxNaYEo="; }; } ]; # SteamVR environment variables environment.sessionVariables = { # Force XCB platform for SteamVR under Wayland (prevents Qt Wayland issues) QT_QPA_PLATFORM = "xcb"; };It’s been working with my Frame perfectly.
Ah, you’re using the kernel patch, I’ve been a bit worried about that due to the security risks. It would be nice to be able to use it without it. Currently I’m using WiVRn (which uses the Monado runtime, fully FOSS which is nice) with a net-blocked Quest 2. I’m still on the waitlist for the Frame so I’ll be lucky if I get one by 2030 anyway :(
But does the capsysnice thing has to do with it being 32 bits? I thought it was an independent issue.
Also, good luck with the wait-list, hopefully you’ll get your email soon.
I was referring more to the fact it now uses its own container. It’s bubblewrap that causes the need for a workaround
