NGnius
commented
1 year ago There's a front-end JS API exposed in SteamClient.System.Perf that also has similar functionality. The most notable difference I've seen is that it's encoded in base64, though I haven't bothered to convert it into anything else to see what exactly is encoded there. I'm not sure how settings are applied, but a call from the frontend may be the best way to get it to actually apply settings.
I'm very hesitant about messing with Steam settings, or accepting a PR that would do that.
- There is no guarantee that the format of the binary representation won't change, potentially breaking the entire steam client
- The frontend part of this might also be required, but that's another point of failure since it has no guarantee of stability
- I don't particularly like VDF, but at least there's Rust parsers for it
- This change would only ever apply to Steam Deck but would affect more than just the Steam Deck driver components in PowerTools
- PowerTools tries to give priority to Steam settings; completely overriding them is a complete reversal of intent
- This would be a side-effect which is not immediately apparent to users
You've raised some good advantages too, but I'm not sure they fix the problem any better than a bit of common sense and maybe a mention in the FAQ.
Please confirm
Describe what you'd like to be able to do
PowerTools semi-duplicates the options that's in the 'Performance' section.
I'd love to have all options in one place rather than having to go to two different sections.
I'm also concerned that opening or going to Steam's default 'Performance' I may accidentally reset or set the options that I'm tinkering with in PowerTools, eg. TDP.
The 'Performance' settings are in:
/home/deck/.local/share/Steam/config
It looks like:
"InstallConfigStore" { "Software" { "Valve" { "Steam" { "Perf" { "GameProfiles" {
So you can find 'Global', and 'App'. Then it's separated by AppID.
Each AppID has the settings in the Performance menu stored as a hex value. For example:
"1174180" { "0" { "0" "08b009102818002000280f300138dc0b400448005000580060006828700178018001058801900190019001980101" } }
And this can be manipulated manually. You can re-check this file after changing a setting, and determine which hex value it's adding to the string.
For example you can change the TDP value manually in hex, and extend it beyond 15, though it then sets both fast/slow to the same value if you monitor /sys/class/hwmon/hwmon4/power1_cap / /sys/class/hwmon/hwmon4/power2_cap
Describe alternatives you've considered
At the very least, check the config.vdf and clear out any settings relating or that cross over with those set in PowerTools so that the two don't have an option to conflict. Having one 'master' place where they're set and set reliably at least reduces user confusion - and you can check if the settings in config.vdf would conflict or are set outside of the 'per game profiles' set in PowerTools.
Basically put, this allows for some validation in settings and reducing any conflict to know what should be happening.
Anything else?
Sometimes a game or application can cause for a 'temporary' file to be created. config.vdf.somethingsomething and it may store the values elsewhere, but ultimately changing the contents of config.vdf is always seen as the 'master'.