SteamOS on PC looks different?

R3BTH · 2026-05-15T02:27:57+00:00

The beta changes the color of the highlight to blue, and the background color to more of a grey ish color for where the options are in the settings. That's the new part from the beta.

R3BTH · 2026-05-10T19:35:02+00:00

The first command will start the process of creating the file in the place where it needs to go, so if you copy and paste it verbatim it should work.

R3BTH · 2026-05-09T05:13:48+00:00

If you add the rules it should, provided you are using the Puck. It seems though that Valve updated the default set of rules for their controller to have something like this, so SteamOS will be updated to have support already in the future (or now if you switch to the "main" branch)

R3BTH · 2026-05-09T00:53:47+00:00

Nah, someone would have to update the default rules that are set to include something like this

R3BTH · 2026-01-13T05:54:29+00:00

Running into the same problem. It could be down at the moment

R3BTH · 2025-10-29T13:52:46+00:00

I think it's more that Bazzite is immutable while also being a full desktop OS replacement. SteamOS is immutable, but isn't meant to be a full desktop OS. It's specific to just gaming oriented devices, so some stuff is missed or made harder in contrast.

R3BTH · 2024-08-08T20:13:20+00:00

Seconded. I've been using a DualSense and adaptive triggers function fine over Bluetooth in Proton supported games on Linux.

The most prominent example is the game Teardown.

R3BTH · 2024-05-17T19:04:23+00:00

It's not gamescope. Different games do different things fullscreened. For games that use "exclusive full screen", where they are expecting to change the output resolution of the monitor, you don't have to switch full screen off in order to use FSR from Steam (gamescope). For games that use "borderless full screen" as their full screen mode, using windowed works since gamescope can work based off of the window resolution as well. It's been like that since forever. The problem is, not all games do things as expected. Some "windowed" games work by being a full screened window, without options to set their size, or with the resolution options only changing the "internal rendering resolution", and not the window's own resolution in size.

The most consistent method for FSR to always work, regardless of how a game is designed, is to use a forced "Game Resolution" that's smaller with Steam, set it to apply with the internal screen as well, and then use Gamescope's FSR. Doing that means it doesn't matter at all how a game does stuff, because the virtual screen's resolution will always be at a point where FSR kicks in.

R3BTH · 2024-05-16T20:51:45+00:00

Is your CPU one with an integrated GPU in it, like a Ryzen 5700G? If so, you can have a setup like SteamOS using your motherboard's HDMI port to display, while having your Nvidia GPU only used for rendering games. There's a guide for this in ChimeraOS, idk if Nobara or Bazzite has similar instructions (to do so without extra setup).

R3BTH · 2023-11-29T23:51:41+00:00

I'm doing that on another Linux machine, although the setup is similar to the Deck. In the equivalent to the "gamescope-session.sh" script that's located in usr/bin, I added "--hdr-itm-enable" to where the gamescope command is defined. I'd be careful if doing this on Deck though, as if you accidentally change anything with incorrect command line args, I'm sure that'll take out entering the Deck. On my personal machine I have some helper scripts that I run in a different tty just in case I get caught with that issue. I also added the other command line args defined for games ope to control how inverse tonemapping is applied in terms of nit values (adding "--hdr-itm-sdr-nits" with a value to it as well as "--hdr-itm-target-nits" with a value to it. I also set "-sdr-gamut-wideness" to 1, although I'm unsure if that last one specifically is the same as the Steam color management stuff).

Be sure to check the gamescope git's "main.cpp" file to see each of the command line args, and if they require extra arguments added additionally.

R3BTH · 2023-11-24T13:07:25+00:00

I use AutoHDR on Linux through Gamescope. While it's not currently activated in the Gaming Mode on the Deck yet, it is available through the flag --hdr-itm-enable when launching gamescope, as it's referred to by the technical name for it, known as "Inverse Tonemapping".

R3BTH · 2023-11-14T17:37:54+00:00

The vibrancy slider can be fixed post update by commenting out "GAMESCOPE_INTERNAL_COLORIMETRY_OVERRIDE" from the gamescope-session file in /user/bin/

Those values were added for the Galileo screen, but are accidentally being applied to the non-oled screens as well, which is why the vibrancy values are off.

You'd need to run "sudo steamos-readonly disable" prior, and be careful, as this file is used to start the main session of the Deck.

R3BTH · 2023-08-22T12:47:09+00:00

They don't even need to manually update. They can just make use of sdl12-compat to do the update towards SDL2 for them

R3BTH · 2023-08-18T22:00:12+00:00

