# System variable detection causing game confusion **URL:** \ **Category:** Wicked Bug Reporting\ **Tags:** technical-issues, linux\ **Created:** [July 17, 2026, 6:34am UTC](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831 "2026-07-17T06:34:04Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Evil1nside](https://yyz1.discourse-cdn.com/flex003/user_avatar/forum.norestforthewicked.com/evil1nside/32/9438_2.png) [@Evil1nside](https://forum.norestforthewicked.com/u/Evil1nside)\ **Post date:** [July 17, 2026, 6:34am UTC](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831/1 "2026-07-17T06:34:04Z")
Hello good people on the internet. As some of you already know, there has been an issue with the set of available resolution options in the game settings when playing on Linux. The workaround for this issue was to simply use a launch option argument before starting the game(`SteamDeck=0`) which works alright for most systems, but there are still some that doesn’t receive the same treatment. It seems like, apart from the `SteamDeck` variable detection, there’s an additional check being made by the game’s code. The same issue happened on a brand new Steam Machine with SteamOS 3.8. A user on Git was able to fix the issue by doing some claude coding. It basically edits some device metadata file in the `il2cpp_data/` folder of the **No Rest for the Wicked** game. IL2CPP looks like some backend used by Unity, and in this particular case, used by the game’s runtime to detect the device model via a `SystemInfo` lib (?) Both Steam deck and Steam Machine have names with `(Valve)` in them, which triggers the custom detection code in the game’s runtime to force handheld resolutions in the graphics options, which is wrong, and should not happen. **Proof that the issue was fixed after the above edits:** ![image](https://canada1.discourse-cdn.com/flex003/uploads/wickedforum/original/3X/d/7/d70f02fe0bdeaec57772f3f900dd04549ca22563.jpeg) Here’s an AI generated summary of the root cause and how to fix it : ### **Environment** - Hardware: Valve **Steam Machine** (_Fremont_, HawkPoint APU), SteamOS 3.8.x, Desktop Mode - Game: No Rest for the Wicked (appid 1371980), Unity 6000.1.15 IL2CPP, Proton - `SystemInfo.deviceModel` = **`Fremont (Valve)`** ### **Root cause** `The IL2CPP metadata contains the handheld-detection fields:` `s_deviceModelContainsValve` `s_deviceModelContainsRogAlly` `s_processorIsSteamDeckOledModel` `IsRunningOnHandheld / RunningOnSteamDeck / m_isSteamDeck` and the comparison string literal is **`(Valve)`** (7 chars). The check is effectively: `s_deviceModelContainsValve = SystemInfo.deviceModel.Contains("(Valve)");` Steam Deck reports `Jupiter (Valve)` / `Galileo (Valve)` Steam Machine reports `Fremont (Valve)` All contain the `(Valve)` suffix, so the Steam Machine is misclassified as a handheld. The game then re-applies handheld graphics defaults **at runtime** , overwriting any user setting (confirmed: it resets `DeviceSettings` to `1368×768`, `DRSEnabled=true`, `DRSTargetFPS=30`, `RenderScaleFSR=0.667` on the menu→game transition). A potential hotfix should be considered for the currently available EA build, as it may also help with the proper functionality of 1.0 when it comes out. Link to the original git page where the issue was discovered: > > > Hello All, > > After using SteamOS for quite some time now on many different system…s, including SteamDeck, ROG Ally, and an all AMD HTPC setup similar to the Steam Machine in terms of hardware specs, it came to me that for some reason SteamOS treats all of these systems as Steam Deck(even including the Steam Machine), and that's an issue for some games, where users are oftenly locked behind some limitations, for example not the full advanced graphical settings are available, or not the full screen resolution options are available, because the OS "thinks" it's a Steam Deck, thus limiting some games features to ensure the smoothest gameplay experience on the platform. > I'm pretty sure, you can already see where the issue is. > > The workaround: > Game Launch Options: \`SteamDeck=0 %command%\` > > This is "telling" the game that your system is in fact not a Steam Deck so that you can benefit from all ingame available settings, and features, so you can also utilize the available hardware. > > All of this is especially true for the Steam Machine, as it's way more capable then the Steam Deck, and we can only expect that most people simply want to start the system, and play their favorite titles without even thinking about all that, thus we cannot expect those same people to also be aware of these launch options, plus, they also don't always work too. > > The solution: > Fully automatic, and hardware-aware process, so \`SteamDeck=0\` is only applied on non-Deck systems, while real Steam Deck hardware keeps its default behavior. > The clean way to do this is to conditionally set the environment variable at login, based on actual hardware detection. > > What we know is that a real Steam Deck exposes identifiable system info via: > DMI/BIOS strings (\`/sys/class/dmi/id/\*\`) > Vendor/model fields like: \`Valve Jupiter\` (LCD Deck) or \`Galileo\` (OLED Deck) > > So we can check those and decide: > Is it a Real Deck? Yes, then keep SteamDeck=1 > Anything else, force SteamDeck=0 > > Example of a detection script: > \`\`\` > \#!/bin/bash > > \# Detect if running on actual Steam Deck hardware > if grep -qiE "valve|jupiter|galileo" /sys/class/dmi/id/{sys\_vendor,board\_vendor,product\_name,board\_name} 2\>/dev/null; then > export SteamDeck=1 > else > export SteamDeck=0 > fi > \`\`\` > > Example script file name: \`steamdeck-detect.sh\` > > And then just hook it into the environment \`nano ~/.profile \` > \`source ~/.config/profile.d/steamdeck-detect.sh\` > > All of this can also be introduced as a new feature as a trigger on the Steam UI, or in Gamescope, so that people can decide if they want to use the Deck profile, or the Desktop profile for their games, without the need of manually typing any commands anywhere. > > Please let me know what you think, and if this is even a feasible request. > Thank You in advance. ---
**Author:** ![crecsky](https://yyz1.discourse-cdn.com/flex003/user_avatar/forum.norestforthewicked.com/crecsky/32/17220_2.png) [@crecsky](https://forum.norestforthewicked.com/u/crecsky)\ **Post date:** [September 11, 2026, 8:55pm UTC](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831/2 "2026-09-11T20:55:12Z")
Has this error been rectified? ---
**Author:** ![yyg](https://yyz1.discourse-cdn.com/flex003/user_avatar/forum.norestforthewicked.com/yyg/32/17548_2.png) [@yyg](https://forum.norestforthewicked.com/u/yyg)\ **Post date:** [September 11, 2026, 10:32pm UTC](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831/3 "2026-09-11T22:32:06Z")
Continuing the discussion from [System variable detection causing game confusion](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831/2): you should be able to specify the string’s value of the check to match the _exact_ system you are on, if steam machine: `s_deviceModelContainsValve = SystemInfo.deviceModel.Contain("Fremont (Valve)");` please note the " " ^ above may throw a syntax error and require moving, the "quote is to prevent the compositor from reading the open and close parenthesis as its unique assigned variable in bash. you can also use \'s in replacement for your delemeters. edit 1) an easier way should just be assigning your own environment variable to the steam machine for the hardware to detect by itself with ini formatting in your .profile equivalent file of your $USER directory ---
**Author:** ![crecsky](https://yyz1.discourse-cdn.com/flex003/user_avatar/forum.norestforthewicked.com/crecsky/32/17220_2.png) [@crecsky](https://forum.norestforthewicked.com/u/crecsky)\ **Post date:** [September 25, 2026, 9:42pm UTC](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831/4 "2026-09-25T21:42:48Z")
I appreciate the manual fix, but I don’t think it should be necessary for us to have to alter our devices for something the developers can rectify in what appears to be a couple lines of code. I’ll continue patiently waiting as best I can. ---
**Author:** ![yyg](https://yyz1.discourse-cdn.com/flex003/user_avatar/forum.norestforthewicked.com/yyg/32/17548_2.png) [@yyg](https://forum.norestforthewicked.com/u/yyg)\ **Post date:** [September 29, 2026, 3:50pm UTC](https://forum.norestforthewicked.com/t/system-variable-detection-causing-game-confusion/26831/5 "2026-09-29T15:50:59Z")
no doubt! im sure it’s coming but its always fun to puzzle stuff out like this yourself too if its your cup of tea