Add lucid sleep flag and debugging helper

chrome/browser/chromeos/power/lightbar.cc

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "chrome/browser/chromeos/power/lightbar.h"

[Daniel Erat, 2014/09/12 19:53:03]

nit: this should also be light_bar.h unless the class is renamed to Lightbar

+
+#include <cstring>  // needed for strlen()
+
+#include "base/command_line.h"
+#include "base/file_util.h"
+#include "base/logging.h"
+#include "base/message_loop/message_loop.h"
+#include "chromeos/chromeos_switches.h"
+#include "chromeos/dbus/dbus_thread_manager.h"
+
+namespace chromeos {
+
+namespace {
+const int64_t kDarkSuspendDelaySeconds = 4;

[Daniel Erat, 2014/09/12 19:53:03]

nit: int is fine if you don't specifically need 64 bits

+const char kLightBarControlPath[] =
+    "/sys/devices/virtual/chromeos/cros_ec/lightbar/sequence";
+const char kKonamiCommand[] = "KONAMI";
+
+}  // namespace
+
+void LightBar::DarkSuspendImminent() {

[Daniel Erat, 2014/09/12 19:53:03]

nit: move this down to match the order in the .h file

+  // The plan is to track the progress of push events and then re-suspend as
+  // soon as we know they have been processed.  In the meanwhile, we can hack
+  // around this by just having the light bar delay for a long time so that
+  // people can at least start playing around with this feature for their apps.
+  //
+  // TODO(chirantan): Remove this once we can accurately track the progress of
+  // push events.
+  base::MessageLoop::current()->PostDelayedTask(
+      FROM_HERE,
+      DBusThreadManager::Get()
+          ->GetPowerManagerClient()
+          ->GetSuspendReadinessCallback(),
+      base::TimeDelta::FromSeconds(kDarkSuspendDelaySeconds));
+
+  if (!has_lightbar_)
+    return;
+
+  if (base::WriteFile(control_path_, kKonamiCommand, strlen(kKonamiCommand)) !=

[Daniel Erat, 2014/09/12 19:53:03]

is there a plan to make a distinction between the dark resumes that are
initiated by powerd to possibly shut down if the battery level is low and ones
that happen in response to incoming messages? it seems weird to flash the light
bar in the former case; those are explicitly supposed to not be visible to the
user

[Chirantan Ekbote, 2014/09/15 23:20:46]

Yes, Derek is working on being able to distinguish network wakes from rtc wakes.
 Eric is also looking into separating rtc wakes for shutdown-after-x from rtc
wakes for dhcp renewals and gcm heartbeat messages (crosbug.com/p/31970).

Also, the light bar code is only going to live for one release.  I plan on
removing it once we're ready to ship.

+      static_cast<int>(strlen(kKonamiCommand)))
+    PLOG(WARNING) << "Unable to flash light bar during dark resume.";
+}
+
+LightBar::LightBar()
+    : control_path_(base::FilePath(kLightBarControlPath)),
+      has_lightbar_(base::PathIsWritable(control_path_)),
+      enabled_(CommandLine::ForCurrentProcess()
+                   ->HasSwitch(switches::kEnableLucidSleep)) {
+  if (enabled_)
+    DBusThreadManager::Get()->GetPowerManagerClient()->AddObserver(this);
+}
+
+LightBar::~LightBar() {
+  if (enabled_)
+    DBusThreadManager::Get()->GetPowerManagerClient()->RemoveObserver(this);
+}
+
+}  // namespace chromeos