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
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
(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.
Thanks for your reply. I'll try if I can reproduce the issue. regards
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
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?
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.
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.
(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?
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.
(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.
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!
(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/
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.
*** Bug 452533 has been marked as a duplicate of this bug. ***
*** Bug 452839 has been marked as a duplicate of this bug. ***
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
There is also: https://wiki.archlinux.org/title/Laptop/ASUS#systemd_service
(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
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.
Darn. Ok, we'll write the value on every boot then.
*** Bug 455848 has been marked as a duplicate of this bug. ***
*** Bug 456537 has been marked as a duplicate of this bug. ***
*** Bug 457506 has been marked as a duplicate of this bug. ***
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)
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?
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.
(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.)
To my knowledge there is no released or proposed fix for this issue yet, sorry.
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.
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.
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.
*** Bug 464535 has been marked as a duplicate of this bug. ***
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 😖
Is there any update when this issue is going to be resolved. I m facing the same issue on my ASUS Vivobook 15
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.
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
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.
> 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
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.
(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.
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.
*** Bug 451454 has been marked as a duplicate of this bug. ***
*** Bug 476976 has been marked as a duplicate of this bug. ***
*** Bug 477858 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/290
*** Bug 485020 has been marked as a duplicate of this bug. ***
Facing the same. Here's a link to the ongoing discussion in the powerdevil repo : https://invent.kde.org/plasma/powerdevil/-/issues/36
Have the same problem on huawei laptop, the only difference it resets to 50% on every reboot.