What a title...<p>I still remember when it was the norm for features like this to be entirely implemented in the EC and behaved sanely in any OS, even one that doesn't know about ACPI. For example, on old Thinkpads you can adjust the screen brightness, audio volume, and turn on/off the keyboard backlight in DOS. No drivers needed at all. The outliers were the stupid designs that would overheat and shut down if you left the laptop sitting in the BIOS setup screen for too long, because the fans would stay off. Several decades later, ECs have gotten much bigger flash and RAM, and BIOSes have bloated several times, yet modern laptops need an OS and a massively complex driver loaded just to do something trivial. I recently discovered on a new Thinkpad that the screen brightness was not adjustable in the bootloader, or even early in the OS boot, and that GPU drivers were necessary for that function. A regression which by any other name would just be by design. IMHO this is the increasing fragility leading to the closing of the PC ecosystem that MS ultimately wants.
Windows makes it much easier for userland policy agents to plug into WMI than to call raw ACPI methods, so WMI became much more popular as Microsoft made it more difficult for vendors to ship random kernel drivers. I didn't write the first WMI integration for Linux (that was Carlos Corbacho back in 2008) but I did write various glue drivers - initially for HP because there was one single hotkey on my laptop that fired a WMI event and which Linux couldn't receive, and later the entire Sony hotkey driver which involved a ludicrous number of layers of indirection. WMI is /somewhat/ self describing (there's a method to call to get a compressed binary of a blob that contains method signatures), but unfortunately there's no requirement that anything <i>they</i> call is documented in any way, so it's often still a matter of reading decompiled ACPI bytecode.<p>I have taken psychic damage so you don't have to.
> Linux separates things such that I was looking at C files in drivers/platform/x86 and header files in include/linux/platform_data/x86. And the ACPI code lives other places as well. It’s all very orderly, but at times it felt like navigating a grocery store that arranges products in alphabetical order. Logical, but not exactly cozy.<p>So beautifully put!
> Battery life is also much better. The fan itself is obviously eating less power. I think the CPU also enters a somewhat lower power state in whisper mode, or it’s willing to sleep a little deeper. It’s not clear everything that changes, and it varies by machine, but that’s the beauty of it.<p>You can get 90% of the way here on an Intel CPU by setting the EPB. There are a number of ways to do this on Linux: <a href="https://wiki.archlinux.org/title/CPU_frequency_scaling#Intel_performance_and_energy_bias_hint" rel="nofollow">https://wiki.archlinux.org/title/CPU_frequency_scaling#Intel...</a><p>By shifting to a more power efficient mode, the fan noise should be lowered or eliminated (the fan in my laptop is default off and it rarely comes on at all).
Nice artical! However the supposed rationale for having ACPI WMI is wrong, the real reason is that it allows firmware to (almost) directly expose higher level WMI objects, which is in my opinion clearer and easier to use than the sysfs style used in linux. The problem is that it stopes making any sense when all the supporting infrastructure is not available.