Using powerd-inhibit-suspend directory is how ALL the activities are working today,<div>and how powerd is used.<div>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.</div> <div>Also I should be happy if playing a sound and inhibit suspend was solved lower in the stack, but is not the case.</div><div>About the proposed ways, may be Paul can say what is the better.</div><div> </div><div>Gonzalo</div> <div> <div class="gmail_quote">On Mon, May 14, 2012 at 12:57 PM, Sascha Silbe <<a href="mailto:silbe@activitycentral.com" target="_blank">silbe@activitycentral.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><a href="mailto:godiard@sugarlabs.org">godiard@sugarlabs.org</a> 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. </div>/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] <a href="http://upower.freedesktop.org/docs/QoS.html" target="_blank">http://upower.freedesktop.org/docs/QoS.html</a> [2] <a href="http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/" target="_blank">http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/</a> [3] <a href="https://www.kernel.org/doc/Documentation/power/pm_qos_interface.txt" target="_blank">https://www.kernel.org/doc/Documentation/power/pm_qos_interface.txt</a> [4] <a href="http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit" target="_blank">http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit</a> [5] <a href="http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.SessionManager.xml#n84" target="_blank">http://git.gnome.org/browse/gnome-session/tree/gnome-session/org.gnome.SessionManager.xml#n84</a> [6] <a href="http://lists.laptop.org/pipermail/devel/2011-August/032809.html" target="_blank">http://lists.laptop.org/pipermail/devel/2011-August/032809.html</a> [7] <a href="http://lists.laptop.org/pipermail/devel/2010-April/028394.html" target="_blank">http://lists.laptop.org/pipermail/devel/2010-April/028394.html</a> [8] <a href="https://dev.laptop.org/git/projects/ohm/tree/docs/dbus-interface.xml" target="_blank">https://dev.laptop.org/git/projects/ohm/tree/docs/dbus-interface.xml</a> [9] <a href="https://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix" target="_blank">https://en.wikipedia.org/wiki/Unix_philosophy#McIlroy:_A_Quarter_Century_of_Unix</a> -- <a href="http://sascha.silbe.org/" target="_blank">http://sascha.silbe.org/</a> <a href="http://www.infra-silbe.de/" target="_blank">http://www.infra-silbe.de/</a> </blockquote></div> <div> </div>-- Gonzalo Odiard SugarLabs Argentina </div></div>