Laptop battery charge threshold

[WatchMkr]

In System76 open firmware we are enabling a battery threshold features that we want to expose through the Power panel in GNOME Settings. Setting battery charge thresholds other than the defaults extends battery life.

There are two parts to the feature:

1. Setting the maximum battery charge level (charge only up to 70% of the battery capacity)
2. Setting the battery level at which charging will start (when plugged in, don't start charging the battery until it has reached 80%)

For the first, it might be a slider with specific points:
0% ------------------------------------------------------------------ 70% ----- 80% ----- 90% ----- 100%

For the second, a similar slider. but with more points.
0% ----------------------------------------- 50% ----- 60% ----- 70% ----- 80% ----- 90% ----- 99%

A customer might set a maximum charge-level of 70% but a don't-charge-until level of 80% which would result in the battery charging at 69%. To avoid this being confusing, we should probably reduce the don't-charge-until percentage to match the highest charge-level. If they raise the charge-level, the don't-charge-until level wouldn't increase automatically with it. This needs UX consideration to determine if the interaction between these two settings in this way will be confusing

[ids1024]

Since charging thresholds are implemented using a standard sysfs interface, supported on some other hardware, we can potentially send a patch for this upstream. I've opened an upstream issue about this: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1135

As noted in the links there, support for this has been requested before in Gnome, and KDE recently added such a feature.

[ids1024]

I kind of like the way Asus supports this: https://www.asus.com/us/support/FAQ/1032726/#3

They offer 3 modes:

A. Full Capacity Mode(Yellow color): Battery is charged to its full capacity for longer use on battery power.

B. Balanced Mode(Blue color): Stops charging when power is above 80% and resumes charging when power is below 78%. This mode is recommended when using the Notebook on battery power during meetings or conferences.

C. Maximum Lifespan Mode(Green color): Stops charging when power is above 60% and resumes charging when power is below 58%. This mode is recommended when the Notebook is always powered by AC adapter.

Logically, this might fit nicely in the power menu, but I guess that's already getting cluttered (maybe a somewhat different design could improve that?)

Offering two sliders is definitely more flexible, but it is likely non-obvious what settings make sense. I would be inclined to support a few sensible options like the Asus ones, and then a "custom" mode allowing arbitrary thresholds.

Fully custom configuration here is likely not something upstream would be interested in.

[ids1024]

After working on some refactoring of the cluttered battery code in Gnome Control Center, I have some insight on how it works.

It normally displays the battery like this:

But there actually can be multiple batteries (internal laptop batteries, or a UPS), which would look something like this (faking it, since I don't have such hardware):

The first row is the overall charge combining batteries, and the other two rows are different batteries (or the same one in the modified code I'm testing with).

So for a robust solution that works all all hardware, in theory there may be multiple batteries with thresholds that can be modified separately. This would also be cleaner to implement, since thresholds are inherently associated with a battery device in sysfs. (Though if a computer had multiple batteries, it would be odd to have independent thresholds...).

Given the space required, I guess we would probably want a pop-up dialog or an expander to be able to hide any additional battery settings.

If we want to get this upstream, I suppose we'll need to see what the Gnome design team thinks.

[WatchMkr]

The Asus approach is pretty good. I like that they're simply choosing the charge-start point at 2% below the max setting. Adopting that will reduce us to one slider.

Having considered this a bit more, different laptop models have different size batteries and draw which leads to different choices about what the top charge level should be. For the Lemur, 50% goes a long way and might be plenty. Whereas the Oryx would be 80% or higher for the same mobile-use.

One max-charge slider with more point is a better solution.

0% ----------------------------------------- 50% ----- 60% ----- 70% ----- 80% ----- 90% ----- 100%

Tesla's UI includes hints to help users select an appropriate charge level. For us, those might be - 50-60% Max Lifespan | 70-80% Balanced | 90-100% Full Capacity. (Not completely pleased with those descriptions but I haven't come up with anything better.)

The GNOME design team has a new design for the power panel. @maria-komarova is going to work on incorporating this feature into the new designs and perhaps we can take on both adding this feature and the new design.

[ids1024]

It looks like Lenovo recommends somewhat different settings, but in similar categories to the Asus ones.

"Optimizing for runtime (hours)"

• 96%-100%

"Optimizing for lifespan (years)"

• 40%-50% when the battery is rarely used
• 85%-90% when the battery is frequently

So in addition to differences in the exact numbers, Lenovo's recommended thresholds have 5% and 10% ranges, rather than just 2%. And even when charging to 100%, is uses a 96% bottom threshold.

[ids1024]

And then there's the modes Huawei offers:

Family Mode: Suitable for when your computer is being charged continuously. In this mode, charging starts when the battery level drops below 40% and stops when it reaches 70%.

Office Mode: Suitable for when the power adapter could be unplugged at any time. In this mode, charging starts when the battery drops below 70% and will stop when it reaches 90%.

Travel Mode: Suitable for when a power adapter is frequently unavailable for lengthy period of time. In this mode, charging starts when the battery drops below 95% and stops when it is 100% charged.

Seems like a pretty dubious naming convention, but we again see three modes with similar purposes, at slightly different numbers.

[ids1024]

Based on some discussion with upstream, it seems unlikely this will be accepted in Gnome currently, so we can probably work on implementing this specifically for Pop!_OS on System76 hardware, and look at potentially expanding this and upstreaming later.

Anyway:

• What UI do we want? Are we still intending to use one or two sliders, or do we want to offer three profiles, which seems to be typical with other manufacturers?
  • Offering 3 profiles like this seems to make the feature fairly usable and approachable. It's simple to choose sensible values, and the interface also explains why one would choose one option over another.
• Do we expect this to be configurable by any user without entering an administrator password? I guess that's how other things like graphics switching currently works, though it seems atypical (if not too destructive) for system-wide firmware configuration.

I believe releasing this feature would also be dependent on the EC firmware persisting thresholds across resets which it currently doesn't. And of course releasing firmware updates with this.

[maria-komarova]

I agree, we can work on implementing this specifically for Pop!_OS starting with System76 hardware.
Here is the UI for that:

• single battery case
  
  

• multiple batteries
  
  

I am not sure what the charge start-point should be 2%, 5% or 10%. Maybe this is a case where we start with 2% and then try to find out what users think.

It seems to me that this should require an administrator password for a non-administrator users. Is there something in the Settings that currently requires administrator password? I thought I saw something similar for languages or input sources but maybe that's not so.

[ids1024]

I'm not sure we can get quite that style with GtkScale. It does support adding marks at certain values with text, but it doesn't look quite the same. And strangely I can't seem to center the text of the labels (It seems pango markup doesn't have an attribute for alignment...).

I don't see a way to add bracketing of ranges like that.

(Of course we can do basically anything with custom rendering, but that rapidly becomes more complicated).

Instead, I was thinking we might want to provide a dropdown with the options "max lifespan", "balanced", "full capacity", and "custom (if those are the names we're using).

For the first three options, it can have a label below the dropdown showing what the currently selected mode does, and why one would use it. When custom is selected, it would allow the user to set arbitrary values for each threshold, perhaps with two GtkSpinButtons.

[maria-komarova]

Would it be possible for us to use percentages instead of words on the GtkScale and then add brackets with text using something else?
The slider should show percentages first anyway.

[ids1024]

The scale could be labelled with the percentages easily enough. I suppose brackets could be added by adding a GtkDrawingArea below the GtkScale and rendering them with cairo. It may be awkward to get everything to reliably line up how it should.

Another option that comes to mind is a GtkListBox, which could give several options as well as "custom". A somewhat crude proof of concept:

[maria-komarova]

Each "mode" includes a range inside it where a user can select the value. For example, Max Lifespan has a range of 50-60% and the idea was to enable a user to select any percentage within this range. The mockup treats modes more as recommendations and the information to consider while giving a user the ability to choose within those modes.

One thing we thought to limit is setting the value to below 50%. But I am not sure how possible it would be to do with GtkScale. Basically to not let the slider be moved below 50%.

[ids1024]

Discussion with upstream seems to favor profiles, ideally vendor-provided, and probably no ability to set arbitrary thresholds in the UI. Though we can do something different.

I like the way the profiles are shown in the Asus UI, since it provides a reasonably good summary of why one would use each of the three modes. Based on what Asus (as well as Huawei and Lenovo) recommends, "max lifespan" is optimized for uses where someone largely uses AC power, "balanced" is for typical laptop use (assuming it's not critical to get the highest capacity possible), and full capacity just disables thresholds.

I don't know if the current mockup makes it as clear what values to set and why.

[maria-komarova]

I am not entirely sure as to what solution offers more value to the user.

• One option is to have a slider with the guidance/suggestions on the side and freedom to choose between 50% and 60% for the Maximum lifespan, for example.
• Another option is to offer predefined profiles and potentially offer a way for to customize thresholds through the command line.

1. The only way I see right now to make the UI with the scale/slider clearer would involve more drawing. Or we can use a vector graphic but I don't know how many issues there will be with keeping things aligned the right way. Here is an example of the UI:
   

2. Second option seems to be more in line with the direction where the upstream discussion is going. But we would need to have the actual percentages defined. I have inserted the numbers based on the previous discussion into the mockup. But I might not be the best qualified person to determine them. Dialog mockups for that version are below. It would get somewhat complicated with more than one battery but it can be a scrollable dialog, although this is not ideal.
   The mockups for the addition of the threshold to the power panel are the same as in the post above.
   
   

[ids1024]

I have this partly working, using the DBus API in pop-os/system76-power#197. Selecting a different option pops up an authentication dialog:

[ids1024]

This is functional, looking like the previous screenshots, plus this inline in the panel:

There some things to sort out before this can be released.

Supposing we are happy with providing set profiles, and switching with a UI like this:

• Confirm the names, descriptions, and thresholds values we want to use for each profile
• Merge feat: Add dbus API and CLI for battery charge thresholds system76-power#197, which the changes here depend on
• Update EC firmware to persist thresholds (Charging thresholds don't persist through an EC reset system76/ec#128)
• Release updated firmware with the feature
• Release modified version of Gnome Control Center
• Document in https://github.com/system76/docs

[WatchMkr]

Proceed with this design and the following copy and thresholds. @ids1024 @maria-komarova

---

Increase the lifespan of your battery by setting a maximum charge value below 100%.

Full Charge (100%)
Battery is charged to its full capacity for the longest possible use on battery power. Charging resumes when the battery falls below 96% charge.

Balanced (90%)
Use this threshold when you unplug frequently but don't need the full battery capacity. Charging stops when the battery reaches 90% capacity and resumes when the battery falls below 85%.

Maximum Lifespan (60%)
Use this threshold if you rarely use the system on battery for extended periods. Charging stops when the battery reaches 60% capacity and resumes when the battery falls below 50%.

[humanplayer2]

I hope this comment is not out of place, but as a Pop!_OS user, I really hope this will become available for hardware supporting charging thresholds in general.

Due to this, I believe my ThinkPad supports charging thresholds, and it would be divine if Pop! offered the functionality build-in.

[ivanakcheurov]

I would like to share a terminal solution for Asus laptops until the feature is released.
Google leads here. Pages like this usually have workarounds people can use today.

Setting ASUS battery thresholds in Terminal

Explanation
Video

In a nutshell

Check if your system has the file with the threshold.
You might need to replace BAT0 with BAT1 or another digit.

cat /sys/class/power_supply/BAT0/charge_control_end_threshold
# outputs the maximum percentage to which the battery should be charged:
100

Change the threshold (effective until next reboot):

echo 60 | sudo tee /sys/class/power_supply/BAT0/charge_control_end_threshold 

Apply the change permanently (gets effective after reboot):

cat <<EOF >> /etc/crontab
#
# Battery Charge Threshold by OS Busters
# https://www.osbusters.net/2021/01/enable-asus-battery-health-charging-in-linux-os.html

@reboot root echo 60 > /sys/class/power_supply/BAT0/charge_control_end_threshold

# END Battery Charge Threshold by OS Busters
EOF