blob: 933045d0323d2cc5eafeb3be33e3f0078d29f08c [file] [log] [blame]
// Copyright 2014 The Chromium OS Authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
syntax = "proto2";
option optimize_for = LITE_RUNTIME;
package power_manager;
// Included in powerd's SuspendImminent signal, sent when the system is about to
// suspend. If any clients previously called RegisterSuspendDelay, suspending
// will be deferred until they've called powerd's HandleSuspendReadiness method.
// The general flow is as follows:
// 1. A client that needs to perform some work before the system can be
// suspended listens for SuspendImminent and SuspendDone signals from powerd.
// 2. The client passes a RegisterSuspendDelayRequest message to powerd's
// RegisterSuspendDelay method and receives a RegisterSuspendDelayReply
// message in response. The client saves the |delay_id| field from the
// response.
// 3. When the power manager is about to suspend the system, it emits a
// SuspendImminent signal containing a SuspendImminent message.
// 4. Upon receipt of the signal, the client performs any last minute work
// that it needs to do and then calls powerd's HandleSuspendReadiness method,
// including a SuspendReadinessInfo message with its |delay_id| and the
// |suspend_id| field from the SuspendImminent signal.
// 5. Once powerd has received notification that all registered clients are
// ready to suspend, the system will be suspended. If the initial suspend
// attempt fails, it will be retried automatically, but additional
// SuspendImminent signals will not be emitted.
// 6. After the suspend request is complete, powerd emits a SuspendDone signal
// containing a SuspendDone message. The client should undo any pre-suspend
// work that was done in response to the SuspendImminent signal.
// 7. Before the client exits, it calls UnregisterSuspendDelayRequest with a
// UnregisterSuspendDelayRequest message containing its delay ID.
// Note that the original suspend request may be aborted before all clients have
// reported readiness; this can happen if a user closes and then quickly opens
// the lid, for instance. In this case, powerd will emit SuspendDone and return
// to normal unsuspended behavior without waiting for clients to report
// readiness. It's unnecessary for clients to report readiness for the original
// |suspend_id| after a SuspendDone containing the same ID has been received.
// Clients that start asynchronous operations in response to SuspendImminent
// should take this possibility into account. One approach is to queue the
// "undo" operation when SuspendDone is received so it will run after the
// original operation completes. Note that a second SuspendImminent signal may
// be emitted before the original operation has completed; in this case, the
// client may wish to unqueue the undo operation and instead report readiness
// for the second, current |suspend_id| once the original operation completes.
message SuspendImminent {
// Next ID to use: 2
enum Reason {
// The user inactivity idle timeout was reached.
IDLE = 0;
// The lid was closed.
// Some other reason (e.g. an explicit user request).
OTHER = 2;
// Unique ID corresponding to this suspend request. This is included in the
// SuspendReadinessInfo message passed via HandleSuspendReadiness.
optional int32 suspend_id = 1;
// The reason the system is suspending.
optional Reason reason = 2;
// Included in powerd's SuspendDone signal, sent after the system has completed
// a suspend request. Each SuspendImminent signal will be followed by a
// SuspendDone signal.
message SuspendDone {
// Next ID to use: 3
// Unique ID corresponding to the suspend request.
optional int32 suspend_id = 1;
// Wall time that the system was suspended, as given by
// base::TimeDelta::ToInternalValue().
optional int64 suspend_duration = 2;
// Included in calls to powerd's RegisterSuspendDelay method.
message RegisterSuspendDelayRequest {
// Next ID to use: 3
// Upper bound on the amount of time that the power manager will wait for this
// client to call HandleSuspendReadiness before suspending the system, as
// given by base::TimeDelta::ToInternalValue().
optional int64 timeout = 1;
// Human-readable description of the delay's purpose (e.g. the name of
// the daemon that requested the delay). Only used for debugging.
optional string description = 2;
// Included in responses to powerd's RegisterSuspendDelay method.
message RegisterSuspendDelayReply {
// Next ID to use: 2
// Unique ID assigned to the client that registered this suspend delay. This
// is included in later HandleSuspendReadiness and UnregisterSuspendDelay
// calls.
optional int32 delay_id = 1;
// Included in calls to powerd's UnregisterSuspendDelay method.
message UnregisterSuspendDelayRequest {
// Next ID to use: 2
// ID that was returned in response to the original RegisterSuspendDelay call.
optional int32 delay_id = 1;
// Included in calls to powerd's HandleSuspendReadiness method.
message SuspendReadinessInfo {
// Next ID to use: 3
// ID that was returned to the client in response to its invocation of
// RegisterSuspendDelay.
optional int32 delay_id = 1;
// ID that was included in the SuspendImminent signal that provoked this
// readiness call.
optional int32 suspend_id = 2;
// Included in calls to powerd's RecordDarkResumeWakeReason method.
message DarkResumeWakeReason {
// Next ID to use: 2
// Wake reason that caused the current dark resume.
optional string wake_reason = 1;