Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759256AbbEEQHg (ORCPT ); Tue, 5 May 2015 12:07:36 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:50632 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2993209AbbEEOjt (ORCPT ); Tue, 5 May 2015 10:39:49 -0400 Date: Tue, 5 May 2015 10:39:48 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Chirantan Ekbote cc: "Rafael J. Wysocki" , John Stultz , Olof Johansson , Bastien Nocera , Linux Kernel Mailing List , , Tomeu Vizoso , Linux PM list Subject: Re: A desktop environment[1] kernel wishlist In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3169 Lines: 58 On Mon, 4 May 2015, Chirantan Ekbote wrote: > Ok so now I can talk about how lucid sleep fits into all of this. The > power manager only considers a suspend attempt successful if the write > to /sys/power/state was successful. If the suspend was successful, > the power manager then reads another sysfs file > (/sys/power/wakeup_type in our kernel) to determine if the wakeup > event was user-triggered. If the event was user-triggered it sends > out a DBus signal announcing the end of the suspend, Chrome thaws its > renderer processes, the full UI comes back up, and the user can start > working. If the event was _not_ user-triggred (if it was the RTC or > NIC), the power manager sends out a different DBus signal announcing > that the system is in lucid sleep and will re-suspend soon. It will > then wait for all registered applications to report readiness to > suspend or for the max timeout to expire. > > If it so happens that a user interacts with the system while it is in > this state, the power manager detects it via the user activity message > that Chrome sends. This could be real (keyboard, trackpad) or > simulated (lid, power button). Either way, the power manager responds > the same way: it announces the end of the suspend, Chrome thaws its > renderers, the full UI comes back up, and the user starts working. If > there is no user activity and all applications report ready, the power > manager gets ready to suspend the system again. Since the NIC is now > a wakeup source, the power manager doesn't read the wakeup_count until > after all applications have reported ready because accessing the > network could increment the wakeup_count and cause false positives. This gives only an implicit description of the difference between "lucid sleep" and normal resume. I gather that "lucid sleep" means you avoid reactivating some parts of the hardware (in particular the parts used by the renderers), and perhaps also you shorten the inactivity delay before the next suspend. Is that right? The main point of "lucid sleep" is to allow the system to do a partial resume, in which some of the most power-hungry parts remain suspended? If that's true then some of the recent work on "direct-complete" may be sufficient to do what you want. See commit f71495f3f0c5 (PM / sleep: Update device PM documentation to cover direct_complete) and the preceding commits. The idea is that under some circumstances, devices that were in runtime-suspend before a system sleep can remain in runtime-suspend when the system wakes up. If you can force the rendering hardware to go into runtime-suspend when starting a system suspend, it can remain powered down when the system wakes up. Then if it isn't needed for anything (because you suspend the system again before doing any UI activity), it can remain powered down the entire time. No need for a separate "lucid sleep" state. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/