Thank you @jean for this, and for pointing me in the direction of fw-ectool!
I have a small side question: on Arch, installing the fw-ectool-git package works fine, producing the ectool binary as expected. However, passing in --interface=lpcprevents things from working (as opposed to not specifying any value for --interface, or using --interface=fwk which doesn’t seem to be documented by works, added here):
$ sudo ectool --interface=lpc fanduty 0
Missing Chromium EC memory map.
Unable to establish host communication
Couldn't find EC
It’s just interesting that lpc works for you but not for me, given that we are both on a Framework laptop? Again, everything works fine for me if I avoid specifying lpc, I’m just curious why we see different behavior on the same(?) hardware. Perhaps we are using different version of ectool?
Indeed !
It still works for me when removing the interface parameter, my mistake.
I can’t remember why I came to the conclusion that this parameter was required, but it clearly isn’t
I’ve updated the repo (along with a new feature, Strategies).
Thanks @dgquintas !
As of why does it work fine on ubuntu with --interface=lpc and not on Arch, I have no answer. Not very willing to dig but if someone knows, please let us know
I made this account just to thank you for this. I was almost going to return my framework because the fans were wayy too loud and I couldn’t concentrate on my work because of them.
This is amazing work @jean ! Thanks for sharing. This thread should be pinned somewhere for visibility! I’d agree that the default fan curve seems overly aggressive.
My only suggestion for potential improvement would be a slow ramp up / down when a new target fan value is set. Would just be slightly nicer sound-wise. But I understand would make the code more complex when we can only set discrete values through ectool.
Do you have an idea of how frequently it’s possible to update the duty value using ectool? Could it be done multiple times per second for example? Not sure if this would have performance implications. This is interesting actually, I might have a play!
You can get a slower ramp up by increasing the MovingAverageInterval parameter in your config.
For ramp down however, the script takes the minimum temperature between average temp and current temp, so it’s an instant change in fan speed whenever the cpu load decrease suddenly.
To make the ramp down just as smooth as the ramp up, you can remove these 2 lines: fw-fanctrl/fanctrl.py at main · TamtamHero/fw-fanctrl · GitHub
and replace them with this:
If this new behavior works for you, feel free to make it configurable, PRs are welcomed
About ectool, it’s a very lightweight program so there won’t be performance implications if you trigger it frequently, but I don’t think that the fan itself can mechanically react to more than 1 request/sec. Not 100% sure about it though, let me know if you fiddle with it and find something interesting !
I created an updated version of TamtamHeros fw-fanctrl which enables automatic switching between two custom fan curves depending on if the laptop is charging or discharging. I created a pull request for this. Until its merged into the original fw-fanctrl the updated version is available in my GitHub repository.
The current charging status of the laptop is read from the following file: /sys/class/hwmon/hwmon2/device/status
On my Framework Laptop running Pop OS 22.04 this works. I don’t know yet if this path works for all Framework Laptops on all Linux distributions. So any feedback is appreciated.
I’ve just published an update which allows to change the strategy more easily: you can now type fw-fanctrl lazy or fw-fanctrl medium or any other strategy available in the config file without having to mess with the running service.
To get it, you can just pull the latest main and run the install script again.
Nice feature/bugfix from @emrebicer: Fans keep working after suspend · Issue #6 · TamtamHero/fw-fanctrl · GitHub
If you’re living like me in a cold/temperate country and you don’t do heavy computation, you might have not noticed it but the fan was not actually stopped by fw-fanctrl when going to sleep. Now it is
I’ve extended the great work of @jean with an cinnamon applet make the switch between strategies easier.
Framework FanCTRL - Fan Strategy Control Applet for Cinnamon
This applet allows you to control the fan speed strategies of Framework laptops directly from your desktop. It uses fw-fanctrl / framework-ec to select different fan speed strategies.
- Right click on the menu bar.
- Open "Applets".
- Click on "Download" tab.
- Search for "FanCTRL".
- Click on the install icon next to the applet name.
The applet should now be available in your Applets settings panel. Add it to your panel to start using it.
It shouldn’t be that hard to make the code run on Windows using ectool, but you will need to disable secure boot to install the EC driver, which is the biggest problem. Otherwise, what would need to change in the source code is the whole running-as-a-service part and checking for temperatures (but you could also call ectool to get the temperatures).
I’m grateful, because this seems to be working, but I’m having some problems with the terminal interface: ‘-q’ does nothing. ‘–list-strategies’ does nothing. ‘–run’ just causes a bunch of concerning print-outs:
Exception in thread Thread-1 (startServerSocket):
Traceback (most recent call last):
File "/usr/lib/python3.12/threading.py", line 1073, in _bootstrap_inner
self.run()
File "/usr/lib/python3.12/threading.py", line 1010, in run
self._target(*self._args, **self._kwargs)
File "/usr/bin/fw-fanctrl", line 118, in startServerSocket
os.remove(COMMANDS_SOCKET_FILE_PATH)
PermissionError: [Errno 13] Permission denied: '/run/fw-fanctrl/.fw-fanctrl.commands.sock'
Error getting I/O privilege: Operation not permitted
Cannot find I2C adapter
Unable to establish host communication
Couldn't find EC
…but ‘–resume’ DOES work and causes the fan speed to change. ‘–pause’ also seems to work as intended.
