When I first bought my Framework, the battery charge limit reset after
every boot, necessitating something like this. With later firmware
versions, it doesn't reset, so there's no need for a service. Just set
your preferred limit once, using whatever method you like, and then
forget about it.
The only thing I use either of these for is setting the charge limit.
Both seem to work identically. I've been using framework-system for a
month or so and haven't noticed any difference.
If you set a charging threshold on the battery, you may bounce between
charging and discharging while still on AC. The profile only needs to
change when AC is disconnected. If the battery is discharging, but AC is
connected, don't switch to a power-saving profile.
I think.
Apparently changes made via ectool only survive power off if the laptop
remains plugged in, so in practice we have to set this on every boot.
https://wiki.archlinux.org/title/Framework_Laptop_13#Battery_control
Setting the lower and upper charge percentage to the same value causes
the controller to idle the battery at that percentage. This seems like
it would be better for the long term health of the battery than giving
the battery a range to constantly dis/charge between. It also feels more
like what I'm used to from all my years of Thinkpads and TLP.
I have also set the max charge on my battery to 90% in the BIOS, as per:
https://guides.frame.work/Guide/Enabling+Battery+Saver+Functionality+in+BIOS/392
I'm not sure if a looping script like this is the best way to accomplish
this. I don't understand why TuneD doesn't provide this functionality
itself, like TLP does.
The default TLP config now lives at /etc/tlp.conf. Override files should
be installed to /etc/tlp.d/. This allows us to more easily make our few
customizations.
The old tlp-sleep.service systemd unit no longer exists.
The only functional change here is excluding printers from USB autosuspend,
which is the tlp 1.1 default
ALPM can be changed when kernel 4.15 is released.
Existing users should remove the old udev rules.
# rm /etc/udev/rules.d/99-lowbat.rules
notify-send doesn't work since the script is being called as root, but
that is fixable. This at least gets the low battery notification via
wall and suspension at critical levels working consistently, unlike the
unreliable udev approach.
I think I originally got this from the official TLP docs, but
systemd-rfkill isn't a template, so we don't actually want the @ in
there.
Fixes some of #18.
udev was not distinguishing between multiple batteries. It was
suspending the system when the secondary battery reached the threshold,
even if the primary battery was still full, which is not the desired
behaviour.
There may be a way to tell udev which battery we care about, but it was
easier for me to just write a shell script that handles all the logic.
The script warns when the primary battery is low and suspends when the
primary battery is critical.
I tried calling the script with a single udev rule with a capacity range
of 0-10, however that resulted in no warnings and suspending only when
the battery went to 0%. Not useful. With two rules with different ranges
like this, the system is consistently suspended at 5%, which is what I
want. I sometimes get warnings in the 6-10% range, but not consistently.
I don't know why.
If the warnings won't work, we could create a systemd timer to call the
script every ~60 seconds or so. That will definitely work, but it seems
like udev should be able to handle this.
