Battery charge limit isn't reset correctly #127
NGnius
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Please confirm
Extra details
pt_oc.jsonfilelimits_cache.jsonfileExpected Behaviour
Battery charges to 100% when charge limit is turned off.
Actual Behaviour
On SteamOS 3.5, the charge limit is persistent and PowerTools does not set it back to 100% when it's turned off. Instead, the battery is limited to the value set last by PowerTools.
Steps To Reproduce
Anything else?
No response
Version
1.4.0
Platform
SteamDeck
OS
SteamOS 3 (Preview/Beta)
Prior to switching to 3.5, I had the limit set to 80% and after upgrading I noticed the charge was going up to 84%. Tried setting to various values and it looks like the 84% as a limit was stuck.
Tried going back to stable SteamOS branch and the limit seem to have persisted. Also tried to do a factory reset, the same limit is still there (84%) even if deckyloader+powertools isn't installed.
What are the commands to check the value from sysfs? and how do I manually reset it?
To read
cat /sys/class/hwmon/hwmon4/max_battery_charge_levelTo write
echo $value | sudo tee /sys/class/hwmon/hwmon4/max_battery_charge_level(will prompt for your root password)The file is missing on my deck, it throws permission errors when trying to set the value.
I'll test out the build once
46659a474dis included in a release. I currently don't have an environment to create the builds to test on my own.My OS version might be relevant:
Update: Switched back to 3.5 (Beta BUILD_ID=20230915.100), the file is in there and the value was set to 85. It looks like the sysfs method was only for 3.5?
That's appreciated. I don't currently have a timeline for the next release, but there might be a pre-release version with minor fixes soon(tm).
Yes sorry, I should've mentioned that. The method for <3.5 is not really using sysfs. The hwmon indices also changed with 3.5 (due to the updated kernel), so hwmon4 on Steam 3.4 is for a different component.
Just advising I also have this issue, glad to see you are aware I will wait for the next update thanks.
i was able to reset it to 100 in konsole using the command in this link:
https://steamcommunity.com/app/1675200/discussions/2/3186865924589640794/?ctp=5#c5992658048667347631
(which is exactly what I suggested above)
oh I see it now, sorry I am new to linux and didnt understand it. Im learning...
thanks!
FYI I ran into this issue after updating to the 3.5 official stable release (now 3.5.7) and apparently the location of the files that control the settings were relocated to hwmon3 instead of hwmon4. Modifying those instead is now allowing me to charge even above 90%.
Thanks for this awesome tool! Hopefully it can be updated soon to work with 3.5, as it really is important functionality for many users.
Hey, just a quick question. When I was on SteamOS 3.5.5, to reset to default, I did it via terminal and set it to "echo 100".
After updating to 3.5.7, I also asked a friend if I could check their Steam Deck (they never used charge limit stuff and also never changed stuff). Checking the hwmon3 settings, it said the value was set to "0". That friend says he never used charge limiting apps/features/commands.
So... default charge behvaiour value is not 100 anymore, but now it is 0? Or was it actually always 0?
Basically, I try to find out if the default max charge limit was 100 or 0.
I think this pattern is incorrect (or has become out of date); it seems like it should use a dash (
steamdeck-hwmon) instead of an underscore (steamdeck_hwmon):This is triggering a fallback to
hwmon5, which is incorrect.It's a bit concerning that you read a part of the PowerTools codebase before reading this whole issue's discussion. If you had read up to my earlier comments, you'd see that I already fixed the bug (not released, though).
I'm sorry, I was
Getting back to what I pointed out, at least for my Steam Deck, I still think this pattern needs to be updated to
steamdeck-hwmon, if I am understanding the source code here and in sysfuss correctly.Thanks for this plugin.
No worries, both are admirable goals. I didn't explain how you were wrong because I thought that would be rude. But in the interest of encouraging curiousity, here it goes (sorry in advance if this comes off as mean; my intent is only to explain):
In short, if
steamdeck_hwmonwere incorrect none* of the battery functionality would work at all, not just this specific case.When sysfuss looks for a hwmon by name, it uses the name attribute of the sysfs entry (i.e.
/sys/class/hwmon/hwmon#/name), not any part of the resolved (de-symlinked) path. In my sample size of 2 (1x LCD, 1x OLED Deck), both readsteamdeck_hwmonfrom/sys/class/hwmon/hwmon3/name(or wherever that moves to on any kernel bootup). The fallback to hwmon5 is from SteamOS 3.4, so that would likely never work properly with SteamOS 3.5+. If PowerTools did fall back to hwmon5 for some reason, two notable things would occur:* except setting the battery charge mode
The consequence of 2 is more obvious unless you read the logs (so anyone except me). If PowerTools is not using the correct hwmon, then the persistent way of setting the charge limit would never be detected and so it would never be written to in the first place. That would nip this bug in the bud by preventing it from getting set to anything other than 100% or 0%.
PS I'm slightly disappointed that no one has brought up whatever tf I did here, which just seems silly. I found that while looking around for specific lines to explain things mentioned above but I'm still laughing at myself for it.
PPS I forgot to mention that based on some earlier discussion in this thread, the default value that is written to disable the custom charge limit is now
0instead of100.Thanks for the explanation! I'm not offended. I did suspect there was something missing from my understanding. I'm poking around in a system I don't know, that's on top of another system I don't know, in a language I barely know. Like you said, the max batter charge level was being set on my Deck.
It makes a lot more sense (seems more robust) that this works using the name attribute and not file path names. Thanks!
Any idea on when that solution will be released? I have a charge limit set at 80% and can't get back to 100. I don't know the architecture or the language well enough to confidently start poking around in the system, so I'm kinda depending on the actual good developers to release the patch for this...
Side Note - More testing is required but since engaging this feature my Deck has died twice while powered off. Not asleep, or in rest mode, or any of that. Actually off, but still discharging battery. Again, more testing is needed to see what the issue is, but figured I'd mention it at any rate.
Steam Deck LCD 512GB running stock with only EmuDeck and PowerTools installed.
I don't like to give ETAs. The next release is currently held up by my lack of time and motivation to tackle the last big change that I want to make for that version. Unfortunately it seems that y'all are stuck with me being the only developer on this project.