Fan Service
flak.tedunangst.com
flak.tedunangst.com
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.
I wonder if this is a one-way street, that is, if a realization will come at some point that simple solutions to simple problems can be more robust...
I'd dispute it being over-engineering: media keys tend to control a mix of hardware and software (OS) features (looking at asus keyboards on the internet I see audio volume, mic mute, fan speed / perf governor, display off, brightness, projection mode, touchpad off, sleep, and airplane mode).
Given this, an OS driver is a requirement, and the OS further needs to access the hardware for obvious reasons.
This means you can either implement everything uniformly in driver (just bouncing from the interrupt to a hardware operation in the case of hardware features), or you can mix the implementation between firmware and driver.
Unless you have a very good justification to do so (which I'd very much dispute the existence of for gaming-oriented ASUS laptops) the latter seems like the over-engineering.
But you have to take software seriously as something that can improve a system, not just a cost centre to be minimised where possible, and an embarrassing source of problems that will ultimately end up in the newspaper or worse.
On the other hand, I'm not as optimistic about open-source BIOSes like Coreboot, whose only reason for existence seems to be "it's open-source!" --- that project has been around since the last century, yet still lacks any actual GUI/TUI for configuration, like any other BIOS has had since the late 80s.
There is no simply here.
You can’t list a litany of niche skills before implying that’s just life and it’s everyone fault they don’t have the time and knowledge to just, you know, casually reverse engineer and patch a binary.
Simple interfaces were fine when we didn't have pre-emptive multitasking, and didn't have SMP. Life is better now. Having mediated interfaces where we can ensure that anything accessing the same hardware is doing so in a controlled manner is a good thing. And, counter to your claim, this is a space where vendors do stuff in spite of Microsoft in ways that make it harder for Microsoft to provide a well-defined user experience - this is literally vendors trying to differentiate within the space Microsoft allows, not something that allows Microsoft more control.
Brightness control has always been in ring 0, or -1 when it was still exclusively SMM.
I don't know what you're on about. What "FUCKING SUCKED" about not having to worry about what the OS does, if it does anything at all? The OS can poke the EC if it wants to adjust the screen brightness, fan control, or whatever else. Otherwise the EC takes care of everything.
Windows handled all of these on CPU 0 so it worked by accident
...and if it was handled by SMM, Windows doesn't need to care at all!
Then again, I'm not surprised at your misdirection and half-truths given you've been essentially shilling Treacherous Computing and Restricted Boot among other hostilities.
Edit: and as if destiny itself wanted to show why needing an OS and accompanying mess of drivers to do something simple is a bad idea, especially for Asus products in particular, this shows up right on cue: https://news.ycombinator.com/item?id=43951588
> Otherwise the EC takes care of everything.
See, that's just not possible. Modern displays have the backlight integrated into them, and the control is over something that's roughly i2c over eDP. But the same i2c channel needs to be accessible to the OS, and if the OS and the EC try to access that at the same time then things will break. So you need some kind of locking, and that's utterly impossible if hitting a key just jams you into SMM and smashes some bits over there - you might do that in the period between the OS writing an index and writing a value.
> ...and if it was handled by SMM, Windows doesn't need to care at all!
The behaviour of the SMM handler is defined by the platform vendor, and if the vendor ends up only testing against one OS then they may embody assumptions about that OS. In this case they assumed that SMM could only be triggered when running on CPU 0, which was true in the case of Windows and not in the case of Linux. This isn't about Windows needing to care, it's about SMM being a mechanism for vendors to accidentally assume that what Windows does is universal.
> Then again, I'm not surprised at your misdirection and half-truths given you've been essentially shilling Treacherous Computing and Restricted Boot among other hostilities.
I am arguing that it is better that this code lives in visible space, executed in the context of the OS, and subject to security boundaries that the OS imposes. You appear to be arguing for opaque code running on a separate microcontroller, mediated by code running on the main CPU, but which stops the entire OS from running while it executes, and which is hidden from the OS. Which of these sounds better for the user?
Maybe that's a bad idea? You've clearly outlined some problems it causes.
brightness control, thinklight, etc. all work without any os support. this (and many other nice touches) was an unexpected surprise from an entirely hobbyist hack.
this has been my daily driver for years and i'm looking forward to future upgrades (there seems to be a meteor lake motherboard in the works).
I think putting in key backlights made the previous spill-proof tray design not viable, so it's not a pure win and I could see why they tried to hang on to the old design.
Old Thinkpads could survive repeated spilling of drinks on their keyboard, the only laptop I've seen to cope with that. There was a tray underneath the keys with a drainage hole all the way through the laptop, that way the liquid didn't reach any zappy bits.
Panasonic's "Let's Note" series, too. Their machines from ~2002 were quite impressive to me.
I have taken psychic damage so you don't have to.
I dumped my laptop's DSDT tables and decompiled all the WMI methods. It turned out to be stub code.
So beautifully put!
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: https://wiki.archlinux.org/title/CPU_frequency_scaling#Intel...
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).
P.S.: This project is obligated to have an anime mascot girl and a logo where she is embarrassed while trying to keep her skirt in place because a house fan suddenly turned on xD