| This isn't purely a software engineering mess though. The PC architecture for "off" is a mess at the hardware level too. I mean, long ago you just had a physical switch on the power supply. But then filesystem authors invented buffering and that wasn't safe anymore. So now there were two ways to shut the machine off: the "safe" way and the old way (where the "old" way was still available via e.g. holding the power button down for 4 seconds). Then, we wanted to start using laptops and carrying them around. But booting the whole computer again and again every time you changed your seat became a chore, so software people invented this cool new trick where you could dump memory to disk and restore it later, so "hibernation" was born and we now had three ways to shut down. Then the hardware people jumped in and pointed out that really the problem here is just the CPU. DRAM refresh is cheap, so there's really no need to dump the RAM at all. Let's just shut the CPU off and come up with a hardware/firmware/OS/driver hack (yeah, it touches basically everything) for powering on into a known DRAM configuration. Much faster! And now we had a fourth way to shut down. (OK, this is a little spun. In fact suspend to disk and suspend to RAM landed nearly simultaneously in the PC world, with different manufacturers picking different horses. Then of course ACPI came in and standardized both, forever locking us into not one but two kinds of suspend.) Then of course, we had a paradigm shift where "mobile" OSes revisted this whole scheme and threw it out the window. The hardware people making mobile chips designed the clock and power gating logic such that the "suspend to RAM" happens essentially every time the CPU reaches an idle state, and never has to be "entered" explicitly the way ACPI S3 is. And now PCs are shipping with this scheme too even on systems where ACPI still works in a traditional way. So, yeah. FIVE. I mean, Microsoft surely made a UI mess out of this. But it's not like they were handed a simple problem to begin with. |
In reality, CPUs and SoCs have multiple levels of sleep, some of which are standardized for a platform. ACPI at least tries to specify what should happen on x86/x64 systems. ARM has some standards, and then each SoC implements a lot of their own, which, to be fair, are sometimes really cool.
For lots of the power saving modes, hardware drivers have to opt in. This is where a lot of problems happen, if a single driver doesn't work, a laptop won't go to sleep, and the battery dies. Or, on mobile, a single bug in some component (which may manifest itself only under certain situations, which is why a reset can fix some problems) can prevent a good sleep state from being entered.
Of course software can also present problems. For the longest time, if WebGL content was loaded in any tab in, I think FF (either that or Chrome, heh), then the GPU would stay on and the system would never go to sleep.
Fun stuff like that.
The behavior people really want is "turns on quickly, uses little battery." That is harder to do on PC due to legacy, but part of the problem is also different usage patterns from mobile. Users check their mobile frequently, if something is draining the battery, odds are it'll be noticed in a couple hours and the phone will get a charge (and some apps potentially force killed, based on how knowledgeable the user is.) Laptops have less periodic usage patterns, so a single problem program may not get noticed before the battery is completely dead.