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

[Gonzalo Odiard]

Using  powerd-inhibit-suspend directory is how ALL the activities are
working today,
and how powerd is used.
We can work in a new feature to sugar 0.98, to have a more generic power
management communication, in fact, would be great no need to copy/paste
similar code in a lot of activities, but I don't think we should do it to
solve this particular bug, or at this time in the release cycle.
Also I should be happy if playing a sound and inhibit suspend was solved
lower in the stack, but is not the case.
About the proposed ways, may be Paul can say what is the better.

Gonzalo

On Mon, May 14, 2012 at 12:57 PM, Sascha Silbe <silbe at activitycentral.com>wrote:

> 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/
>



-- 
Gonzalo Odiard
SugarLabs Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120515/59ddec59/attachment.html>