Blocking suspend blockers

By desktop distros I mean Ubuntu, Fedora etc that are used on both desktops and laptops. As dlang has pointed out, laptops are often set to suspend after a certain period of inactivity by the user. This non-user-initiated-suspend can and does sometimes interrupt important activities (such as watching a movie, downloading a file etc).

> A desktop computer cannot use opportunistic suspend as it stands, because:
> * The hardware is not designed that way; suspending (spinning down) your hard drive every few seconds is a great way to kill it

Desktops/laptops are certainly different beasts in terms of hardware than mobile devices. A laptop with a solid-state drive (that isn't damaged by a suspend/resume "every few seconds") could potentially handle frequent suspend/resumes whereas a machine with a hard drive couldn't.

Currently we rely on the user or the disto to set reasonable policies in terms of how soon to suspend when running on battery power, but ideally the driver itself would inform the system of it's limitations. A correctly implemented suspend blocker API might be a way to achieve this.

Also Android's userspace API for suspend blockers (which they call wakelocks) supports multiple suspend states:
http://developer.android.com/reference/android/os/PowerMa...

Possibly a suspend blocker implementation would allow devices that are happy to suspend frequently to do so while others are kept active. A user may wish for their dual 24" monitors and 12-core CPU to suspend after 3 minutes of inactivity but not their hard drive (which would suffer too much wear). A well implemented suspend blocker API could allow the drivers to indicate when they are willing to suspend.

> * Current software does not acquire suspend blockers where they would be expected by the user

Of course nobody is using an API that doesn't exist yet. But I think you're assuming that by implementing suspend blockers distros would be forced to suspend very frequently like Android devices do, thereby causing problems for software. There's no reason why they would need to be configured this way.

But by providing the API a browser that's downloading a 600MB ISO from a server that doesn't support resuming could indicate it doesn't want the network & storage systems to be suspended till it's finished. Perhaps this might be sufficient to block a timeout-triggered suspend but a user might still be allowed to force a suspend if required?

> * Current drivers do not use suspend blockers, so the system as a whole doesn't know when it *can* suspend. If it tries, chances are that the suspend will be blocked half-way until the driver can finish its work -- time during which the system is still running, but the user cannot do anything meaningful.

Most laptops running desktop distros are suspended after a period of inactivity when running on the battery. As you point out, they do so without the system really knowing that it can. The system is forced to *assume* that it can because drivers can't tell it otherwise because they have no API with which to do so. Providing this API rectifies this problem.

> This is an Android-specific feature that cannot be reliabily used in other configurations, possibly even other handsets.

I think it's a potentially useful feature for any Linux system that runs off a battery or uses a lot of power.