[Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

[Sascha Silbe]

godiard at sugarlabs.org writes:

> To avoid stoping playing the text when the xo go to sleep.
> This patch creates a file in /var/run/powerd-inhibit-suspend/
> and remove it when finish.

/var/run/powerd-* is an implementation detail of a particular downstream
implementation of power management (namely powerd). I don't think it's a
good fit for Sugar upstream to be this tightly bound to downstream code.

Leaving aside the question whether we need to interfere with power
management at all in this particular case (as Paul has pointed out
correctly, powerd should treat audio "traffic" as non-idleness and
inhibit suspending), there are likely to be other cases where it may be
beneficial to interface with the power management code. The important
thing is to make sure that it's implemented in a hardware- and
implementation-independent manner. Since AFAICT there is no open
standard (published by a standard-setting organisation) on this kind of
interface, the next best thing we can do is to choose an interface that
any power manager (implementation) _can_ implement; preferably one
that's already implemented by one or more existing components. Even
better if that component is in widespread use (but remember the
hardware- and implementation-independent rule).

The above is important not just for hardware independence of Sugar, but
also for better operation of non-Sugar applications on XOs. If we can
agree on a suitable interface, it can a) be implemented by any
power manager and b) be used by all applications.

Possible choices, potentially combined:

1. UPower API

   UPower has a D-Bus API to set "latency requirements" [1,2]. The
   UPower back-end code uses the kernel PM QoS interface [3] to set the
   requested CPU (DMA) latency (in µs, up to ~35 minutes) and network
   throughput (in kbps). cpuidle hooks into the PM QoS framework to
   provide CPU latency management.

   This is likely the future of fully automatic suspend
   mechanisms. Whatever other API we may want to use, it would make
   sense to use this one as well, at least on the client side. There's a
   gap to today's world of not-quite-transparent, user space initiated
   suspension. But we can close that gap by having powerd listen to the
   LatencyChanged signal (calling GetLatency() after setting up the
   signal handler to make sure it didn't miss some early request during
   boot) and having it inhibit suspend accordingly.

2. gnome-session API

   The org.gnome.SessionManager.Inhibit() method [4,5] allows registered
   clients to inhibit suspend (bit 3 of flags). This is a direct
   equivalent of the /var/run/powerd-inhibit-suspend/<pid>
   interface.

   gnome-session provides a lot of other functionality that wouldn't be
   sensible for a pure power manager like powerd to implement and the
   current implementation as part of gnome-session is geared towards
   manual suspension, not almost-transparent, automatic suspension like
   powerd is trying to achieve. But if we think this is the right choice
   of interface, Gnome folks may be open to extending the interface and
   / or implementation to match our needs.

3. Open Hardware Manager (OHM) API [8]

   While not in widespread use (anymore?), it's at least an existing API
   and doesn't interfere with other implementations (a problem the
   UPower and gnome-session may have, depending on how much the power
   manager wants to implement). OTOH there's a smaller chance many
   (non-Sugar) application developers will a) be aware of and b) use
   this interface, as it duplicates part of the above, commonly used
   interfaces.

   The advantage over touching a file in
   /var/run/powerd-inhibit-suspend/ is that with a D-Bus interface
   _code_ is running to handle the interfacing. An alternative power
   manager doesn't have to monitor arbitrary directories for random
   files that may appear.

4. Brand-new D-Bus API

   If we go this route, we should involve other desktop projects (Gnome,
   KDE, etc.) to agree on an API that all of us can use.

5. Brand-new CLI API

   At least better than hard-coding powerd directory paths.


Independent of the API issue, I'd prefer the Gnome components to be
extended to support our (= Sugar Labs and OLPC) use cases and letting
powerd die. Not because I consider powerd to be a bad piece of software
(quite the contrary, it's doing one thing and doing it well [9]), but
because it would align us better with mainstream. We'd get it a)
maintained by the much larger number of Gnome developers and b) used by
the many developers that write software for Gnome. Still not universal
(KDE etc. won't use it), but a step in the right direction.


Previous discussions on the same or a related topic:
- "powerd-dbus network extension" [6]
- "Power management vs. activities" [7]

Sascha

[1] http://upower.freedesktop.org/docs/QoS.html
[2] http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/
[3] https://www.kernel.org/doc/Documentation/power/pm_qos_interface.txt
[4] http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit
[5] http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.SessionManager.xml#n84
[6] http://lists.laptop.org/pipermail/devel/2011-August/032809.html
[7] http://lists.laptop.org/pipermail/devel/2010-April/028394.html
[8] https://dev.laptop.org/git/projects/ohm/tree/docs/dbus-interface.xml
[9] https://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120514/e5e93087/attachment.pgp>