lkml.org 
[lkml]   [2010]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Attempted summary of suspend-blockers LKML thread, take three
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


\
 
 \ /
  Last update: 2010-08-08 18:21    [W:0.230 / U:2.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site