• NetBSD

  • Setting battery charge limit

nia you can't control battery charging from userspace. it's the responsibility of the firmware to do the reasonable thing

That's exactly what I would've said, before I looked onto that TLP thing mentioned above.

It does look to me now, that some form of battery override is possible, at least on ThinkPad laptops, for setting things like battery charge thresholds. On the ThinkPad wiki:

https://www.thinkwiki.org/wiki/Tpacpi-bat
https://www.thinkwiki.org/wiki/Tp_smapi

There's even code on GitHub:
https://github.com/teleshoes/tpacpi-bat
https://github.com/morgwai/tpbat-utils-acpi

  • pfr replied to this.
  • pfr likes this.

      pfr tpacpi-bat is Linux-only. (Those scripts just manipulate the kernel-provided /sys/... files.)

      • pfr replied to this.
      • pfr likes this.

          pfr Out of curiosity, can you explain why you want to change the battery charge limit? I mean: what is the use-case? I, personally, would be very wary of fiddling with the battery manufacturer's (carefully tuned) values.

          • pfr replied to this.

              rvp the battery on my old x230 is the original, and doesn't hold charge for very long so I've been looking into replacements. Genuine Lenovo batteries are expensive, so before I purchase one I'd like to know I can keep it healthy for as long as possible.

              From what I've read, to keep lithium ion batteries healthy they shouldn't be charged over 70-80% and shouldn't be left to discharge below 30-20%

              With a utility like this I could essentially leave the laptop plugged in (it generally doesn't leave my desk) and it would never charge above 80% and would never discharge below 30%

              Setting triggers such as, charge to 80% then stop charging until the battery reaches 30% before it starts charging again. Or just set it to keep the battery charged with a certain threshold (between 50-80%). I believe that's the idea anyway. This essentially prevents battery degradation that would occur if it was to be kept plugged in and at 100% all day.

              pfr@sdf.org | https://social.sdf.org/@pfr | https://matrix.to/#/@pfr:bsd.cafe

              • rvp replied to this.

                  pfr Hmm. Discharging a battery while it is on AC power. Is this even possible with modern Smart Batteries (ie. those with built-in controller and firmware)? You mentioned that TLP on Linux worked well for you, right? Did TLP let you do this?

                  • pfr replied to this.
                  • pfr likes this.

                      rvp You mentioned that TLP on Linux worked well for you, right? Did TLP let you do this?

                      I said it works on linux. and I dont run linux on my ThinkPad. But I have a friend who uses TLP on his X1 Carbon ThinkPad running linux who claims the results are good. I Cant say for sure that it's possible to disable AC power while plugged in but If TLP can stop the AC from charging beyond a certain point then it must have the capability to control when AC power kicks in again?

                      I don't claim to know much about the capabilities of the software, I'm just seeking advice/knowledge on this subject.

                      pfr@sdf.org | https://social.sdf.org/@pfr | https://matrix.to/#/@pfr:bsd.cafe

                      • rvp replied to this.

                          pfr I Cant say for sure that it's possible to disable AC power while plugged in but If TLP can stop the AC from charging beyond a certain point then it must have the capability to control when AC power kicks in again?

                          Depends on what you mean by "control" here. Lemme explain:

                          Almost all removable batteries available nowadays are what're called Smart Batteries. When you plug these batteries in, the microcontroller/firmware built-into them determines the SoC (state of charge) of each of the cells of the battery pack, then applies a varying charge current to charge them: a large currents if the cells are drained and smaller amounts (to each cell individially) as the cells approach full capacity (100%)--which itself diminishes over the life-time of the battery. At 100% nominal SoC, the battery controller signals the laptop power supply to "shut-off" the current. It then monitors the individual cells and supplies a "topping-up" charge to keep the cells at 100%.

                          When off AC power, the battery controller monitors the SoC and sends a warning signal to the OS (at a set percentage--16% on mine), and also a critical signal at a very low SoC (1.6% on mine) so that the OS can do a clean emergency shutdown. (The microcontroller may also signal the OS to control the battery LED: colour, blinking, etc.)

                          Now, using TLP, on Thinkpad laptops, you might be able to set different thresholds instead of 100%-16%-1%. In your use-case scenario, you might set a full-charge threshold of 80% and a critical threshold of 30%, (giving you 50% of actual run-time off-line--3 hrs, instead of 6hrs, let's say) to prolong battery-life, and the controller will do the rest. Note that only the thresholds have been changed, not the operating mode of the controller. The laptop will still have to be unplugged and used, otherwise it will keep topping-up at 80% and never discharge down to 30%.

                          What, however, you want to do is to keep the Thinkpad on wall-power always and have the controller drain the battery while it is on AC power and while respecting your custom thresholds. This is operating the controller in an unusual mode of operation, and is what I wanted to know if is possible on modern Smart Batteries. It may be possible; it may not be (which is more likely).

                          The TLP documents are not much help, and I don't have a Thinkpad to experiment on, which is why I asked for clarification.

                            Once again @rvp very well explained, much appreciated.

                            I suppose I shouldn't worry too much then. I've just read a few articles now about how it's bad for the battery to keep your laptop/phone/whatever plugged in, but constantly plugging/unplugging my laptop and keeping an eye on the charge state gets tiresome.

                            What I would accept in consolation is a functional hardware backlight control in NetBSD to replace redshift adjusting the gamma/contrast. I feel my battery life isn't great because the screen is always at max brightness. I'm hoping this will be fixed in NetBSD 10.

                            pfr@sdf.org | https://social.sdf.org/@pfr | https://matrix.to/#/@pfr:bsd.cafe

                              pfr I feel my battery life isn't great because the screen is always at max brightness.

                              redshift can also adjust screen brightness although, I get your point. But, is xbacklight really that different? Or, what do you mean by hardware brightness control?
                              I honestly don't know, because as long as I can manage brightness I'm ok, as I do it mainly for comfort rather than battery saving.

                              • pfr replied to this.

                                  pin what do you mean by hardware brightness control?

                                  I am not 100% on the difference, I thought xbacklight was more of a hardware control, ie. actually controls the brightness level of the display panel, probably via altering the power going to the screen? Most battery saving modes that are built into operating systems generally dim the screen drastically in order to save juice!

                                  It would be great for the built in function keys for screen brightness to be supported and to function as intended and if it meant extended battery life that's a bonus!

                                  pfr@sdf.org | https://social.sdf.org/@pfr | https://matrix.to/#/@pfr:bsd.cafe

                                    pfr What I would accept in consolation is a functional hardware backlight control in NetBSD

                                    Edit: simplified patch
                                    If you have an Intel graphics card, try what I've been doing all this while:

                                    1. Download FreeBSD's intel_backlight code from Github
                                    2. Unzip the .zip file, then apply this small patch:
                                    diff -urN intel_backlight_fbsd-master.orig/Makefile intel_backlight_fbsd-master/Makefile
--- intel_backlight_fbsd-master.orig/Makefile   2020-04-18 22:07:25.000000000 +0000
+++ intel_backlight_fbsd-master/Makefile        2020-12-10 08:04:46.878046765 +0000
@@ -1,9 +1,9 @@
 CC ?= clang
 CFLAGS +=
-LDFLAGS = -ldrm_intel -lpciaccess
+LDFLAGS = -lpciaccess
 
-INCS = -I/usr/local/include -I/usr/local/include/libdrm
-LIBS = -L/usr/local/lib
+INCS = -I/usr/pkg/include -I/usr/X11R7/include/libdrm
+LIBS = -L/usr/pkg/lib -Wl,-rpath=/usr/pkg/lib
 
 PREFIX ?= /usr/local
 MANPREFIX ?= $(PREFIX)
                                    1. Run this commands as root:
                                    pkgin install libpciaccess
                                    1. Assuming you have Xorg from the base install sets (the paths are set for this in the patch above), run (as root) the command below. This will install intel_backlight in /usr/local/bin and its man-page in /usr/local/man.
                                    make install-setuid
                                    1. man intel_backlight will show you what to do.

                                        rvp if they would just provide a release tag... it looks rather straight forward to package this.

                                        • rvp replied to this.

                                            pin it looks rather straight forward to package this.

                                            Go right ahead--was a bit surprised, actually, that no HW backlight control progs were present in NetBSD when I first looked into this a few months back.

                                            • pin replied to this.

                                                rvp Go right ahead

                                                I would, if there was a release tag.

                                                • rvp replied to this.
                                                • pfr likes this.

                                                    pin I would, if there was a release tag.

                                                    File an issue, then.

                                                    • pin replied to this.
                                                    • pfr likes this.

                                                        rvp I'm nearly sure the lack of releases/tags has something to do with licensing. Its a bit unclear to me if its allowed or not.

                                                            pin I'm nearly sure the lack of releases/tags has something to do with licensing

                                                            I never thought of that...However, since Linux -> FreeBSD is OK, I don't think FreeBSD -> NetBSD will raise eyebrows. What's good for the goose is good for the gander.

                                                            • pfr replied to this.
                                                            • pfr likes this.
                                                                4 months later