Open brenobaptista opened 5 months ago
I am not aware of a a way to make the health mode setting persistent across reboots. I would also guess there is none. You could pass the enable_health_mode=1
argument to insmod when you load the module, e.g. from /etc/modules.
This way you won't need an additional script for writing to /sys/bus/wmi/drivers/acer-wmi-battery/health_mode
. I suppose you could also add the argument to this file if you use the dkms setup, but I have not tried it.
I may chime in just a little bit, based on my experience making the installation package for this driver on Arch Linux
Which is surprising to me—and it doesn't require extra scripts to force that 1 but a simple reboot. (You may git clone these packages & inspect the code, but it's mostly dry of any magic.)
Only did different was make an acer-wmi-battery.conf to /usr/lib/modules-load.d/
as advised to me from the Arch Linux forums, but nothing else.
I may chime in just a little bit, based on my experience making the installation package for this driver on Arch Linux
- As soon as I reboot (after installing either the dkms or dkms-git package of this driver), _healthmode is automatically set to 1
Which is surprising to me—and it doesn't require extra scripts to force that 1 but a simple reboot. (You may git clone these packages & inspect the code, but it's mostly dry of any magic.)
Perhaps some Acer laptops persist the value and some do not. That seems totally possible to me. But there seems to be no way to control this in the WMI interface. On my laptop, the setting is gone after a cold reboot. Which model do you have?
Perhaps some Acer laptops persist the value and some do not. That seems totally possible to me. But there seems to be no way to control this in the WMI interface. On my laptop, the setting is gone after a cold reboot. Which model do you have?
Acer Spin 3 (SP314-21N), which was released on 2021.
And I did make sure to turn on Battery Charge Limit from Acer Control Center prior to migrating to Linux.
But there seems to be no way to control this in the WMI interface.
From all I know on my specific model, such control only existed at the Acer Control Center on Windows 10/11 (the toggle was there briefly until it vanished from a reinstall of Windows few years ago).
Unless that program was somehow reverse-engineered to work on Linux, or implement an open-source framework space to control Acer firmware/BIOS values (such as for Asus with asusctl), I have doubts on the permanence on keeping Health Mode on with just a sudo echo 1 without it being overridden afterward.
EDIT: Found this GitHub issue from TLP while browsing through @frederik-h , and it seems that you may be aware of this already.
But there seems to be no way to control this in the WMI interface. [...] EDIT: Found this GitHub issue from TLP while browsing through @frederik-h , and it seems that you may be aware of this already.
This driver is based on reverse-engineering the Windows tool and uses the WMI interface. But I did not find anything that would let you persist the state of the "health mode" between cold reboots. It seems to survive soft reboots and waking up from hibernation on my laptop. If you want it to be enabled by default, you need some init script that enables the health mode after each boot or you can enable it by passing a flag to the module when you load it. The latter option seems a bit easier to me, by the way.
If you want it to be enabled by default, you need some init script that enables the health mode after each boot or you can enable it by passing a flag to the module when you load it. The latter option seems a bit easier to me, by the way.
@frederik-h A SystemD service should work. Besides the one proposed by @brenobaptista, one idea is to use a loop (separated by an interval of few seconds) to check & change the health mode value, or a system trigger, (which I'm not aware of where to find).
If you want it to be enabled by default, you need some init script that enables the health mode after each boot or you can enable it by passing a flag to the module when you load it. The latter option seems a bit easier to me, by the way.
@frederik-h A SystemD service should work. Besides the one proposed by @brenobaptista, one idea is to use a loop (separated by an interval of few seconds) to check & change the health mode value, or a system trigger, (which I'm not aware of where to find).
There are lots of possibilities to enable the health mode on boot. You can use an init script or even a systemd service to write to /sys/bus/wmi/drivers/acer-wmi-battery/health_mode
, but I would recommend to load the module, for instance, in /etc/modules
and pass the enable_health_mode=1
argument. There is no need to loop over anything. As I said, the value should never get reset. There was however a report about some problems caused by a fan control driver which would reset the health mode setting, cf. #40. Hence, if the health mode settings gets reset on your system, this is probably caused by a bug in another driver.
Perhaps some Acer laptops persist the value and some do not. That seems totally possible to me. But there seems to be no way to control this in the WMI interface. On my laptop, the setting is gone after a cold reboot. Which model do you have?
This week, unfortunately, my health_mode no longer persists. Now I also have to set it to 1 manually every time I boot my laptop.
I've described what I found out on the PR for DKMS support. But basically another Acer Nitro 5 owner and I found out that by creating a systemd service to force health_mode to be 1 on startup fixed the problem of it going back to 0 after a few days for no apparent reason.
I have no experience with building drivers but maybe to fix this it would be needed to persist this value in a file and get that file on reboot/kernel updates.
I made a guide on my personal blog explaining how to use this driver and it would be nice to remove the extra step, it's a big chunk of the whole guide: https://www.brenobaptista.com/posts/battery-charging-threshold-acer-linux
Currently I'm using the DKMS fork but I assume it's a problem with the base software.