System Settings -> Advanced Power Settings - Charge Limit is not persisting after machine is shut down

My laptop sits on a desk 80% of the time, so fully charging the battery is a Bad Idea TM. I can set the charge limit to 90%, which works, but when I shut the machine down at the end of my work day the setting seems to get lost: when I start it up the next day the Charge Limit is back to 100%.

It’s a clean Manjaro install from a week ago, with ‘pamac update -a’ having been run today.

Any suggestions of what I can investigate to solve this?

  Host: N/A Kernel: 5.18.10-1-MANJARO arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.24.6 Distro: Manjaro Linux
  Type: Laptop System: ASUSTeK product: ROG Strix G513QY_G513QY v: 1.0
    serial: <superuser required>
  Mobo: ASUSTeK model: G513QY v: 1.0 serial: <superuser required>
    UEFI: American Megatrends LLC. v: G513QY.318 date: 03/29/2022
  ID-1: BAT0 charge: 90.5 Wh (99.0%) condition: 91.4/90.0 Wh (101.5%)
  Info: 8-core AMD Ryzen 9 5900HX with Radeon Graphics [MT MCP] speed (MHz):
    avg: 1251 min/max: 1200/4889
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M]
    driver: amdgpu v: kernel
  Device-2: AMD Cezanne driver: amdgpu v: kernel
  Display: x11 server: X.Org v: 21.1.3 with: Xwayland v: 22.1.2 driver: X:
    loaded: amdgpu unloaded: modesetting,radeon gpu: amdgpu
    resolution: 1920x1080~300Hz
  OpenGL: renderer: AMD RENOIR (LLVM 14.0.6 DRM 3.46 5.18.10-1-MANJARO)
    v: 4.6 Mesa 22.1.3
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
  Device-2: MEDIATEK MT7921 802.11ax PCI Express Wireless Network Adapter
    driver: mt7921e
  Local Storage: total: 476.94 GiB used: 114.31 GiB (24.0%)
  Processes: 365 Uptime: 43m Memory: 15.04 GiB used: 2.79 GiB (18.5%)
  Shell: Zsh inxi: 3.3.19

I am using Manjaro KDE and face the same issue every time after shutdown. using a system service route to set the charging limit.

Check your Settings > Desktop Session and best is to enable Start with an empty session

No, it’s set to “Restore manually saved session” which is the default as far as I can tell.

Hang on, are you saying I should change from the default to “Start with an empty session”?

I am not sure what you mean.

Are you saying there is a config file I can edit? Run a script on boot?

But what’s the point of implementing a GUI that doesn’t work? What if this is meant to work and it’s not because of a bug? Shouldn’t I report it somewhere so it gets fixed?

I’m saying to switch to Start with an empty session and make sure the Power Settings are surviving reboot, and then switch back to whatever you prefer: Restore manually saved session or the other one.

Unless you expect perfection, but a saved session to work after reboot, has to be a session that is clean, because you might still boot into the session prior of making the changes in Power Settings …

I followed @bogdancovaciu 's instructions and the settings still weren’t retained.

Please note who I was replying to. When I asked “But what’s the point of implementing a GUI that doesn’t work?” it was in response to @ajaychat3 's post, who said: “I am using Manjaro KDE and face the same issue every time after shutdown. using a system service route to set the charging limit.”

So, what do I do next? The setting isn’t getting retained. What can I do to investigate this? Should I report it somewhere? Where do I report an issue like this? Is this a problem with the KDE settings interface and should I report it to KDE? Is there a way for me to confirm it’s a problem with the KDE settings and not a problem with the Manjaro specific implementation of those settings? I have looked on other laptops I have access to that run Manjaro and they don’t even have the option to set a charge limit, so I haven’t been able to compare between machines. From what @ajaychat3 said it seems pretty clear that the GUI setting isn’t getting retained in his case, either.

Is there a workaround while I wait for this to get fixed upstream? @ajaychat3 seemed to indicate that it can be fixed by editing some settings file somewhere directly, but didn’t say what specific setting in what file.

Then we can move on to the next stage of the investigation.

We didn’t concluded yet if is a local issue for you and @ajaychat3 - and while there are multiple ways around this, the classic approach might be better.
Are the files ~/.config/powerdevilrc and ~/.config/powermanagementprofilesrc writable on your user, do your user owns those files?

@outsidefactor . Here is what I have done. I have a Asus laptop and the approach which I have adopted is given below. Hope it helps you as well.

  1. Create a service file named battery_charge_threshold.service like this.
Description=Set the battery charge threshold

ExecStart=/bin/bash -c 'echo 80 > /sys/class/power_supply/BAT0/charge_control_end_threshold'

  1. Move the file to this location /etc/systemd/system
  2. Run the following commands.
sudo chmod 644 /etc/systemd/system/battery-charge-threshold.service
sudo systemctl daemon-reload
sudo systemctl enable battery-charge-threshold.service

After doing this, charge threshold of 80% (as per service file) will persist between reboots. It will also stop charging the battery if the current level is above 80%. Hope this helps. I have been using it for almost 1.5 years without any issue.

1 Like

The ~/.config folder is owned by my user and I have read and write to the directory. The file “powerdevilrc” doesn’t exist. “powermanagementprofilesrc” exists, and I have both read and write permissions. I checked, and powerdevil is installed.

These settings seem to be tied to a specific user and (in my limited understanding) only get loaded on user login, but surely “Charge Limit” is a system wide setting? For example, let’s say I have been on site, return to my office and dump my laptop on my desk to charge but I don’t log in, wouldn’t I still want to limit he charge to 90%, even without a user being logged on?

Thankyou for posting your workaround!

I will hold off putting it into action for a bit so I can continue to work with @bogdancovaciu on getting the GUI working, but thanks for letting me know your (quite elegant, if I may say) fix.

Apparently there is a bug report on this, but seems to be specific to some laptop models, and in the case of the OP of that issue report, it happens after booting to Windows …

The proposal is to go here Laptop/ASUS - ArchWiki and since your laptop is an ASUS, for sure will help.
More or less goes the same route as @ajaychat3 proposed, plus gives also a fix to persist from hibernate.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.