Yeah, no drivers required, merely the ability for userland code to smash hardware by hand. That's a terrible situation. You want to adjust screen brightness on a Thinkpad right now? Write to the appropriate control registers in the GPU to send commands over the relevant eDP sidechannel and you can do that, except any modern operating system will prevent you from doing that because you're going to be racing against anything else that's trying to use the same index/value interface, and now you tried to adjust the brightness but actually changed some other value and now your screen is displaying garbage. You know how your brightness hotkeys used to work? They generated system management interrupts, which caused the CPU to STOP EXECUTING THE OS and EXECUTE OPAQUE CODE IN A HIDDEN AREA OF RAM, and THAT FUCKING SUCKED. Now they simply tell the OS that someone hit the key, and it's up to the OS to hook that up to actually doing something as a result. Is the user experience worse? Eh yeah in some ways, but if anyone cared enough we could make it better. Is the past a better place? Fuck no. In the past HP managed to screw this up such that if the hotkey interrupt ended up being serviced on CPU 1 it would restore the CPU registers on CPU 0 instead, and you'd crash immediately (Windows handled all of these on CPU 0 so it worked by accident).
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.
Yeah, no drivers required, merely the ability for userland code to smash hardware by hand.
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
For most of the past 20 years, brightness control has been ring 0 mechanism, ring 3 policy. ACPI provides a mechanism for the OS to interface with the EC in a way that aligns with any SMM that's going on, and where we are now is just fundamentally better than the halcyon DOS days you're pining for. It also means we don't need to involve another computer in here, which is what the EC is.
> 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?
And in response to your edit: do you think putting this code in hardware is more or less secure than having it in the OS because if it were in hardware all operating systems would be fucked while having it at the OS level means that only Windows is fucked
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.