While using Qubes, I’ve observed that the battery constantly goes from 95% to 100% and discharges in this range. Is there a way to disable the charge once it gets to a certain percentage and only pull from AC power?
Could be hardware dependent. There are some laptop models that don’t work at all if you take the battery out.
I did try disconnecting the battery. It reset all the clocks… which in turn meant I needed to reset the Librem Key as well. I thought the clocks would run on some CR2032
battery is being controlled by EC
and there was somewhere information how to set charge thresholds. like:
allow battery discharge to 40% then load it to 80% …
it’s matter of setting correct EC profile.
here you have inf0o how to control battery:
Controlling the Battery
In our last blog post we also talked about the battery charge controller and that we can set some threshold from user space. Here you go:
If the battery percentage falls below the start threshold and then a new charge is started, charging will stop when the battery reaches the end threshold percentage. On my Librem 14 I currently use a script and set this to:
#set default battery thresholds
echo 40 > /sys/class/power_supply/BAT0/charge_control_start_threshold
echo 95 > /sys/class/power_supply/BAT0/charge_control_end_threshold
The system fans can not be controlled from user space yet, right now, but they can at least be monitored a bit:
We will work further on it.
The ACPI driver is on its way into PureOS as a DKMS package and we will do our best to get this into upstream Linux kernel so the DKMS will not be necessary mid-term.
I have combed through /sys/class/power_supply myself and under Qubes (at least on my device) these do not appear. I have already wiped the default installation of PureOS on my drive so I can’t verify if those exist or not. The problem is less about determining when the battery starts charging but the behavior that the battery is being used while being plugged into the wall.
And it appears that we have no way to update the EC firmware in any way yet so a fix is probably for the future
I’ve been monitoring /sys/class/power_supply/BAT0/current_now and mysteriously after a couple reboots and updates it appears to be stable at 0 and my battery is constant at 96%.
This leads me to the conjecture that the charger cannot provide enough wattage to the computer if under significant load and therefore needs to pull current from the battery as well.
In the above post Nicole talks about limiting the CPU wattage by using
echo 15000000 > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw
echo 20000000 > /sys/devices/virtual/powercap/intel-rapl/intel-rapl:0/constraint_1_power_limit_uw
But powercap does not show up under virtual so I haven’t been able to try that solution.
Edit: Executing “find /sys/ | grep constraint” also returns no results.
they all require the librem-ec DKMS driver, as described in that blog post
So I guess there isn’t much I can do
the default battery charge threshold to start charging is 90%, so the only way I can see what you are describing happening is if it’s below 90%, starts charging, then stops at 100% and discharges until it’s back below 90% again. Is that what you’re seeing?
My L14 did not charge at all with preinstalled PureOS. After installing librem-ec-acpi-dkms it still was not charging because /sys/class/power_supply/BAT0/charge_control_start_threshold was 0 by default. After changing it to 75 it started to charge.
that means your L14 shipped with EC firmware that has a bug in the charge thresholds setting, we have an update EC firmware (just no mechanism to apply it yet), but setting via the DKMS driver achieves the same result
The behavior is as follows.
At rest/low load, the battery level stays constant and I do not observe “discharge -> charge -> discharge -> charge” behavior. Under load (eg. during initial setup/updates) the battery begins discharging and then begins charging again.
Due to the intermittent loads this gives the laptop enough time to recover and recharge the battery back to 100% and hence we observe this cycle.
This leads me to believe the charger is unable to provide enough power to the L14 and thus needs to pull extra current from the battery under load. As such my issue is less about setting charging thresholds but rather what I observe to be an inadequate charger (power wise).
there’s no way the L14 should be pulling more than 65W - the CPU turbo max is 20W, and even counting the rest of the system (display, etc) and fully populated USB ports, should still be well under 65W.
Will see if I can reproduce here compiling / forcing a heavy load
Thanks! The only reason why I say this is because when the battery reports “fully charged” and I’m just idling/browsing the web…
that makes sense, since the current supplied by the battery (assuming that’s the discharge current) would be zero since on AC power
Yes, but during heavy loads and ramping up it is not 0 sooooooooooooooooooooooooooooooooooooooooooooooooo its discharging even though plugged in.
then that’s something I need to investigate
Thanks! Just as a point of reference, I’ve reinstalled Qubes maybe 2-3 times on the L14 now and every time during the initial update/after you first login this behavior is most prevalent (eg. sudo qubes-dom0-updaste, upgrading fedora-32 to fedora-33 templatevm, or just normal updates).
I’m also seeing odd battery behavior while running Qubes. Even with the charger plugged in, the battery level does not increase despite xfce4-power-manager stating that the battery is charging.
Yesterday I had the laptop on, the battery level was at 74%, and with the charger plugged in for hours it remained at 74%. I turned the laptop off and kept the charger plugged in for over 8 hours overnight. When I turned the laptop back on this morning, the battery level is still reading at 74%. I unplugged the charger for a while and now the battery is at 65%, and plugging the charger back in is keeping the battery at 65% but it is not increasing.
@wanderingshort if your device won’t charge with a PureOS (10) live USB booted, then contact support about an EC firmware update to address the issue