Repository navigation
Update recommended for everyone on 1.0.0.
1.0.0 talked to the EC only through its ports 0x62/0x66. Windows' own EC driver uses the same ports, and the two collided about three times an hour. Each time, Windows logged ACPI event 13, "The embedded controller (EC) did not respond within the specified timeout period", in the System log. On the test unit that meant 212 in 66 hours, against none before the plugin was installed. With 1.1.0 there were none in the first 3 hours.
- Fans 1-2 and the EC temperature now go through the BIOS's own WMI fan interface (
root\wmi:PowerSwitchInterface). Its ACPI code reaches the EC through the memory-mapped EC RAM, so it cannot collide with Windows. The EC ports are used only for fan 3 (read every 30 s), the startup checks, and handing the fans back to the firmware when Fan Control closes. - The remaining port traffic waits for an idle EC, gives way to Windows' queries, and never takes a byte meant for someone else. On a BIOS without the WMI interface, the plugin falls back to the ports and says so in Fan Control's log.
- If handing a fan back ever fails, the fan is held at 80 % instead, so it fails loud rather than hot.
axb35ctlchanges:sniff(a read-only watch of who else talks to the EC);--ports;- a transport line in
status; - Ctrl+C now always releases the fans.
- Sensor and control names are unchanged, so saved curves keep working. Same 80 % cap as 1.0.0.
Upgrade: close Fan Control, replace FanControl.Axb35.dll in its Plugins folder with the one matching your build, unblock it, and start Fan Control again. The DLL to pick: net8.0-windows\FanControl.Axb35.dll if the folder has FanControl.runtimeconfig.json, or net48\FanControl.Axb35.dll if it has FanControl.exe.config. Fan Control's log should say through BIOS WMI.
Details and measurements are in the README ("How it works") and in #1.
SHA-256 of FanControl.AXB35-1.1.0.zip: 944b7706851f1f0fb4212fadbea609f50f2ca1e8115659dae1e024d1fb06d0ed
Per-file hashes are in SHA256SUMS.txt inside the zip.