[X] I have searched existing issues and found no duplicate
[X] I will fill this out to the best of my ability
Extra details
[ ] I am using a custom pt_oc.json file
[ ] I am using a custom limits_cache.json file
[ ] I have submitted a log through the PowerTools UI
Expected Behaviour
Game A (Slay The Spire) has a persistent profile with an aggressive 400/800 MHz limit. These values should not be retained upon closing the game to ensure that it doesn’t impact the performance of Game Mode. Game Mode does not use a persistent profile, and should use the default values that it has when the Deck first boots.
Actual Behaviour
So, in Game A (Slay The Spire, for reference), I’ve set some pretty aggressive limits to reign in power usage to prolong battery life.
These are saved to a PowerTools persistent profile. The easiest value to use in this example is the CPU Frequency. I’ve set a minimum of 400MHz, and a maximum of 800MHz with SMT disabled.
Now, I noted that one of the other reports said that after setting these values, the PowerTools UI will always show the minimum frequency value as 1400MHz. This was chalked up to the Kernal not accepting values less than that, if I remember correctly. According to GameScope, the set value of between 400/800MHz is being respected, and the power draw reflects that this is working. I did rerun this with the Kernel’s minimum value of 1400MHz and noted that my issue will still occur.
So, once I’m finished playing Game A, I’ll close it to return to Game Mode. PowerTools will correctly return to the default non-persistent profile called Main. This profile has no set values, but I can tell it’s being reloaded because SMT was enabled. However, the previous CPU Frequency values have been retained, and the Steam client will cough and splutter until the Deck is rebooted. Going into Desktop Mode and back into Game Mode won’t fix the issue, as the same CPU Frequency values are reloaded upon entering Game Mode.
Steps To Reproduce
Open a game.
Set it to use a persistent profile with a lower than normal CPU Frequency range (tested 400-800MHz, and 1400-1400MHz).
Enable GameScope’s fourth detail level so you can observe the CPU Frequency.
Close the game and note that Game Mode’s CPU Frequency is locked to the upper limit set in the previous game’s profile.
Reboot the Deck and note that the values are now able to clock up and down like normal.
Anything else?
I can get you some screenshots if you’re not able to reproduce the issue. The log file didn’t have any issues noted. I could see that it successfully identified when the game opened and closed, applying the profile as required.
Please confirm
Extra details
pt_oc.json
filelimits_cache.json
fileExpected Behaviour
Game A (Slay The Spire) has a persistent profile with an aggressive 400/800 MHz limit. These values should not be retained upon closing the game to ensure that it doesn’t impact the performance of Game Mode. Game Mode does not use a persistent profile, and should use the default values that it has when the Deck first boots.
Actual Behaviour
So, in Game A (Slay The Spire, for reference), I’ve set some pretty aggressive limits to reign in power usage to prolong battery life.
These are saved to a PowerTools persistent profile. The easiest value to use in this example is the CPU Frequency. I’ve set a minimum of 400MHz, and a maximum of 800MHz with SMT disabled.
Now, I noted that one of the other reports said that after setting these values, the PowerTools UI will always show the minimum frequency value as 1400MHz. This was chalked up to the Kernal not accepting values less than that, if I remember correctly. According to GameScope, the set value of between 400/800MHz is being respected, and the power draw reflects that this is working. I did rerun this with the Kernel’s minimum value of 1400MHz and noted that my issue will still occur.
So, once I’m finished playing Game A, I’ll close it to return to Game Mode. PowerTools will correctly return to the default non-persistent profile called Main. This profile has no set values, but I can tell it’s being reloaded because SMT was enabled. However, the previous CPU Frequency values have been retained, and the Steam client will cough and splutter until the Deck is rebooted. Going into Desktop Mode and back into Game Mode won’t fix the issue, as the same CPU Frequency values are reloaded upon entering Game Mode.
Steps To Reproduce
Anything else?
I can get you some screenshots if you’re not able to reproduce the issue. The log file didn’t have any issues noted. I could see that it successfully identified when the game opened and closed, applying the profile as required.
Version
1.3.2
Platform
Steam Deck
OS
SteamOS 3 (Stable)