[RESPONDED] Battery charge control thresholds in sysfs

Currently we have an option to set the battery charge limit in BIOS. However, that setting is not propagated to the kernel and thus is not visible to the userspace.

For example my KDE battery applet still shows the battery as charging even when upper limit is reached. Also, it incorrectly calculates the battery wear.

I suppose this happens because kernel does not provide the information in sysfs:

+++ Battery Status: BAT1
/sys/class/power_supply/BAT1/manufacturer                   = NVT
/sys/class/power_supply/BAT1/model_name                     = Framewo
/sys/class/power_supply/BAT1/cycle_count                    =    126
/sys/class/power_supply/BAT1/charge_full_design             =   3572 [mAh]
/sys/class/power_supply/BAT1/charge_full                    =   3208 [mAh]
/sys/class/power_supply/BAT1/charge_now                     =   2304 [mAh]
/sys/class/power_supply/BAT1/current_now                    =    346 [mA]
/sys/class/power_supply/BAT1/status                         = Discharging

/sys/class/power_supply/BAT1/charge_control_start_threshold = (not available) 
/sys/class/power_supply/BAT1/charge_control_end_threshold   = (not available) 

Charge                                                      =   71.8 [%]
Capacity                                                    =   89.8 [%]

Note the missing thresholds and charge limit (90%) mistakenly treated as actual capacity.

Any ideas on what needs to be done to support that in the kernel? My understanding is thath it could be supported, since overall battery info is detected and is more or less accurate.

3 Likes

charge_now?/ charge_full* 100 = 71.8%

charge_full_design/charge_full *100 = 89.7%

Question:: charge_full_design = 3572 [mAh] as design is 5500 [mAh]

Different units. Design voltage is 15.4V, so
3572 mAh * 15.4V = 55.0 Wh (which is the design capacity of the battery)

1 Like

Yes :blush: that should have been 5500mWh

So, exposing the charge threshold in sysfs is something I’m working on. The limit is mediated by the EC, and exposing it in sysfs requires the installation of a battery “extension” (it’s a kernel interface that allows one driver to add sysfs entries to an ACPI battery node owned by another driver.)

I’m planning on seeking upstream approval for this patch soon. For now, though, some teasers:

(rigel) ~ % ls /sys/class/power_supply/BAT1 
alarm           charge_full_design  device        power          subsystem   voltage_min_design
capacity        charge_now          hwmon2        present        technology  voltage_now
capacity_level  current_now         manufacturer  serial_number  type
charge_full     cycle_count         model_name    status         uevent

(rigel) ~ % sudo modprobe framework_acpi

(rigel) ~ % sudo dmesg | tail -n 1
[159509.633091] ACPI: battery: new extension: Framework Laptop Battery Extension

(rigel) ~ % ls /sys/class/power_supply/BAT1/charge_control_end_threshold 
/sys/class/power_supply/BAT1/charge_control_end_threshold

(rigel) ~ % cat /sys/class/power_supply/BAT1/charge_control_end_threshold
100

(rigel) ~ % echo 80 | sudo tee /sys/class/power_supply/BAT1/charge_control_end_threshold
80

18 Likes

Does charge_full/charge_full_design represent true battery wear? I’ve been using an 11th-gen laptop for 5 months and have battery charge capped at 80%. 10% wear seems too high.

[fw ~]$ cd /sys/class/power_supply/BAT1
[fw BAT1]$ cat charge_full charge_full_design charge_now
3215000
3572000
2592000

Also cycle_count reports zero. But I guess that’s because I haven’t been using any battery manager so the kernel doesn’t know.

Hi @DHowett.

Have you got any further with your efforts to expose the battery charge limit setting to OS control?

3 Likes

Been wondering about it as well. My old-ish huawei laptop exposed those entries just fine, but the AMD framework does not - a pity. I actually used to change those depending on my use case, rebooting to BIOS is rather inconvenient, not to mention only the max charge can be changed.

You can change these with the ectool from userspace from memory (which requires david’s currently out of tree patch to support the amdfw)

Thanks for the heads up, but that’s still a workaround for me. I do use the console, but I’d like to make use of Plasma’s powerdevil / activity profiles, which means GUI. Sadly, that only works if charge_control_start_threshold and charge_control_end_threshold are exposed…

1 Like

Hello @Loell_Framework , any chance that this feature request can be taken into consideration by the DEV team?
I have the same request and several other forum users as well. Only problem is that these requests are a bit scattered around in the forum.

Given its open nature, I would totally expect FW to expose this bit via sysfs eventually.

As another user mentioned, keeping a value of 80% is great for extending battery lifespan, but being able to ramp up to 100% before a long flight/trip would be a great usability improvement, without the need to fiddle with the BIOS.

@DHowett tagging you as you kindly started working on this as well :slight_smile:

Thanks!

EDIT: other thread here

2 Likes

If you’re willing to run some rando’s third-party kernel module, you can test it out!

It also exposes things like fan speed and keyboard backlight to userland via sysfs.

3 Likes

Dhowett’s solution or bios is where were at for now.

Thanks for the link

From the README however my understanding is that I’d need to compile my own kernel, not just the module, is that still the case?

I’m not familiar with that process at all, and of course when compared to compiling just a module, I think that it would be a different league of DIY :sweat_smile:

Hence my interest for this being upstreamed eventually. Are your upstream efforts still ongoing, and if so, is there an issue/URL I can monitor for progress?

Thanks a lot :slight_smile:

3 Likes

Thank you for this!

I’ve just built and installed the module on my 12th Gen running Fedora 39 without any problems. It was as simple as:

$ git clone https://github.com/DHowett/framework-laptop-kmod.git
$ cd framework-laptop-kmod/
$ make
$ sudo make modules_install
$ sudo modprobe framework_laptop
$ cat /sys/class/power_supply/BAT1/charge_control_end_threshold
80
# echo 100 > /sys/class/power_supply/BAT1/charge_control_end_threshold 
# cat /sys/class/power_supply/BAT1/charge_control_end_threshold 
100

After this, I could see it start charging up past 80%.

1 Like