Re: Attempted summary of suspend-blockers LKML thread, take three

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Sat, Aug 07, 2010 at 10:46:59AM -0400, Theodore Tso wrote:

> True, but again, consider the MacBook.  If you plug in an iPod, the 
> machine will wake up for *just* long enough to let the iTunes sync the 
> iPod, but once its done, the machine goes back to sleep again 
> immediately.  I doubt MacOS has something called a "suspend blocker" 
> which prevents the machine from sleeping until iTunes finished, which 
> when released, allows the machine to suspend again immediately.  But 
> neither did I see any evidence that it took 30 seconds for some kludgy 
> polling process to decide that iTunes was done, and to allow the 
> MacBook to go back to sleep.  Clearly, the MacBook allows some 
> interrupts through, and some USB insert events through, but clearly 
> not all.  (Inserting a USB drive doesn't wake up the laptop; at least, 
> not for long.)

On the contrary, I suspect that it's precisely equivalent to userspace 
suspend blockers. There's no way to conditionalise USB wakeups - the 
system comes up when you plug or unplug any USB device. The system is 
then fully awake and I'd *guess* that ipods are magically exempted in 
some way, with itunes sending a signal when it's complete in order to 
allow the suspend policy daemon to trigger a suspend again.

> Can we do something as smooth with a Linux desktop?  And if not, why 
> not?  (Oh yeah, and wasn't this supposed to be the year of the Linux 
> Desktop?  :-)

gnome-power-manager supports applications inhibiting suspend, but right 
now I suspect that it'll never deal with the case where you resume with 
the lid closed. It's a simple matter of coding, though.

-- 
Matthew Garrett | mjg59@srcf.ucam.org