Incorporate or Synchronise with Steam's "Performance" in QAM #88

New issue

Open

opened 2023-03-27 22:34:36 +01:00 by syberphunk · 2 comments

syberphunk commented

2023-03-27 22:34:36 +01:00

(Migrated from github.com)

Please confirm

I have searched existing issues
This issue is not a duplicate of an existing one
I will fill this out to the best of my ability

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'.

### Please confirm - [X] I have searched existing issues - [X] This issue is not a duplicate of an existing one - [X] I will fill this out to the best of my ability ### 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'.

NGnius commented

2023-03-28 17:41:09 +01:00

(Migrated from github.com)

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.

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.

NGnius commented

2023-04-07 00:03:47 +01:00

(Migrated from github.com)

Someone else (Uknys on Discord) who was working on reverse engineering the hex data for configs found the exact format of it: 85eddaab4f/steam/steammessages_client_objects.proto (L297)
(A Steam client protobuf)

Just throwing this here to keep everything in one spot

Someone else (Uknys on Discord) who was working on reverse engineering the hex data for configs found the exact format of it: https://github.com/SteamDatabase/Protobufs/blob/85eddaab4f93e33b9e178f702aa844fbdc2d32c2/steam/steammessages_client_objects.proto#L297 (A Steam client protobuf) Just throwing this here to keep everything in one spot

👍 1