New way of handling charge handling on the deck

[JDGBOLT]

Within the deck firmware, there actually is a method of turning on/off the charging of the battery that isn't just doing the current limiting or anything, but actually control it manually like how the deck currently discharges to 90% if it's plugged in for a while. Within the jupiter-hw-support package there is actually a file /usr/share/jupiter_controller_fw_updater/RA_bootloader_updater/linux_host_tools/BatCtrl that is able to control the charging circuitry. There are other functions like controlling the charging led, changing fan speeds, enabling shipping mode, controlling power to the board, and many others. But the one that is interesting in this case is BatCtrl ChargeMode [0/1/2].

0 allows you to force discharge the battery, where the deck will run on the battery even while plugged into a power source, 1 is idle the battery charging circuit where it will keep the battery at that particular value, and 2 which is the normal charging behavior. Looking at an strace of what it's doing it's sending text directly to /dev/port, and I think it's talking directly to the low level controller that exists on the deck so it's not just something that's exposed within sysfs. Could potentially sniff what it's doing exactly and have power tools send that string to /dev/port, or more likely to be without issues is just running the batctrl binary directly.

Only issue is that it's executable by default within steamos 3.4, but not in 3.3. The commit that changed that is what initially brought my attention to it's presence in the first place, and found it kind of interesting. With that it should be possible to setup making the deck only charge to a certain amount when plugged in for a long period of time in order to increase battery health. I think power tools already did add that functionality, so hopefully wouldn't be a huge reengineering to change over to this method, though as I said, by default will only work on 3.4, as 3.3 the binary isn't executable. Just thought I would bring it to your attention.

[NGnius]

Wow, what would I do without you! I'm going to have to take a look at BatCtrl and how it works, so I'm not sure if this will make it into the next update or the one after. I'm sort of hoping I can just reverse engineer it and the firmware API isn't subject to change, but that's more work than directly calling the executable. The goal is stability, but I've got no idea which option will be better for that -- time will tell, I guess.

A question for you, if you know: does this work when the Steam Deck is asleep and/or powered off? Since it's firmware, it has a good chance of that but I'm unable to test right now.

[NGnius]

This will be in v1.1