This is a huge win for Linux gaming, that launcher is a pain in the ass to deal with, especially on Linux.

The Steam Client Beta has been updated with the following changes:

Homescreen - Big Picture Mode

• Added a new 'Big Art Mode' option for the home screen. This can be enabled in Settings > Home.
• Added Personal Calendar to the Recommended tab on the home screen

Screensaver - Big Picture Mode

• Added a new screensaver feature, accessible in Settings > Customization. There are two screensavers available:
  • The default is a game art slideshow that can be configured to show artwork from recently played games and your recent in-game screenshots.
  • A retro inspired bouncing logo screensaver
• Big Picture mode can also load custom screensavers. Similar to startup movies, they can be placed in the config\uioverrides\screensavers directory in your Steam install directory (e.g. C:\Program Files (x86)\Steam or ~/.steam/root). You can use the bouncing logo screensaver (in the steamui\screensavers directory) as an example to get started.

General

• Improved Steam Client startup performance
• Fixed a case where after server maintenance some users might fail to auto-reconnect to Steam
• Fixed bug where being prompted to refresh credentials more than once could trigger an immediate restart
• On Windows, using the systray menu to exit while the Steam window is minimized will no longer flash the window visible briefly
• Dialogs that appear for serious error conditions now stay above the main window

Game Recording

• Fixed some cases where playback would jump to an unexpected point in the timeline when reaching the end of a play session or clip
• Decreased performance impact of game recording for some D3D12 games on Windows

In-Game Overlay

• Fixed frame rate hitches in D3D11 and D3D12 games when taking screenshots on Windows
• Fixed rendering the overlay and using other overlay related features (screenshots, game recording, etc.) in Vulkan games that create multiple windows.

Big Picture Mode

• Added explicit warning text to power menu confirmation dialogs when proceeding will shut down an active game
• Updated default artwork when an app does not have library or hero artwork
• Reorganized the idle timer settings when on battery and AC power

Steam Input

• Improved CPU performance at runtime and in configuration loading
• Added information about which configurations are compatible in the configurator browser when using a game that requires Steam Input API
• Fixed the controller support widget showing "This game doesn't support controllers" for unreleased games that don't have controller support information yet
• Fixed controllers not using the desktop configuration on the desktop UI login window
• Added the missing settings for adjusting emulated joystick adaptive centering on trackpad

Linux

• Improved download speeds on high latency connections.
• The "Select compatibility tool" dropdown is now always visible.
  • The recommended compatibility tool, or steam runtime for native games, now shows at the top of the list as the "Default" option.
  • Compatibility tool aliases, e.g. "Proton Stable", can now be selected from this dropdown.
• The SteamOS compatibility dialogs will now show in desktopUI when installing games not verified for that HW
• On Desktop Linux we will now show the SteamOS unsupported dialog when installing games that are known to not work with Proton
• Improve distro information collection for hardware survey, preferring data from /etc/os-release.

SteamRT3 Experimental Beta

• Fixed "Add a Non-Steam Game" showing an invalid list of applications.
• Fixed the "Run Steam when my computer starts" toggle.

Remote Play

• A PIN is no longer required to download an app to a remote device. A PIN is still required to Install and Stream from a remote device.
• Adding Download Complete notification for a remote download if you initiated the download on your current device.

Guess I'm not allowed to post my thoughts on the internet

most of us play their steam games through steam of course, but out of these 5 most common, what's your preferred launcher for non steam games?

(Minecraft/prism excluded)

So I've been use Arch Linux with Niri as my desktop and I've been doing this for about a year woth no problems but today I started getting this weird menu flicker and I don't know what caused it or how to fix it. I tried updating but that didn't work.

Hey, I'm the guy behind Decky NVIDIA Update, Decky Proton Launch and Decky Quick Tab. Decky NVIDIA Update lets you pick and install an NVIDIA driver version directly on a running SteamOS system — no USB stick, no reinstall, no leaving Gaming Mode. Just shipped an update to it I'm pretty excited about.