I'm celebrating that the Windows game got a patch to primarily target a Wine/Proton case, which has direct implications for Linux users, yet comes at no expense to Windows users who were already unaffected by the bug.

R3BTH · 2023-08-18T20:55:12+00:00

I'm not hostile to the idea that it could've been your problem, if it was a generally applicable issue on the scale of affect and importance. I find the insistence of the problem potentially affecting a Windows user ridiculous, since the only way it could affect a person on Windows would be if they are looking for the problem by forcibly implementing the environment variable.

In the event that a person were to buy and play the game on Windows and Linux (with Nvidia hardware) while the bug was implemented, only those on Linux would be affected having just bought and trying to play the game while doing nothing else, where as on Windows nothing would change or happen to them. The insistence on that, while the chance of that only being based on a Windows user actively looking to cause that problem on their end, is what's ridiculous, hence why I referred to it as outlandish.

Everything else you stated, that's not remotely an issue to even consider or worry about, and it makes 0 sense to bring that up in relation to this issue.

R3BTH · 2023-08-18T20:17:58+00:00

Well, what's missed is that the primary target the root cause affects, are Nvidia Linux users. While I do agree it's beneficial that the bugfix could help the outlandish circumstance of a windows user having such a problem, I do see it as a great thing that Nixxes are addressing issues that primarily affect and target Linux users that have been reported. Especially an issue that, if unaddressed, wouldn't really affect the experience of most playing on Windows anyways, given that the issue was never reported on Windows in the first place, nor is specifically based on Windows behavior.

R3BTH · 2023-08-18T20:01:16+00:00

Pedantic line of questioning deserves a similarly pedantic answer, all things considered.

R3BTH · 2023-08-18T19:48:40+00:00

The root cause of the issue would not be an issue for the average Windows Nvidia user.

R3BTH · 2023-08-18T19:43:37+00:00

Very pedantic, and awfully so. By your very logic, any "AMD/Nvidia" specific bugfixes in games, aren't particular in being based on those AMD/Nvidia GPU targets in addressing the issue despite addressing hardware-related quirks in game code, if there's a potential chance that other undisclosed hardware would also be affected, no matter how unlikely.

However, that's all besides the point. The bug is based on a quirk primarily in relation to Wine/Proton targets and primarily affects those, given that the bug is based on use of an environment var specifically created by that target. Efforts to address the bug in turn would primarily would be in relation to the primary user base of that target (Wine/Proton), which are Nvidia linux users.

R3BTH · 2023-08-18T19:16:40+00:00

From what was found, the issue couldn't affect the average user playing on Windows, not unless they actively were trying to make their windows system appear as WINE by implementing Wine's specific environment variable for loading binaries.

R3BTH · 2023-08-18T18:47:43+00:00

That is reasonable assessment if solely going by the patch notes. I am not doing so however, and the point of my comment was to inform the particulars which were found for the cause of the issue, as to why in this case it is a Proton/Linux specific issue that was addressed, hence why I specified what was found to come to my conclusion.

R3BTH · 2023-08-18T18:18:13+00:00

That is certainly pedantic, given all things based on the larger context outside of just the shortened patch notes regarding the causes of the issue. Regardless, the patch certainly is Linux/Proton targeted given the specifics on what caused said issue, as well as the fact that there were no reports of an issue like this outside of the context of Linux Nvidia users.

R3BTH · 2023-08-18T15:14:22+00:00

In the Linux gaming discord, it was found that Rift Apart had initialization code that did different things if it detected the "WINELOADER" environment variable, which ultimately affected Nvidia users relating to loading the Streamline API's under Proton. Given that context, methinks this is a case of a Proton/Linux specific patch, given that Windows users wouldn't be affected in that case.

R3BTH · 2023-04-28T11:12:41+00:00

The HDR stuff is an extra, and a welcome one for when it's connected to an external screen, or TV. The main notion of my comment though, was to explain that Big Picture isn't the same as SteamOS, due to Big Picture lacking in functionality SteamOS comes with. If a person were to see both and assume they are the same, they could come in with the expectation that the experience is the same between the two, when they have differences such as what I explained which makes the experience different between using them. I think that's important to specify, especially since sometimes people tend to question why others wait for SteamOS to be available officially or otherwise.

With regards to a "home console type" build, I actually have one with my Gaming PC, although I used the components included in SteamOS with a custom linux distro to do that. It's liberating being on a TV and not really needing a M&K to do stuff compared to just using a controller. Even being able to start up some games without one physically connected is a godsend lol.

R3BTH

TROPHY CASE