Mushitags

Valve has begun the broader deployment of SteamOS 3.9, marking one of the most substantial architectural shifts for the platform since its pivot to Arch Linux. While minor point releases often settle for incremental Steam client adjustments and localized driver patches, SteamOS 3.9 modernizes foundational system components that define how the handheld manages display composition, power states, wireless handshakes, and third-party silicon. For handheld enthusiasts and users of community distributions like Bazzite and CachyOS, the changes in SteamOS 3.9 serve as a bellwether for the entire portable Linux ecosystem. Beyond surface-level polish, this release reveals where Valve is directing its engineering efforts: untangling SteamOS from Deck-specific hardware assumptions and paving the way for a more versatile, device-agnostic operating system. ### Core Upgrades: Linux Kernel 7.2 and Plasma 6.7.3 The centerpiece of SteamOS 3.9 is a rebased base system featuring Linux Kernel 7.2 and an updated Arch Linux package repository. Moving past the long-standing 6.x kernel baseline brings crucial scheduler refinements, modernized power-capping telemetry, and expanded support for contemporary x86 APUs. For day-to-day Steam Deck users, one immediate benefit is optimized idle power consumption when no active audio streams are playing—an edge case that previously kept audio subsystem clocks higher than necessary. In Desktop Mode, SteamOS makes a major generational stride by adopting KDE Plasma 6.7.3, replacing older Plasma 6.4 builds. Operating under pure Wayland by default, Plasma 6.7.3 delivers noticeably smoother desktop window animations, resolves longstanding fractional scaling blur on high-DPI external monitors, and significantly stabilizes USB-C docking behavior. Gamers who routinely dock their handhelds will find that hotplugging multi-monitor setups and negotiating Variable Refresh Rate (VRR) over DisplayPort alt-mode no longer trigger erratic display composition loops or broken frame limiters. ### The Wi-Fi Overhaul: Why Valve Reverted to wpa_supplicant One of the most consequential yet surprising decisions in SteamOS 3.9 is the transition of the default wireless networking backend. For fresh installations, Valve has replaced Intel's modern `iwd` daemon with the venerable `wpa_supplicant`. While `iwd` was originally favored across lean Linux distributions for its minimal memory footprint and fast initial scan loops, real-world deployment across millions of diverse consumer routers and enterprise networks exposed subtle edge-case friction. In particular, users frequently encountered dropped handshakes, failures when connecting to hidden SSIDs on the first attempt, and stubborn reconnect delays when resuming the console from deep sleep. By returning to `wpa_supplicant` with custom fast-reconnect patches, SteamOS 3.9 substantially cuts the time required to re-establish an encrypted Wi-Fi connection upon waking the handheld, ensuring cloud saves sync immediately and multiplayer lobbies don't drop abruptly. To prevent regressions for existing setups, this change applies out-of-the-box only to clean installations, though existing users can toggle the backend manually in Developer Settings. ### Hibernation Groundwork and the Holo Refactor Under the hood, Valve's system engineers have completed a systematic renaming of core platform packages, migrating internal scripts from the legacy `steamos-` namespace to `holo-`. While backwards-compatible symlinks and aliases remain fully intact to protect custom pacman hooks and decky-loader plugins, the semantic shift is deliberate. Holo is the internal codename for Valve's standalone operating system stack, and stripping the Deck hardware prefix is a technical prerequisite for an eventual general public release of SteamOS on rival PC handhelds. Complementing this reorganization is preliminary kernel-level support for system hibernation (suspend-to-disk). Although fast suspend-to-RAM remains the primary sleep state in Game Mode, reliable hibernation support is essential for safeguarding game state when battery voltage drops below critical thresholds during extended sleep sessions. ### Third-Party Handhelds and VM Compatibility SteamOS 3.9 also expands Valve's testing perimeter across alternative hardware profiles. The update incorporates preliminary driver hooks and brightness-control logic for alternative hardware, including fixes for suspend/resume crashes on discrete RDNA 1 and RDNA 2 graphics configurations. Furthermore, the bootloader has been updated to accommodate stricter UEFI implementations across mainstream laptop and handheld motherboards. Virtualization enthusiasts also benefit from enhanced guest support under accelerated hypervisors using `virtio-gpu` and `venus` Vulkan passthrough, making it significantly easier to run performant, sandboxed SteamOS environments on standard Linux workstations and developer rigs. ### Verdict and Ecosystem Impact SteamOS 3.9 illustrates that Valve's platform ambitions extend far beyond defending its own hardware perimeter. By updating to Kernel 7.2, stabilizing Wayland composition on Plasma 6.7, and resolving real-world networking quirks, Valve is polishing the foundational layer required for a seamless console-like PC experience. For existing owners, it represents a substantial upgrade to system stability and docked productivity. For the broader handheld landscape—already explored in our foundational guides to [SteamOS setup and compatibility](https://www.mushimu.com/post/8729) and [Bazzite on handheld PCs](https://www.mushimu.com/post/8728)—it demonstrates that the software race to power next-generation portable gaming PCs is accelerating. ~SteamOS ~SteamDeck ~HandheldPC ~LinuxGaming ~Valve

Valve has implemented a major overhaul to its Steamworks submission and build review process, introducing stricter pre-release requirements aimed at tackling severe backlog delays. Over recent months, an unprecedented surge in submissions—heavily exacerbated by low-effort titles and asset flips—had stretched the typical store page and build approval turnaround from three to five business days to as long as twelve business days, creating unpredictable scheduling bottlenecks for independent and mid-tier studios. At the center of the updated policy is a mandatory five-minute client validation test. Developers must now install their release candidate build directly through the Steam client and actively play it for at least five continuous minutes before the system unlocks the formal Submit for Review button. Valve automated backend tracks this telemetry to ensure basic depot packaging, runtime launch parameters, and executable binaries initialize correctly before human reviewers inspect the build. Alongside the runtime verification, Valve has expanded its pre-release checklist with stricter configuration audits. Developers must now explicitly declare and test common redistributable packages (such as DirectX and Visual C++ runtimes), confirm that Steam Cloud save paths successfully write to remote storage during live play, and verify achievement metadata to eliminate placeholder icons and duplicates. Additionally, store page screenshot guidelines are being enforced more aggressively, requiring studios to categorize promotional concept renders separately from genuine in-game captures. The tighter intake controls represent Valve most assertive administrative adjustment to Steam publishing pipeline in years. While the added verification steps introduce minor operational friction for legitimate creators, the developer community has largely welcomed the initiative, anticipating that filtering out broken and unplayable submissions will restore review queue turnaround times ahead of the competitive holiday release window. ~Gaming ~Steam ~Valve ~PCGaming