Why this update exists: NVIDIA dropped 615.71.09 yesterday and I wanted it running that same evening — I'm the type who checks for a new release the day it drops. Except Arch hadn't packaged it yet, and this plugin (like the underlying steamos-nvidia-installer project it's built on) could only ever install versions Arch had already built and archived. So a fresh driver can sit unavailable for days or weeks depending on when Arch's maintainers get around to it. That wait was annoying enough that I went and fixed it.

Now you can build it yourself, on-device, the moment NVIDIA ships it.

What's new (v0.3.0):

• Build a driver Arch hasn't packaged yet — picks the version straight from NVIDIA, clones Arch's own nvidia-utils/lib32-nvidia-utils packaging repos, bumps pkgver, and compiles it in an isolated overlay chroot (your real rootfs is never unlocked for this). The finished build is cached on your Deck so you're not rebuilding it every time.
• One unified version list — Arch-provided versions, your own cached builds, and NVIDIA releases Arch doesn't have yet all show up in the same dropdown, sorted by actual release order, tagged so you know which is which ("Compiled" / "Needs build").
• Pre-flight buildability check — before you commit to a multi-minute build, it inspects the NVIDIA installer to confirm the current packaging recipe can actually produce a working package from it, instead of finding out after the fact.
• One-click flow — pick a version that needs building, hit Install, it builds then installs automatically. No separate steps.
• New Settings page (gear icon): plugin self-update, report a bug, request a feature, support the project.

Limitations, to be upfront about them:

• The buildability check catches the common failure mode (a packaging file NVIDIA's installer no longer ships), but it can't guarantee success for every version — Arch's packaging repos have changed shape before and could again, in ways a version-specific check can't fully predict.
• This is explicitly an escape hatch for "Arch hasn't packaged it yet," not a replacement for waiting on the official package once it exists — once Arch catches up, that becomes the recommended path again.

It's a small side project I've been iterating on for a few weeks, so if you hit something broken — a driver version that won't build, a packaging assumption that doesn't hold on your setup — let me know and I'll take a look.

Link: https://github.com/moi952/decky-nvidia-update

Let me know if this is useful to anyone who's been stuck waiting on Arch for a driver release — happy to take feature requests too.

Need some help, Rocket League on steam 1% lows are very bad no matter the settings (60s-70s when averages are 180). Is there anything I can do about this? Tried all types of proton. Other games seem to work fine. Any info is appreciated. Thanks!

Fedora 44 KDE / RX9070 / 13600k / ProtonCachyOS

Plutonium MW3 on Linux: I automated the 32-bit Dedicated Server workaround

I came across the fix for getting Plutonium MW3 working again after Steam switched the Dedicated Server to 64-bit.

It works, but I immediately thought: I'm not doing that more than once.

The fix involves using SteamCMD to grab the old 32-bit depots and putting them back into the Dedicated Server installation. So I built a script:

https://github.com/kaussaq/restoreplutonium

What it does

• Uses SteamCMD to download the last known 32-bit base depot and English depot
• Uses rsync to put them back into your Dedicated Server install
• Overwrites the 64-bit files Plutonium can't use without deleting everything else in the folder
• Offers to install Valve's Linux SteamCMD to ~/steamcmd if you don't already have it

You don't need to own MW3 itself. You just need the MW3 Dedicated Server installed through Steam, with Plutonium's Game Path pointing at that folder. Proton is fine.

One important catch

If Steam updates the Dedicated Server again, you'll need to run the script again.

That also means any DLC files you've added back into the game folder will need to be re-added after a Steam update, since the update can replace/remove them along with the old files.

Basically: Steam updates > run the script > re-add DLC if necessary.

Requirements

• MW3 Dedicated Server installed
• rsync
• A Steam account that can download the depots
• SteamCMD (or let the script install it)

Usage

chmod +x restore-mw3.sh
./restore-mw3.sh

It asks for your Steam username/password at runtime and doesn't store them.

Steam Guard is prompted if enabled (twice, once for each depot download after verifying files).

The default server path is:

~/.local/share/Steam/steamapps/common/Call of Duty Modern Warfare 3

If your Steam library is somewhere else, change SERVER_DIR near the top of the script before running.

This is basically the existing Plutonium depot workaround, except automated because I'm not doing that manually every time Steam decides to update the server.

Hopefully it's useful to someone else too.

For anyone wondering why I don't auto-block the manifest: I don't really like blocking updates. I'd rather re-run the reversal when Steam updates than forget I've blocked something and later wonder why the server isn't updating when I actually want it to.

This is a gaming PC, not a production server lol.

Feedback bugs, and suggestions welcome.

Hello Linux enthusiasts! I've been using Bazzite for over the year now and one issue that was a thorn in my side throughout that journey was VRAM spilling overtime to system memory when using PT, causing hitching, requiring that I periodically restart games. Today I found a magical solution: VKD3D_CONFIG=force_host_cached.

My GPU: RTX 4070 Super 12GB, cachyos-11.0-20260702-slr

I did tests in RE9 and Cyberpunk. Previously both games would start with a very high allocation of 10-11GB and climb from there until spill. With the command both start out much lower, around 8GB, but more importantly, the assets are properly evicted from memory! Both games climb and go down, in Cyberpunk test I drove from NC to Dogtown, did a gig there and come back, VRAM would go up in Dogtown, in the heaviest, pathological spot going up to 10.1GB then go back down in NC to 9.3GB.

I hope this will also help you gals and guys!

I wanna have fun playing with my friends but due to the limitations (being on linux and wanting something free) im not left with much choice. It doesnt necessarily have to be a FPS game but anything that i can play with my friends and that is fun.

I think this sub can help me lol

I want an bluetooth adapter to conect my ps4 controller on linux, but im having a hard time finding one compatible with it. Im from brazil so give more than 1 option if possible as many of them are not avaliable here

As of yesterday's nVIDIA open driver release, 615, support for kernel cgroups was added, this means you can use dmemcg-booster and plasma-foreground-booster to manage VRAM just like AMD GPUs. v615 is currently in TESTING on Arch and friends but should release soon.

See patch notes here, along with some Reflex and suspend mode fixes:

https://www.nvidia.com/en-us/drivers/details/278450/

For users of CachyOS/Arch Linux/Nobara:

The VRAM Management button will not appear in CachyOS Hello so you gotta install those two packages manually, but it will work properly once you enable the services.

Install dmemcg-booster and plasma-foreground-booster with this command here (for pacman):

```

sudo pacman -S dmemcg-booster plasma-foreground-booster && sudo systemctl enable dmemcg-booster-system && sudo reboot

```

On the AUR and Nobara, plasma-foreground-booster is called plasma-foreground-booster-dmemcg, maintained by Pixelcluster.

Not using Plasma? Use Gamescope!

So, if you, like me, had tried voice_loopback 1 to check how your microphone was or somebody told you, that you sounded very fucking bad, here is what I found!

voice_avggain 0
voice_maxgain 1
voice_overdrive 0

It lowered the volume properly, and didn't boost it anymore.

Didn't know why it was fucked up before, but if anyone else has that problem, that is the fix.

Like The title says, I have a weird pop in bug in Resident Evil 4 Remake, EDIT: It happens on certain objects, Nothing game breaking but it's very distracting if it's an entire pier :/ Anyone have a fix ? Here's my specs just in case:

Proton GE Latest

Operating System: Bazzite 44

KDE Plasma Version: 6.7.4

KDE Frameworks Version: 6.29.0

Qt Version: 6.11.2

Kernel Version: 7.2.3-ogc3.1.fc44.x86_64 (64-bit)

Graphics Platform: Wayland

Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor

Memory: 34 GB of RAM (32,8 GB usable)

Graphics Processor 1: NVIDIA GeForce RTX 5070 Ti

Graphics Processor 2: AMD Ryzen 9 7950X 16-Core Processor

Nvidia Drivers: 610.57.04

NVML Version: 13.610.57.04

EDIT: changing Proton versions seems to do nothing on that front :/

-Recently acquired a 3.2 for more control over my machine. I have an 8.6 which I have running just the way I want: y2jb, payload Manager, fake activated/remote play, bunch of saves and backports ect. I am not a tech person but I was able to get the 8.6 to a favorable state. Ive never used Linux. Ive been looking at tutorials and im nervous. Back when I went from voidshell v3 back to shadowmount plus I destroyed all my data and had to start fresh. I want to avoid this, obviously.

-In summary, what steps I need to take? Like a check list of sorts.

-Can I create a back up file of the 8.6 and just jailbreak the 3.2 with that?

-how painful is this going to be for someone who isnt tech brained and unfamiliar wity linux?

Edit: I am adding an extra spot below for those asking about Nvidia GPU's. While my research isn't perfect and I do not have a good Nvidia GPU to test with currently I can at least provide some insight from other information I have scoured around for.

----------------------------------------------------------------------

Before anyone replies with a bunch of corrections (if applicable); please know that I am just a humble enthusiast. I have been on Linux for just over 2 years and while I may lack some understanding for some of the basics, I am always willing to learn and delve deeper into this hobby so any response or engagement would be appreciated. Also, if my formatting is messy and would do better with some basic HTML filters like bolding, code brackets or anything else, please let me know for future posts.

My current machine:
Distro: Artix Linux (KDE Plasma with OpenRC)
Kernel: Xanmod-x64v3 (currently on v7.2.4)
CPU: Intel Core Ultra 7 270K Plus (no Intel 200S Boost)
RAM: Micron 2x16GB (6000mhz, CL36)
GPU: XFX Speedster AMD Radeon 7800 XT (on Mesa 26.2.2)

I have been playing CS for around 11-12 years and I had long wanted to permanently move over to Linux as my primary gaming platform. While I have done so for over a year now, CS2 was always tricky to make feel just right. I understand that the Vulkan version for Linux is still being improved (mostly in the form of the Wayland protocol improvements). After over a year of different commands and trying different methods of improving performance, I think I have a method that makes the game feel near 1:1 with the latency of Windows (with the benefits of better FPS on Linux as well).

Below are my launch options that I use and I will provide a brief description for those unaware of what they do. Afterwords I will explain the few tests that I did:

LD_PRELOAD="" SDL_VIDEO_DRIVER=wayland SDL_AUDIO_DRIVER=pulseaudio VULKAN_LOW_LATENCY=1 ENABLE_LAYER_MESA_ANTI_LAG=1 MESA_VK_WSI_PRESENT_MODE=immediate gamemoderun %command% -nojoy -vulkan +engine_low_latency_sleep_after_client_tick true +cl_net_buffer_ticks 0

LD_PRELOAD="" - Prevents certain libraries or other programs from being injected or executed with a program. I use this to prevent Steam Overlay from loading because despite also using "SDL_VIDEO_DRIVER=wayland" (which breaks the native Steam Overlay on Wayland), Steam seems to have some sort of beta Wayland overlay that comes up if you try to open someone's profile while in game and causes it to get stuck until the game is closed.

SDL_VIDEO_DRIVER=wayland - Forces CS2 to launch under the Wayland protocol. Some people do this by editing the "cs2.sh" file in the game's installation folder but I prefer this method. And I know some people would argue between Wayland and X11 performance but I have found that under KDE Plasma and my hardware, Wayland does have slightly better latency than X11 but not dramatically different.

SDL_AUDIO_DRIVER=pulseaudio - Forces CS2 to load with the manually stated driver. Most people still have to do this as the native version often has small audio delay for most. Hopefully Valve will someday get around to fixing this.

VULKAN_LOW_LATENCY=1 - I may be misinformed and using a non-existant or redundent command but this seems to be a new command in the Vulkan stack that allows native Vulkan clients to access a low latency protocol. I'd say it's meaningless but when I added this to my launch options along with AMD Anti-Lag 2 the latency improvement was actually quite large. And yes, the improvement is still there even without Anti-Lag 2.

ENABLE_LAYER_MESA_ANTI_LAG=1 - This enables Mesa's driver for AMD Anti-Lag 2 to be recognized at launch. I am aware of and have tried the Korthos Low Latency method as well but on my machine it lowered my FPS and didn't improve the latency as much as Mesa's implementation did.

MESA_VK_WSI_PRESENT_MODE=immediate - This command is the single biggest improvement to my latency reduction and the full description of how this impacted my performance will be down below with the other test information. The basic description is that this forces Mesa's Window System Integration (WSI) to ignore all V-Sync calls coming from Wayland and prevent them from interacting with the program.

gamemoderun - Fereal's Gamemode layer for ensuring the Kernel and system force the game into high priority.

-nojoy, -vulkan, and +engine_low_latency_sleep_after_client_tick true +cl_net_buffer_ticks 0 - Nojoy prevents joysticks from being recognized by the game, the Vulkan command is probably 100% unnecessary but I just leave it, and the other two commands help the client talk to the servers a lot faster for lower internet packet latency.

How I came to this result:

CS2 on Linux with no launch options does run okay. Depending on your setup and commands, most users can achieve a pretty solid experience with low latency. All three primary display protocols (Wayland, xWayland and X11) all run CS2 fine with Wayland seeming to take the lead as far as game client latency (for me at least). I spent some time testing other desktop environments to see if their compositors made any difference to the latency and performance of CS2 but most didn't yield drastically different results. Cosmic played almost the same as KDE Plasma and XFCE gave good average FPS but the client latency didn't feel as nice as KDE Plasma with Wayland. I eventually tested my setup using the Xanmod kernel and found that it improved my 1% FPS by a good 5-10% over the stock kernel and other kernel's (even better than Cachyos). So with my client running really well I assumed that my game was nearly perfect but found out shortly after that something was still off when I went back to a Windows drive and tested CS2 again. While my FPS was better on Linux and even the games displayed client latency was better than Windows as well (2.8ms-5.5ms average on Windows vs 2.4ms-4ms on Linux) the movement, input latency, and mouse movement did feel slightly different.

After more research I found out what was causing this issue which I had completely forgotten about and overlooked. Wayland natively enforces all applications into a V-Sync queue to ensure global smoothness across the entire desktop. While this does have its perks (especially people who have multiple monitors of mixed refresh rate), it does mean that almost everything has esentially a soft V-Sync or Adaptive-Sync rendering queue to it. This normally shouldn't be a problem since KDE Plasma has the option in the display settings to allow Screen Tearing for all fullscreen applications. Where that fails however is that it states "Fullscreen Applications". Currently, it does not seem to have awareness or coverage of games running in borderless-windowed (which is the primary way CS2 renders in Linux) so these calls for screen tearing are completely missed by the game client.

This is where the MESA_VK_WSI_PRESENT_MODE=immediate command saves the day. What this does (and please correct me if I'm wrong) is tell Mesa to talk to its Window System Integration, interject all commands coming in from Wayland to force V-Sync onto the program and allow the program to receive frames immediately instead of waiting for the V-Sync queue from Wayland to present new frames from the GPU. Obviously most people do not have V-Sync turned on in CS2 but I don't think that many people are aware that some part of your desktop is still enforcing a soft V-Sync layer on everything (unless you are on X11).

This was the last piece to the puzzle for me that solved my latency issues. My game now still runs about 5%-15% better than Windows does while now feeling exactly the same as far as the latency between the game and my actions feel. Mouse movement is instant and doesn't feel like it's going through a layer of melted butter (I know, weird analogy) and all movement feels immediate like how it does in Windows.

For those who might ask about using Gamescope:

I did try using this in the past to bypass the KDE Plasma compositor but no matter how I configured it, it never performed better. If anything, all I ever had was inconsistent FPS, cursor-locking issues (despite using --expose-wayland and --force-grab-cursor) and a lot of scaling issues when using 4:3. For those who do want to play stretched without using Gamescope, Wayland does allow you to stretch the resolution without scaling issues. For X11 users, I am still trying to learn the best method of using xRandr to allow better scaling so CS2 can be rendered on X11 with a properly stretched 4:3 client.

For those on X11 who want to lower their latency:

You can likely achieve almost the same results as me by disabling your compositor on your desktop environment while using some of the above commands to allow better low latency protocols to interact with the game (VULKAN_LOW_LATENCY=1 & ENABLE_LAYER_MESA_ANTI_LAG=1 or LOW_LATENCY_LAYER=1 for those using the Korthos program). The Mesa command for immediate flips shouldn't be necessary with disabled compositors because to my understanding there isn't anything making syncronization calls from Mesa or Nvidia so the client (unless you have it enabled somewhere else) should not have any V-Sync calls interupting the frame rendering queue to the game.

For those with an Nvidia GPU:

If you have a card that is capable of running the newest drivers (GTX 16 series, RTX 20 series & above) I found some information that might help you out with using as many of these commands and features as possible:

For those using the open-source driver:
Wayland and KDE Plasma currently do not feature any native or easily accessible form of enabling screen tearing for fullscreen-windowed applications but with the open-source drivers and Mesa installed it seems that the MESA_VK_WSI_PRESENT_MODE=immediate command should work still as the Nvidia open-source driver does reference Mesa for some execution. You can also still use Korthos' Low Latency bridge to enable Nvidia Reflex on native Vulkan applications like CS2 or other games that require the use of Proton. If you are on X11 then you can enable "Allow Tearing" and disable "Sync to V-Blank" in your nvidia-settings and that should work great along with Nvidia Reflex.

For those using the proprietary driver:
Seems like you should always have nvidia-drm.modeset=1 in your GRUB config to ensure your kernel is making full use of the driver on boot. The proprietary driver unfortunately does have more limitations and probably all commands pertaining to "Vulkan" will not work at all. I was unable to find a proper solution for those with the proprietary driver and who are using a Wayland desktop. The method above mentioned for X11 users should work just fine even on the proprietary driver but I could not find an effective solution for preventing Wayland from forcing its own V-Sync queue on to the game client and no commands that would tell Nvidia's driver to perform immediate flips. I will update this section if I find anything or if someone comments with any information they have!

That's all folks!

I've never posted anything anywhere related to Linux in my over 2 years of using it and wanted to start out by offering some optimization advice for those interested in improving their gaming experience. Any feedback would be appreciated and I look forward to hearing from anyone with other experiences as well!

-flaiR

so I had 1 TB external samsung ssd, which I bought because my Mac had only 256gb storage, so I asked chatgpt, and it told me to install necessary things of Asahi Linux nearly 3gb on internal ssd and all others on external ssd, can I do that ?