u/deadcade

Consoles have really been getting closer to more standard hardware over the last years. The WiiU was a mostly custom PowerPC box, with a proprietary version of wifi for the gamepad, and including hardware specifically to run Wii games. The Switch was a barely modified nvidia shield, with bluetooth wireless controllers. The PS3 had a fully custom CPU, and old models included PS2 hardware for backwards compatibility, the PS4 is x86_64 with a custom AMD GPU.

For the PS4/PS5, the majority of effort on running Linux is in getting it to boot in the first place. While some hardware does require patches to existing drivers (like mesa on PS4), or sometimes fully custom drivers (like the CPU fan on PS4), other hardware is completely standard, over a standard interface. Like the HDD and Blu-Ray drives on the PS4.

The big difference is that a game console is "allowed" to deviate from standards, as it does not need to be compatible with anything outside the control of the manufacturer. This results in often small differences that require changes to a kernel which wouldn't work on any other device.

The biggest reason why emulation is hard, is often no longer the custom hardware like it used to be, but the OS and other fully custom standards like a graphics API. The structure of games is completely different too. The old "ship the drivers on the game disc" like on the Wii no longer holds true on modern consoles, and emulators don't need to ensure the exact timing of an optical drive matches to get a game to work.

There have been some attempts to get modern console games to work through kernel patches and translation layers, see horizon-linux and fpPS4, proving just how close modern console hardware is to standard PCs.

All that being said, I don't think SteamOS on PS5 would work for multiple reasons. It's extremely difficult to get the process simple enough for the average consumer, especially with Sony quickly patching any exploits required to boot it. It's also not in Valve's business interest to make it easier and explicitly supported to buy a cheaper and more powerful standardized machine. As they would just be creating a direct competitor to the Steam Machine.

Not OP but a couple things:

• It's a full controller, no "only one joystick" like the 2015 model.

• The quality of the IO is great, like the TMR joysticks, good trackpads, gyro, and nice haptics.

• If a PC runs Steam, it supports all the controllers features (in Steam). This isn't always the case on DS5/xbox controllers.

• The "puck", despite looking insignificant, makes the experience much better. Unlike Xbox with AA batteries or DS5 with USB-C charging, and both of those with Bluetooth wireless connectivity (by default). The Steam Controller (2026) is fully "pick up and start playing".

Whether it's worth the price depends on what you value in a game controller, and how much. For me, the "extra" inputs (mainly back pedals, touchpads, gyro) and accurate sticks (TMR instead of potentiometers) are worth it.

To scroll in menus or desktop, sometimes virtual menus for games requiring more buttons

it seems a bit pointless

Quite the opposite. Linux is currently frequently matching Windows in performance when running games through Wine/Proton. Targeting Linux native avoids this translation layer, and can result in better performance or less CPU overhead for the same performance (which is noticable especially on devices like the Steam Deck).

making games for Linux is ironically difficult

Yes, because of the tooling. If you make a game in Unity, and build for Windows, ""things just work"". If you then build for Linux, you can face any number of random engine issues, like bad controller support, broken mouse grabbing, etc.

as they can break as libraries change over time

Valve has thought about this, and designed the Steam Linux Runtime. This does effectively the same thing as Flatpak, except it pulls in the system native graphics drivers. Steam Linux Runtime provides effectively a full (minimal) Linux distribution that game developers can target, ensuring their games keep running, even on more modern systems.

---

Gaming on Linux has always been a chicken and egg problem. Gamers see there's no games on Linux, so they stick to Windows. Developers see there's no Linux gaming market, so they stick to Windows. With Valve's Proton, they interrupted this cycle. Most games now work on Linux, but game developers haven't switched yet. For them to switch, there needs to be a market of Linux users, and the tooling needs to be sufficiently developed for Linux, ensuring the same (or better) quality as the Windows versions of games. This includes game engines, common libraries (like online multiplayer frameworks or voicechat), and possibly development software, 3D modeling software like Blender, the Adobe suite, etc.

Can still pull off the "no computer" look with just a steam deck in a backpack. It's kind of cool(?), but definitely a lot of effort going into "un-gaming" a steam deck. A framework mainboard may be a better option for this tbh.

Client side anti-cheat is inherently flawed. These games are asking an untrusted computer whether it is cheating. That's like asking a known liar whether they're lying at that moment. The one way to make it harder for the computer to "lie" is by increasing the permissions the AC has, which comes at the cost of privacy for people with the game, and security for every Windows user (not just the ones with a certain game installed).

Client side anti-cheat can be poked and investigated locally, with no restrictions. All it takes a skilled enough cheater is time, and they will bypass it. The only way to test server side anti-cheat is by hopping in the game, trying to learn how it works, and trying to bypass it. That is a much more time consuming and expensive process.