This update incorporates some fixes from Debian. Most importantly, thinkfan will not segfault any more with the default config shipped by Debian, which does not specify any temperature input and instead relies on the defaults to work correctly.
After some annoying hassle during final testing, courtesy of the proprietary nvidia drivers, I finally decided to release 0.9.1. Besides some minor bugfixes and documentation updates, it adds a handler for the SIGUSR1 signal, which will now make thinkfan print the current temperatures. This should help a bit with tuning. Have fun!
OK, had a lot to do in the last months, so this had to wait a bit. The 0.9 release brings A LOT of new features, and probably even more bugs. So please please pretty-please read the stupid docs, test carefully and report any issues.
ok, I've kind-of finished 0.9 development. Since I'm paranoid about wasting instructions in the main loop, the code has become quite a mess (lots of global state). New features will include support for libatasmart (i.e. reading HD temperature from SMART), mixing sensor types (required since probably no one wants to use SMART exclusively), and a simplified biasing logic that allows a negative bias to flatten sudden temperature changes instead of exaggerating them.
Frobnicating the parser again. I've got this stupid urge to turn this into some parser design playground, but what the hell, the current hack works well enough (or does it?)
So, if you feel like helping out a bit, go ahead and pull the 0.8 branch from git. Run it with your config, run it with valgrind, and if it works, run it with some other (messed-up) config and valgrind. Then report any bugs on the tracker. Thanks a lot!
ok, another bugfix release for the 0.7 series. This should finally deal with the problems around the "level disengaged" feature.
ok, after a bit of delay, thinkfan 0.8 is now in a working state. As already mentioned, it will allow you to specify temperature limits for each sensor individually, as well as arbitrary strings as fan levels, while keeping intact most sanity checks. Of course your old config file will continue to work as well. Right now I'm tweaking a config with sensor-specific limits to suit my T61p, while looking for any left-over bugs ;-)
I think we're already memory leak-free, but there's no systematic testing. I'll see about putting the current code in a public repo, but I'm not making a release yet. If you feel like writing some nice unit tests, go knock yourself out!
Right now I'm quite short on spare time, so the 0.8 release will have to wait a little bit since it needs careful testing. In the meantime, I'm releasing 0.7.2 which contains a minor fix regarding the undocumented "level disengaged" feature. You can now use the special value -2147483648 as fan level to tell thinkfan to use "disengaged" or "full-speed" mode on thinkpads. Note that this works only in combination with DANGEROUS mode since it defeats some sanity checks. A better way of handling disengaged mode is coming up in 0.8.
I'm currently working on the 0.8 release, which will add two great features:
1. Fan levels can be arbitrary strings now. Besides doing lots of weird stuff, this also allows you to use "level auto" for certain temperature ranges.
2. Temperature limits can now be sensor-specific. Now you can specify a tuple of N temperatures as the upper and lower limit of a fan level. N must equal the number of temperatures thinkfan knows about and N must be constant in the entire config file.... read more
OK, 0.7.1 is out the door. It'll hopefully detect most error conditions before forking into the background, so people don't need to read their syslog to find out what's going wrong.
It'll also bail out if your temperature limits don't overlap, i.e. if there are temperatures for which there's no fan speed defined. I've actually seen some blogger recommend using that kind of broken config (wtf?).
I wonder if I made thinkfan a little too easy to use, because it seems there are many people using it who don't even understand the config syntax. It also seems the documentation is very hard to read for some. So please, if you have any criticism, especially on docs, give it to me!
I'm currently thinking of making thinkfan completely idiot-proof, i.e. by writing some script that does some profiling on your system and then comes up with very conservative, safe guesses for all settings.
I'm currently doing prerelease-testing on thinkfan 0.7.1, which will improve error handling, i.e. fail early and complain on the terminal if possible. It will also save some comparisons in the main loop.
OK, I'm getting ready to release thinkfan 0.7. I'm pretty much done with testing and fixing. Right now I'm expanding the man page that has been kindly provided by Evgeni Golov from Debian. I'll also include the init script they have provided.
I was asked to put an install target in the Makefile, but that would require a configure script. Then if I write a configure script, I could also just switch to autotools altogether, however that would put the bloat factor from 2 to 200, so I'm gonna postpone that for now.
As stated in the README, thinkfan looks for the highest temperature in the system and uses that to decide which fan speed to set.
This is potentially dangerous, mostly for harddisks, because they (and possibly other sensitive devices, too) have a much lower temperature rating than your CPU or GPU.
Thus it may happen that the highest temperature in the system stays just below the limit for turning on the fan (say 55 °C) for a long time. Now if the CPU doesn't generate enough heat to make the fan run, and outside temperatures are rather warm (say 28 °C), and the lid is closed, it may allow your HD to heat up to 55 °C, too, which alreay exceeds the rating for some devices. I've seen this happen when I left my laptop idle with the lid closed for many hours in a very warm environment. So please take care when using thinkfan.
BTW, I'm currently working on version 0.7, which will fix this by allowing to set specific temperature limits on single sensors.
thinkfan 0.5 is released!
It now supports *any* hardware via the generic sysfs hwmon interface.