Bug 450551

Summary: Battery charge limit is not preserved after reboot on many laptops that support charge limits; need to write it on every boot
Product: [Plasma] Powerdevil Reporter: Matej Mrenica <matejm98mthw>
Component: generalAssignee: Fabian Arndt <fabian.arndt>
Status: ASSIGNED ---    
Severity: normal CC: agurenko, ahmedmaherbf, aisdavid9, alr888rav, andreas, camibohp, fabian.arndt, feus73, fljustsocial, gaunas, gestabr, ioo+kde, j.kde-bugs, kc-kde, kde, kde, konstantinlukashkin, lemmyg, lyrixcaz, m.kurz, manojkumarindia, marcan, masavini, matejm98mthw, me, natalie_clarius, nate, ngoquang2708, p.a.muroniyk, personal, peterthecoder, petteriusa, postix, shreyashr267+kde_bug, sinyagovsky, spamless.9v5xj, tani.giovonni, teohhanhui, th.buskens
Priority: HI    
Version: 5.27.4   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: attachment-24487-0.html

Description Matej Mrenica 2022-02-19 07:55:54 UTC
SUMMARY
ASUS laptop, battery charge limit can be set and battery stops charging when the limit is reached (or when battery is 1-2% under the limit).
The issue is that on every reboot the configured charge limit is reset to 100%. TLP also allows to configure a battery charge limit and this one is working as expected. (I am not running tlp at this moment, nor anything else that chages this setting) 

More info about setting battery charge limit on ASUS devices:  https://wiki.archlinux.org/title/Laptop/ASUS#Battery_charge_threshold

SOFTWARE/OS VERSIONS
KDE Frameworks Version: 5.91
Qt Version: 5.15.2
Comment 1 galder 2022-02-19 12:01:25 UTC
Hello,
Do you know if Plasma has specifics battery settings for this feature?
If not, I think we need set the ticket as feature request.

