Basically every laptop I’ve owned I’ve had to disable sleep when the lid is closed as I often leave them plugged in and want background tasks like downloads or updates to be able to run while I’m not using the machine. However, I don’t think PC laptops have a way to switch to a super low power state and just run background tasks like downloads, alarms and notifications or running scheduled tasks without just being left on in regular power mode. Why is this not just a default feature of laptops, given that phones and tablets have been doing this kind of thing for the last decade or more?
Does anyone know if there are plans to make power management for laptops allow for running certain tasks in Windows or Linux in the future? My smug Apple using friend tells me his Macbook already does this, but is the lack of this feature on PCs software related or something innate to x86 vs ARM architecture?
d3Xt3r@lemmy.nz 1 year ago
Actually, they do, it’s called the “S0” low power state, and it’s part of the ACPI standard. Microsoft calls this “Modern Standby” in Windows (and “suspend to idle” in Linux) , and it’s pitched to do exactly what you’ve described.
The only problem is, the implementation sucks. Most users actually hate the S0 state because it consumes so much power - on some laptops, even the fans may continue to run on S0, and your laptop may overheat if you’ve closed the lid and chucked it in a bag.
Also, because Microsoft and Intel have been pushing this so much, the “standby” mode now defaults to S0 instead of S3 (full suspend-to-RAM) like it used to be, back in the day. So many users actually actively seen to disable S0 and go back to S3, via registry hacks etc.
So why is S0 so bad? Part of this is due to the limitations, long history and the variable nature of the x86 platform. All the power-saving stuff was implemented as an after-thought - both at the hardware and software levels, whereas ARM, at least the modern ARM ecosystem, was developed with mobile usage and power saving from ground up. An x86 PC is also made up of components from disjointed manufacturers, and we need all those components to implement the same standards so that it all works well as expected. So for instance, if a particular component isn’t capable of entering a low-power or active standby state, then it won’t - and you can’t do much about that.
The second half of the problem comes with the software. All applications must be modern standby / S0 aware, if not, one of two things will happen: that app will keep the system awake, or the app will get suspended by the Desktop Activity Manager (DAM). Either way, the app must be capable of running in the DRIPS phase (deepest idle runtime platform state), which rules out most Win32 apps (basically almost every app that’s not on the Microsoft Store).
Finally, the reality is that most PC users don’t care about modern standby regardless - and why should they, when they’ve all got smartphones, which handles notifications well? Also, hardly anyone does large file downloads these days, and the people who do still download, wouldn’t care about doing it while on battery (and if they do, they can take manual actions to lower the power consumption, such as switching to a power saving plan and turning off the display etc).
MrFlamey@lemmy.world 1 year ago
Thanks for the excellent response.
I wonder if Valve will try to implement it in Steam OS for the Steam Deck’s successor, as a lot of people complained about the lack of downloading while asleep after the Deck was launched. It would still need cooperation in hardware I assume, but they were able to get resuming games working, so it doesn’t seem like an insurmountable problem if there is enough desire from both gamers and Valve.
Vash63@lemmy.world 1 year ago
I don’t think this would need to wait for a successor. The problems are software, not hardware. They would need to have games and SteamUI get suspended but leave other processes running, might be tricky and prone to bugs.
qupada@kbin.social 1 year ago
Very much this; I've got a whole army of machines I can SSH into to launch a long-running download, which frequently additionaly cuts out a 2nd step of copying the file to where it needs to be after downloading it (a action which would normally cause additional battery usage on the laptop).
And I thoroughly agree with you; I want the laptop to go to S3 sleep immediately when I shut the lid, and then pull it out of my bag a hours later with only a couple of percent of the battery consumed in the interim.
fiat_lux@kbin.social 1 year ago
Thankyou for answering some historical mysteries for me. It has always irritated me that I didn't know why programs only sometimes drained battery while asleep - but it wasn't always like that, and I couldn't find a pattern in what programs affected it, and I didn't know why a Linux dual-boot on the same drive didn't cause the same issue. The backstory of this makes a whole lot of experiences make sense now.
What is involved in an app being S0 aware and running on DRIPS? Is this a badly-educated-developers-requiring-permanent-network-connections issue or a Microsoft-proprietary-certificate-bullshit thing or something completely different? I'm mostly curious for if I ever dive into desktop application development what performance optimisations I should be keeping in the back of my mind.
d3Xt3r@lemmy.nz 1 year ago
I haven’t developed a desktop app in ages so I’m probably not the best person to ask this, but my understanding is that if you develop a modern UWP app, then it automatically be S0 aware, and you can make use of WinRT APIs to execute background tasks. The user can also choose whether or not to allow this activity. I’m not sure if the WinRT APIs can be called from a regular Win32 app. For Win32 apps, as far as I’m aware, they should get suspended by the DAM automatically (and services may get throttled), but Windows may choose to unsuspend/unthrottle these apps if it thinks some critical activities are happening. I never looked into what it deems as a “critical activity”. Personally though I always disable S0 so that my laptop suspends as you’d expect it to
Bottomline is, if you’re making a UWP app it should all just automatically work, and if you’re making a Win32 app you need to look more into the DAM. There’s some info on that here: learn.microsoft.com/…/desktop-activity-moderator
MoonManKipper@lemmy.world 1 year ago
Very informative- thank you