Regards
Comment 2 Matej Mrenica 2022-02-19 13:28:53 UTC
(In reply to galder from comment #1)
> Hello,
> Do you know if Plasma has specifics battery settings for this feature?
> If not, I think we need set the ticket as feature request.
> 
> Regards

I am not sure I understand your question, powerdevil has the ability to set battery charge limit. The issue I am reporting is that the value is not saved properly / is reset after reboot.
Comment 3 galder 2022-02-19 15:39:00 UTC
Thanks for your reply.
I'll try if  I can reproduce the issue.
regards
Comment 4 galder 2022-02-19 17:25:05 UTC
Sorry,
I can't find the charge limit option with my laptop.
Looping Nate as he was working in some  charge limit changes for 5.24

https://bugs.kde.org/show_bug.cgi?id=449997

Regards,
Galder
Comment 5 Nate Graham 2022-02-21 21:49:21 UTC
1. What kernel version are you using?
2. What is the output of `cat /sys/class/power_supply/BAT*/charge_control_end_threshold` right after you set the charge limit?
3. And what is the output of that command after you reboot?
Comment 6 Nate Graham 2022-02-21 21:50:22 UTC
Did you maybe follow the directions for https://www.linuxuprising.com/2021/02/how-to-limit-battery-charging-set.html in the past?

I suspect that something non-KDE is overriding the charge threshold setting on boot.
Comment 7 Kai Uwe Broulik 2022-02-21 21:54:21 UTC
There's no persistency in PowerDevil. I assumed that setting would be persistet by the device's SMC. I dd not want to bluntly write it on every boot in fear of wearing down some firmware flash storage or something.
Comment 8 Matej Mrenica 2022-02-23 18:42:38 UTC
(In reply to Nate Graham from comment #5)
> 1. What kernel version are you using?
5.16.10
> 2. What is the output of `cat
> /sys/class/power_supply/BAT*/charge_control_end_threshold` right after you
> set the charge limit?
It's the value I set, like 60.
> 3. And what is the output of that command after you reboot?
100

(In reply to Kai Uwe Broulik from comment #7)
> There's no persistency in PowerDevil. I assumed that setting would be
> persistet by the device's SMC. I dd not want to bluntly write it on every
> boot in fear of wearing down some firmware flash storage or something.
So, user has to reset the setting on every boot? Is that the intended behavior?
Comment 9 Nate Graham 2022-02-23 20:11:33 UTC
No, we're expecting the system to remember the charge threshold value once set.

So there are two possibilities here:
1. The device's SMC erases it. If this is what's happening, we will need to write it on every login if it's been changed.
2. Something else on your computer is resetting it.

It might be sane to write the value on login if it's gotten changed from what powerdevil set it to. That would cover case #1 without unduly wearing out the flash memory, since for most people it gets remembered and wouldn't need to be written again. For those whose settings get erased automatically, there's no alternative anyway.
Comment 10 Matej Mrenica 2022-02-23 20:23:49 UTC
(In reply to Nate Graham from comment #9)
> No, we're expecting the system to remember the charge threshold value once
> set.
> 
> So there are two possibilities here:
> 1. The device's SMC erases it. If this is what's happening, we will need to
> write it on every login if it's been changed.
> 2. Something else on your computer is resetting it.
> 
> It might be sane to write the value on login if it's gotten changed from
> what powerdevil set it to. That would cover case #1 without unduly wearing
> out the flash memory, since for most people it gets remembered and wouldn't
> need to be written again. For those whose settings get erased automatically,
> there's no alternative anyway.

From the Arch Wiki (https://wiki.archlinux.org/title/Laptop/ASUS#Battery_charge_threshold): 
...
By default this value is set to 100 and reset on every power cycle.
...

IIRC when I used TLP my battery charge limit was remembered after a reboot, so TLP has to re-set this value every time. And so does Windows.
Comment 11 Nate Graham 2022-02-28 21:50:55 UTC
Looks like it's the Kernel doing this, actually:

https://github.com/torvalds/linux/commit/7973353e92ee1e7ca3b2eb361a4b7cb66c92abee#diff-38095ba4871836b9eeaa6e1904739d398da72cda890e5ef932daec2995579db3R429-R434

That should probably be fixed. Matej, can you file a kernel bug report and put it in the URL field of this bug report? Thanks!
Comment 12 Matej Mrenica 2022-03-01 08:00:13 UTC
(In reply to Nate Graham from comment #11)
> Looks like it's the Kernel doing this, actually:
> 
> https://github.com/torvalds/linux/commit/
> 7973353e92ee1e7ca3b2eb361a4b7cb66c92abee#diff-
> 38095ba4871836b9eeaa6e1904739d398da72cda890e5ef932daec2995579db3R429-R434
> 
> That should probably be fixed. Matej, can you file a kernel bug report and
> put it in the URL field of this bug report? Thanks!

There's a message there saying one should use distro specific bug trackers for kernel bugs, do you think I should report this to Arch Linux bug tracker instead? https://bugzilla.kernel.org/
Comment 13 Nate Graham 2022-03-01 20:41:51 UTC
They say that to filter out bug reports by people using distros that heavily patch their kernels and curate their kernel module selection, because oftentimes those users are experiencing bugs that have already been fixed or that require a non-default kernel module.

Arch doesn't really do that though, and this issue is clearly right there in the kernel code (it's even commented), so I'd say it's fine to file a report on the kernel bug tracker itself.
Comment 14 Nate Graham 2022-04-12 20:57:06 UTC
*** Bug 452533 has been marked as a duplicate of this bug. ***
Comment 15 Nate Graham 2022-04-22 15:43:22 UTC
*** Bug 452839 has been marked as a duplicate of this bug. ***
Comment 16 Ahmed Maher 2022-05-22 13:36:51 UTC
Okay here is a temporary solution until they fix it in the next kernel.

1. Set your stop charging threshold in the KDE power settings.

2. sudo cp /sys/class/power_supply/BAT0/charge_control_end_threshold /home/$USER/.config/charge_control_end_threshold

3. sudo mkdir /etc/your; sudo vim /etc/your/script.sh

!/bin/bash

cp -f /home/$USER/.config/charge_control_end_threshold /sys/class/power_supply/BAT0/charge_control_end_threshold

4. sudo chmod 777 /etc/your/script.sh

5. sudo vim /lib/systemd/system/set-charging-end-threshold.service

[Unit] 

Description=My Shell Script

[Service]

ExecStart=/etc/your/script.sh

[Install] 

WantedBy=multi-user.target

6. sudo chmod 777 /lib/systemd/system/set-charging-end-threshold.service

7. sudo systemctl daemon-reload

8. sudo systemctl enable set-charging-end-threshold.service
Comment 17 Matej Mrenica 2022-05-22 13:38:46 UTC
There is also: https://wiki.archlinux.org/title/Laptop/ASUS#systemd_service
Comment 18 Ahmed Maher 2022-05-22 14:02:20 UTC
(In reply to Matej Mrenica from comment #17)
> There is also: https://wiki.archlinux.org/title/Laptop/ASUS#systemd_service

Oh, I didn't see that. Sorry
Comment 19 Matej Mrenica 2022-06-27 08:17:48 UTC
This issue reported to kernel bug tracker has just been closed as intended behavior (https://bugzilla.kernel.org/show_bug.cgi?id=215651#c2) meaning tools like Powerdevil are supposed to re-set this setting on every boot. So the issue should be fixed on this end then.
Comment 20 Nate Graham 2022-06-27 15:37:25 UTC
Darn. Ok, we'll write the value on every boot then.
Comment 21 Nate Graham 2022-06-27 15:38:01 UTC
*** Bug 455848 has been marked as a duplicate of this bug. ***
Comment 22 Nate Graham 2022-07-13 20:06:36 UTC
*** Bug 456537 has been marked as a duplicate of this bug. ***
Comment 23 Nate Graham 2022-08-05 17:34:31 UTC
*** Bug 457506 has been marked as a duplicate of this bug. ***
Comment 24 tani.giovonni 2022-11-02 14:15:02 UTC
I am also having this issue, is a fix incoming/in progress? I got a new (and expensive) laptop and I'm trying to make sure it's battery lasts but having to reset this value on each reboot is quite tedious. (I'm on the most recent version of KDE plasma on EndeavourOS if relevant)
Comment 25 Ansa 2022-11-04 14:02:44 UTC
This issue contains the word ASUS in its title, but I experience the same issue on a ThinkPad. I suppose it's still correct NOT to file a separate issue, right?
Comment 26 Nate Graham 2022-11-04 14:06:58 UTC
Yes, it's possible some ThinkPad hardware triggers the same Kernel condition. Once we write the value out on every boot, this will be fixed automatically for everyone.
Comment 27 tani.giovonni 2022-11-04 19:29:17 UTC
(In reply to Nate Graham from comment #26)
> Yes, it's possible some ThinkPad hardware triggers the same Kernel
> condition. Once we write the value out on every boot, this will be fixed
> automatically for everyone.
I might have just been super sleep deprived and am misremembering, but I thought I saw a reply to my original comment saying that a fix was already in the latest Kwin; I've since updated again (literally about 2 hrs ago on EndeavourOS) and rebooted and am still having the issue. Based on your phrasing here, it sounds like a fix has been created, and it's just not made it's way downstream to users yet, is that the case or am I totally misreading it? If so, is there an estimate for when it will start being deployed? I know there is no real way of KDE impacting when distros start putting the update in their repos so I don't expect any exact answers, but I'm just generally curious since it sounds like the issue has been more or less solved and it's just a matter of it being distributed.  
(again though, I'm not a developer so I could be totally misreading this, and the comment that I thought I remembered saying that the fix was already in kwin isn't there anymore so for all I know I might have just hallucinated it entirely, no misreading necessary.)
Comment 28 Nate Graham 2022-11-04 19:33:48 UTC
To my knowledge there is no released or proposed fix for this issue yet, sorry.
Comment 29 Peter 2022-11-04 21:51:03 UTC
Created attachment 153481 [details]
attachment-24487-0.html

I have found sort of a solution by using a program called tlp. There is a gui interface for it called tlpui. It fixes the problem, sort of, but it allows your battery to charge past where you set it when you boot/restart. Not quite perfect, but it's better than frying your battery.

Peter 

    On Friday, November 4, 2022 at 03:33:51 p.m. EDT, Nate Graham <bugzilla_noreply@kde.org> wrote:  
 
 https://bugs.kde.org/show_bug.cgi?id=450551

--- Comment #28 from Nate Graham <nate@kde.org> ---
To my knowledge there is no released or proposed fix for this issue yet, sorry.
Comment 30 Hector Martin 2022-12-25 16:15:07 UTC
FYI, this is the case on Apple laptops too. They actually don't support charge thresholds at all, just a charge behavior toggle (inhibit charge/not), and the OS is supposed to do the rest. We'll be emulating the thresholds in the kernel (for the convenience of userspace and because that means we can make them work in s2idle sleep). There is no flash memory to store any of these settings, so the OS has to re-set them on every boot.
Comment 31 Antonio 2023-01-18 04:57:36 UTC
Hi team,
I can confirm the issue on my Asus ExpertBook laptop. It happens every time after I shutdown the laptop. Btw just rebooting does not trigger this for me.
It is being happen since the first time I installed the system in Sept 2022.
Comment 32 Nate Graham 2023-01-23 21:56:15 UTC
*** Bug 464535 has been marked as a duplicate of this bug. ***
Comment 33 Faustino L. Padilla 2023-01-29 01:12:26 UTC
I can confirm this issue is happening with my ASUS DASH TUF F15 Laptop as well. I charged my battery to 100% a couple of times because of this issue 😖
Comment 34 shreyashr267+kde_bug 2023-04-26 17:29:51 UTC
Is there any update when this issue is going to be resolved. I m facing the same issue on my ASUS Vivobook 15
Comment 35 Kevin Chadwick 2023-05-03 12:30:02 UTC
One thing to consider is that this should probably be done as early as possible. A sysctl would be ideal but perhaps no longer the Linux way. Otherwise the battery will charge above the setting a percent or two especially if rebooting often. In general, it might actually help the battery with a short charge on boot, so not a big deal, but also not ideal. Also, I had to create a separate systemd unit file for it to be re-applied on suspend.target.
Comment 36 bornfree 2023-07-29 13:29:42 UTC
I have the same problem.
Asus Zenbook S 13 UX5304VA-NQ083
KDE: 5.27.5
Frameworks KDE: 5.103.0
Qt: 5.15.8
Debian 12. Kernel: 6.1.0-10-amd64
Comment 37 ioo+kde 2023-09-19 01:57:59 UTC
The bug with an LG Gram, after I reboot the value gets set back to 100. I have tried various kernels.

I also tried the temporary solution described in this thread but this does not work: cp: error writing '/sys/class/power_supply/CMB0/charge_control_end_threshold': Invalid argument.

How does the KDE Neon GUI write to this file? I can set the value with the GUI and it does update the file so its possible but nothing I can find will allow me to set the value. I always get an 'Invalid argument' error.
Comment 38 Michael 2023-09-20 02:59:26 UTC
> How does the KDE Neon GUI write to this file? I can set the value with the
> GUI and it does update the file so its possible but nothing I can find will
> allow me to set the value. I always get an 'Invalid argument' error.

I am running KDE neon User Edition and what worked for me was linked to by comment #17
https://bugs.kde.org/show_bug.cgi?id=450551#c17
Comment 39 ioo+kde 2023-09-20 19:56:54 UTC
So #17 is a systemd service that run this command:
echo 75 > /sys/class/power_supply/CMB0/charge_control_end_threshold

but when I run it as root I get:
bash: echo: write error: Invalid argument

so it doesn't seem to be writable for me, somehow KDE knows how to write to it because I can set it in the GUI but after a reboot its back to 100%. I would like to know how KDE writes to this special file.
Comment 40 Michael 2023-09-21 01:28:19 UTC
(In reply to ioo+kde from comment #39)
> So #17 is a systemd service that run this command:
> echo 75 > /sys/class/power_supply/CMB0/charge_control_end_threshold
> 
> but when I run it as root I get:
> bash: echo: write error: Invalid argument

First do this: 

ls -la /sys/class/power_supply/

... and you'll see something differing from CMB0. In my case, I see ACAD and BAT1. I substitute BAT1 for CMB0 in your case.
Comment 41 Fabian Arndt 2023-11-01 22:53:22 UTC
There is some progress: https://invent.kde.org/plasma/powerdevil/-/merge_requests/253
Please note that this is only a draft and there are still some points open for discussion.
Comment 42 Fabian Arndt 2023-11-09 14:51:56 UTC
*** Bug 451454 has been marked as a duplicate of this bug. ***
Comment 43 Natalie Clarius 2023-11-14 06:39:39 UTC
*** Bug 476976 has been marked as a duplicate of this bug. ***
Comment 44 Natalie Clarius 2023-12-04 23:23:10 UTC
*** Bug 477858 has been marked as a duplicate of this bug. ***
Comment 45 Bug Janitor Service 2023-12-13 07:46:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/290
Comment 46 Jakob Petsovits 2024-04-06 02:36:14 UTC
*** Bug 485020 has been marked as a duplicate of this bug. ***