Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Sascha Silbe si...@activitycentral.com writes: [...] 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. [...] For the benefit of those not following the OLPC development list: I've posted a patch for powerd to add UPower support, like I suggested in this thread. If it gets accepted, we can add a convenience wrapper around the UPower QoS interface to sugar-toolkit, so that Activities only have to do a single function call to inhibit suspend. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpQshrBcb4cA.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
[CC'ing devel@l.l.o because it touches operation of low-level software components on OLPC OS] Paul Fox p...@laptop.org writes: the problem is that there's no good operating system mechanism that powerd can use to know that audio is truly in use. it's possible to know that the audio device has been opened, and i have tried using that in the past. but most applications that use audio open the device once, and then leave it open. so even when they're playing nothing but silence, the device appears to be in use. While there could (and maybe should) be a distinction between the audio device being a) opened by a process and b) in actual use for playback or recording, ALSA doesn't make that distinction [1] and a lot of commonplace hardware doesn't support more than one substream. As long as the device is open, no other process will be able to use the device. Whether we like it or not, this is the kernel-level ALSA API and if applications don't obey their side of the contract (closing the device to de-allocate resources) it's simply an application bug. I haven't dug into GStreamer enough to tell what its API looks like w.r.t. resource acquisition and how that translates into ALSA device usage, but powerd is only concerned about the kernel level and a number of well-behaving Activities show that there's no major roadblock ahead; in fact a close look at the Record source doesn't even reveal any obvious kind of hack. regarding the other elements of this thread: it may be that system mechanisms for inhibiting suspend via upowerd or gnome are now mature enough to be of some use. this has never seemed to be the case in the past. plus -- they're all, as far as i can tell, just as specific to the power-manager-du-jour as the current powerd interfaces are. i.e., no one has created a generic set of interfaces which can be implemented in various ways behind the scenes. Yes, many of the Gnome APIs (remember, Sugar is built on Gnome components) are annoyingly specific to Gnome components. There are a number of cross-desktop environment APIs being worked on at freedesktop.org [2], but nothing related to session or power management is among them. The inhibit support of XSMP [3] is claimed [4] to be problematic, so no common base there either. When it comes to power management, we're living in a constantly changing world. Like with any standardisation effort, it will take a) someone to drive it and b) considerable time and effort to design and get people to agree on a common API. I've tried looking at what the APIs KDE uses for power management, but only hit a number of partially [5,6] or completely [7-9] broken API docs pages. What I've seen so far doesn't like any better or more cross-desktop environment than what Gnome does. Sascha [1] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver.pdf page 28 (page 21 using in-pdf numbering) [2] http://www.freedesktop.org/wiki/Specifications [3] http://www.x.org/releases/X11R7.6/doc/libSM/xsmp.html [4] http://live.gnome.org/SessionManagement/GnomeSession#Problems_and_Goals [5] http://www.purinchu.net/kdelibs-apidocs/solid/html/namespaceSolid_1_1PowerManagement.html [6] http://www.purinchu.net/kdelibs-apidocs/solid/html/powermanagement_8cpp_source.html [7] http://api.kde.org/ [8] http://api.kde.org/4.x-api/kdelibs-apidocs/ [9] http://api.kde.org/4.8-api/kdelibs-apidocs/ -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpW9MY3ht3TL.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Gonzalo Odiard godi...@sugarlabs.org writes: [...] That is a complete nonsense to me. [...] I'm not going to reply to your mail in detail because it wasn't constructive in any way; I even felt it to be slightly ad-hominem. See my other mails (including a patch, and maybe another one later today or tomorrow) for the way forward that I see. For those following only sugar-devel: The powerd patch [1] was posted on devel@l.l.o only as it doesn't touch Sugar code. Sascha [1] http://lists.laptop.org/pipermail/devel/2012-May/thread.html#35124 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpkiS2nu9hYa.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
On 05/09/2012 05:56 PM, Paul Fox wrote: gonzalo wrote: On Wed, May 9, 2012 at 12:42 PM, Paul Foxp...@laptop.org wrote: i would much prefer that we could prevent suspend during any audio playback, rather than have to have anyone that wants to make noise do it individually. But this should be done at a lower level, right? yes, sorry -- that comment wasn't really directed at sugar. Hi Paul, can you give some background information here, why preventing the XO to fall asleep when there is audio playback is not happening as of today? And what are the steps to make this happen at a lower level than Sugar? Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Ok, so I am still not clear on the whys. Why does the machine suspend when there is audio being played back? That sounds wrong to me. It would be the same as suspending why I am moving the mouse. Can someone provide some background information on this? Regards, Simon On 05/17/2012 08:08 PM, Gonzalo Odiard wrote: On Tue, May 15, 2012 at 4:51 PM, Sascha Silbesi...@activitycentral.comwrote: Gonzalo Odiardgodi...@sugarlabs.org writes: Using powerd-inhibit-suspend directory is how ALL the activities are working today, Quantity isn't the same as quality. That everybody is doing it doesn't make it suddenly a good idea. Quite the contrary, as platform developers we have the responsibility to take the lead and show what _best_ (not common) practice is. Activity authors can then adopt it. But implementing such solution probably should be a feature and will not be accepted at this time. and how powerd is used. That's exactly what I don't like: it's specific to powerd. That's fine for downstreams to decide for themselves and use your patch (Dextrose may be interested in it, for example), but it's not a good direction for upstream to take. That is a complete nonsense to me. Probably Dextrose will accept it, and OLPC too. In what _real_ users you think when you work? Do you prefer have a bug who affect to 90% percent of our users without fix, because your imaginary users may be don't have powerd? And think one solution can be: *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.* Wake up! This is not a university project. There are real users, and we should work for them. Gonzalo Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Powerd (/usr/sbin/powerd) itself is not that hard to read; it is just a shell script. On XOs, powerd is willing to aggressively suspend the system (and enable the DCON) if certain criteria are met which seem to indicate that the XO is not in use. These criteria include: - CPU usage below a set threshold - No recent keyboard/mouse usage - No network activity except for certain types (multicast and a few other things) - Camera usage above a set threshold - Nothing present which would inhibit suspend given the current ruleset (such as USB keyboards) The audio system is not currently monitored to sense activity because applications tend to open the audio device and leave it open, even if they are not making any sound at the moment. So if the CPU usage is low enough during text-to-speech playback and the audio device is unmonitored, we may try to suspend in the middle of playing audio. On Fri, May 18, 2012 at 7:00 AM, Simon Schampijer si...@schampijer.dewrote: Ok, so I am still not clear on the whys. Why does the machine suspend when there is audio being played back? That sounds wrong to me. It would be the same as suspending why I am moving the mouse. Can someone provide some background information on this? Regards, Simon On 05/17/2012 08:08 PM, Gonzalo Odiard wrote: On Tue, May 15, 2012 at 4:51 PM, Sascha Silbesilbe@activitycentral.**comsi...@activitycentral.com wrote: Gonzalo Odiardgodi...@sugarlabs.org writes: Using powerd-inhibit-suspend directory is how ALL the activities are working today, Quantity isn't the same as quality. That everybody is doing it doesn't make it suddenly a good idea. Quite the contrary, as platform developers we have the responsibility to take the lead and show what _best_ (not common) practice is. Activity authors can then adopt it. But implementing such solution probably should be a feature and will not be accepted at this time. and how powerd is used. That's exactly what I don't like: it's specific to powerd. That's fine for downstreams to decide for themselves and use your patch (Dextrose may be interested in it, for example), but it's not a good direction for upstream to take. That is a complete nonsense to me. Probably Dextrose will accept it, and OLPC too. In what _real_ users you think when you work? Do you prefer have a bug who affect to 90% percent of our users without fix, because your imaginary users may be don't have powerd? And think one solution can be: *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.* Wake up! This is not a university project. There are real users, and we should work for them. Gonzalo Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Hi Paul, thanks again for getting back on this! On 05/18/2012 03:10 PM, Paul Fox wrote: simon wrote: On 05/09/2012 05:56 PM, Paul Fox wrote: gonzalo wrote: On Wed, May 9, 2012 at 12:42 PM, Paul Foxp...@laptop.org wrote: i would much prefer that we could prevent suspend during any audio playback, rather than have to have anyone that wants to make noise do it individually. But this should be done at a lower level, right? yes, sorry -- that comment wasn't really directed at sugar. Hi Paul, can you give some background information here, why preventing the XO to fall asleep when there is audio playback is not happening as of today? And what are the steps to make this happen at a lower level than Sugar? the problem is that there's no good operating system mechanism that powerd can use to know that audio is truly in use. Ok, I see. it's possible to know that the audio device has been opened, and i have tried using that in the past. but most applications that use audio open the device once, and then leave it open. so even when they're playing nothing but silence, the device appears to be in use. OK. the solution would be to either change all the activities to close the device when it's not in use (unlikely), or create a mechanism where one can find out whether the driver is producing audible energy. (or even better -- how long it has been since it produced audible energy) i think this would be difficult. on the other hand, this issue always comes up late in a release cycle, where we don't really have time for new kernel work, and then attention fades. perhaps we can really pursue it this time. Yes, I think it would be great to analyze the low-level situation and see what is possible to sense audible energy. That would be the perfect thing to have. But of course you know better what is possible there. Agreed, there are some issues where we always do workarounds since we are late in the cycle. In general I think it is ok to do workarounds if there is as well a path forward. So even if we include a patch in 12.1.0 from Gonzalo to inhibit suspend when using tts we should have a look at the real issue and if we can not fix it in 12.1.0 try to do so in 12.2.0. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 May 2012 01:21 AM, Sascha Silbe wrote: Gonzalo Odiard godi...@sugarlabs.org writes: Using powerd-inhibit-suspend directory is how ALL the activities are working today, Quantity isn't the same as quality. That everybody is doing it doesn't make it suddenly a good idea. Quite the contrary, as platform developers we have the responsibility to take the lead and show what _best_ (not common) practice is. Activity authors can then adopt it. and how powerd is used. That's exactly what I don't like: it's specific to powerd. That's fine for downstreams to decide for themselves and use your patch (Dextrose may be interested in it, for example), but it's not a good direction for upstream to take. +1 Sascha ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel - -- Anish -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPtTyRAAoJEBoxUdDHDZVpsDEH/2/oiYk9CVsHemBDrovb4MXW eOtZfYZZGW3/E/lUD4/z1NzifZvF94KR7q53F5TOlTDuyakxcmvYU0fpSTqldD/L /xjjURk3ihyQ2da3GPYMX63V6345yPKp/yhRxbKYgugrNvQbxU8rbRJhD/v1oT2G rUcJMgBBiR7Z10m+Xls52mtuf+tE/J7cZdPdivvlUN+HTZJJt8WenBBySnxA7B5f VU0rB19WQPS21JahfhaVwcTQNRrUAAKg8L1W9Ta1EHS77eWiyGgAdUCc5uU5jAtp xi99xmzsvEOxB91uZ+T1wmbdkIZsv3jvsP2lW325uGzIauAExXoSvk64GqNKldo= =N4HZ -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
On Tue, May 15, 2012 at 4:51 PM, Sascha Silbe si...@activitycentral.comwrote: Gonzalo Odiard godi...@sugarlabs.org writes: Using powerd-inhibit-suspend directory is how ALL the activities are working today, Quantity isn't the same as quality. That everybody is doing it doesn't make it suddenly a good idea. Quite the contrary, as platform developers we have the responsibility to take the lead and show what _best_ (not common) practice is. Activity authors can then adopt it. But implementing such solution probably should be a feature and will not be accepted at this time. and how powerd is used. That's exactly what I don't like: it's specific to powerd. That's fine for downstreams to decide for themselves and use your patch (Dextrose may be interested in it, for example), but it's not a good direction for upstream to take. That is a complete nonsense to me. Probably Dextrose will accept it, and OLPC too. In what _real_ users you think when you work? Do you prefer have a bug who affect to 90% percent of our users without fix, because your imaginary users may be don't have powerd? And think one solution can be: *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.* Wake up! This is not a university project. There are real users, and we should work for them. Gonzalo Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -- Gonzalo Odiard SugarLabs Argentina ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
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 si...@activitycentral.comwrote: godi...@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
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Gonzalo Odiard godi...@sugarlabs.org writes: Using powerd-inhibit-suspend directory is how ALL the activities are working today, Quantity isn't the same as quality. That everybody is doing it doesn't make it suddenly a good idea. Quite the contrary, as platform developers we have the responsibility to take the lead and show what _best_ (not common) practice is. Activity authors can then adopt it. and how powerd is used. That's exactly what I don't like: it's specific to powerd. That's fine for downstreams to decide for themselves and use your patch (Dextrose may be interested in it, for example), but it's not a good direction for upstream to take. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ pgpKtIzUvnx6h.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
godi...@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]
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
On Thu, May 10, 2012 at 12:58 AM, James Cameron qu...@laptop.org wrote: Regarding your general approach, this is okay for the moment, since nothing else in the Sugar shell process will use it, but watch out in future. /var/run/powerd-inhibit-suspend/%s is unique by process id only. See stopwatch.git/powerd.py for a reference counted implementation that would avoid this. In my opinion a reference counted implementation should be added to the Sugar toolkit for use by activities as well as Sugar. I agree. I really was surprised we do not have other cases of inhibit suspend in sugar, probably the implementation used in stopwatch/powerd.py is better in the long run. Thanks by the review, I will send another patch. Gonzalo Reviewed-by: James Cameron qu...@laptop.org On Wed, May 09, 2012 at 02:39:02PM -0300, godi...@sugarlabs.org wrote: +def _verify_powerd_running(self): +self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK) +logging.debug(using_powerd: %d, self.using_powerd) +return self.using_powerd This function should not use the word running, since it isn't actually testing if powerd is running, it only tests if powerd inhibit directory is present. There is no need to verify that powerd is present. Just try to create or delete the files and ignore any IOError. + +def _inhibit_suspend(self): +if self.using_powerd: +flag_file_name = POWERD_INHIBIT_DIR + /%u % os.getpid() +if not os.path.exists(flag_file_name): +fd = open(flag_file_name, 'w') +logging.debug(inhibit_suspend file is %s % flag_file_name) +fd.close() This only creates the file if it does not exist, and is a potential race condition. You should just create the file, for example as done in distance.git/activity.py or stopwatch.git/powerd.py + +def _allow_suspend(self): +if self.using_powerd: +flag_file_name = POWERD_INHIBIT_DIR + /%u % os.getpid() +if os.path.exists(flag_file_name): +os.unlink(flag_file_name) +logging.debug(allow_suspend unlinking %s % flag_file_name) + Again, there is no need to check that it exists before unlinking it. The determination of flag_file_name might be placed into a common function, as done in stopwatch/powerd.py -- James Cameron http://quozl.linux.org.au/ -- Gonzalo Odiard SugarLabs Argentina ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
From: Gonzalo Odiard godi...@gmail.com
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. Is the same technique used in activities
(the code is copied from Distance activity) but we need decide
if is the right thing to do in sugar.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
v2: Remove ohmd code
v3: Implemented changes according to James review.
---
src/jarabe/model/speech.py | 43 +--
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/src/jarabe/model/speech.py b/src/jarabe/model/speech.py
index 1cb0ad4..533fec2 100644
--- a/src/jarabe/model/speech.py
+++ b/src/jarabe/model/speech.py
@@ -30,6 +30,10 @@ DEFAULT_RATE = 0
_speech_manager = None
+# directory exists if powerd is running. create a file here,
+# named after our pid, to inhibit suspend.
+POWERD_INHIBIT_DIR = '/var/run/powerd-inhibit-suspend'
+
class SpeechManager(gobject.GObject):
@@ -137,8 +141,10 @@ class _GstSpeechPlayer(gobject.GObject):
def __init__(self):
gobject.GObject.__init__(self)
self._pipeline = None
+self.using_powerd = self._verify_powerd_directory()
def restart_sound_device(self):
+self._inhibit_suspend()
if self._pipeline is None:
logging.debug('Trying to restart not initialized sound device')
return
@@ -147,6 +153,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('play')
def pause_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -154,6 +161,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('pause')
def stop_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -172,12 +180,9 @@ class _GstSpeechPlayer(gobject.GObject):
bus.connect('message', self.__pipe_message_cb)
def __pipe_message_cb(self, bus, message):
-if message.type == gst.MESSAGE_EOS:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
-elif message.type == gst.MESSAGE_ERROR:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
+if message.type == gst.MESSAGE_EOS or \
+message.type == gst.MESSAGE_ERROR:
+self.stop_sound_device()
def speak(self, pitch, rate, voice_name, text):
# TODO workaround for http://bugs.sugarlabs.org/ticket/1801
@@ -223,6 +228,32 @@ class _GstSpeechPlayer(gobject.GObject):
locale, best)
return best
+def _verify_powerd_directory(self):
+using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK)
+logging.debug(using_powerd: %d, using_powerd)
+return using_powerd
+
+def _inhibit_suspend(self):
+if self.using_powerd:
+flag_file_name = self._powerd_flag_name()
+try:
+file(flag_file_name, 'w').write('')
+logging.debug(inhibit_suspend file is %s, flag_file_name)
+except IOError:
+pass
+
+def _allow_suspend(self):
+if self.using_powerd:
+flag_file_name = self._powerd_flag_name()
+try:
+os.unlink(flag_file_name)
+logging.debug(allow_suspend unlinking %s, flag_file_name)
+except IOError:
+pass
+
+def _powerd_flag_name(self):
+return POWERD_INHIBIT_DIR + /%u % os.getpid()
+
def get_speech_manager():
global _speech_manager
--
1.7.10.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Reviewed-by: James Cameron qu...@laptop.org -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
From: Gonzalo Odiard godi...@gmail.com
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. Is the same technique used in activities
(the code is copied from Distance activity) but we need decide
if is the right thing to do in sugar.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
src/jarabe/model/speech.py | 69
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/src/jarabe/model/speech.py b/src/jarabe/model/speech.py
index 1cb0ad4..24f4152 100644
--- a/src/jarabe/model/speech.py
+++ b/src/jarabe/model/speech.py
@@ -21,6 +21,7 @@ import gconf
import gst
import gtk
import gobject
+import dbus
DEFAULT_PITCH = 0
@@ -30,6 +31,10 @@ DEFAULT_RATE = 0
_speech_manager = None
+# directory exists if powerd is running. create a file here,
+# named after our pid, to inhibit suspend.
+POWERD_INHIBIT_DIR = '/var/run/powerd-inhibit-suspend'
+
class SpeechManager(gobject.GObject):
@@ -138,7 +143,20 @@ class _GstSpeechPlayer(gobject.GObject):
gobject.GObject.__init__(self)
self._pipeline = None
+self.using_powerd = False
+if not self.powerd_running():
+try:
+bus = dbus.SystemBus()
+proxy = bus.get_object('org.freedesktop.ohm',
+ '/org/freedesktop/ohm/Keystore')
+self.ohm_keystore = dbus.Interface(
+proxy, 'org.freedesktop.ohm.Keystore')
+except dbus.DBusException, e:
+logging.warning(Error setting OHM inhibit: %s, e)
+self.ohm_keystore = None
+
def restart_sound_device(self):
+self._inhibit_suspend()
if self._pipeline is None:
logging.debug('Trying to restart not initialized sound device')
return
@@ -147,6 +165,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('play')
def pause_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -154,6 +173,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('pause')
def stop_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -172,12 +192,9 @@ class _GstSpeechPlayer(gobject.GObject):
bus.connect('message', self.__pipe_message_cb)
def __pipe_message_cb(self, bus, message):
-if message.type == gst.MESSAGE_EOS:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
-elif message.type == gst.MESSAGE_ERROR:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
+if message.type == gst.MESSAGE_EOS or \
+message.type == gst.MESSAGE_ERROR:
+self.stop_sound_device()
def speak(self, pitch, rate, voice_name, text):
# TODO workaround for http://bugs.sugarlabs.org/ticket/1801
@@ -223,6 +240,46 @@ class _GstSpeechPlayer(gobject.GObject):
locale, best)
return best
+def powerd_running(self):
+self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK)
+logging.debug(using_powerd: %d, self.using_powerd)
+return self.using_powerd
+
+def _inhibit_suspend(self):
+if self.using_powerd:
+fd = open(POWERD_INHIBIT_DIR + /%u % os.getpid(), 'w')
+logging.debug(inhibit_suspend file is %s % \
+ POWERD_INHIBIT_DIR + /%u % os.getpid())
+fd.close()
+return True
+
+if self.ohm_keystore is not None:
+try:
+self.ohm_keystore.SetKey('suspend.inhibit', 1)
+return self.ohm_keystore.GetKey('suspend.inhibit')
+except dbus.exceptions.DBusException:
+logging.warning(failed to inhibit suspend)
+return False
+else:
+return False
+
+def _allow_suspend(self):
+if self.using_powerd:
+os.unlink(POWERD_INHIBIT_DIR + /%u % os.getpid())
+logging.debug(allow_suspend unlinking %s % \
+ POWERD_INHIBIT_DIR + /%u % os.getpid())
+return True
+
+if self.ohm_keystore is not None:
+try:
+self.ohm_keystore.SetKey('suspend.inhibit', 0)
+return self.ohm_keystore.GetKey('suspend.inhibit')
+except dbus.exceptions.DBusException:
+logging.error(failed to allow suspend)
+return False
+else:
+return False
+
def get_speech_manager():
global _speech_manager
--
1.7.10.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
i would much prefer that we could prevent suspend during any
audio playback, rather than have to have anyone that wants
to make noise do it individually.
that being said, you can eliminate any of the code below that deals
with the ohm keystore. if we move away from powerd, it likely won't
be back to ohmd.
paul
godi...@sugarlabs.org wrote:
From: Gonzalo Odiard godi...@gmail.com
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. Is the same technique used in activities
(the code is copied from Distance activity) but we need decide
if is the right thing to do in sugar.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
src/jarabe/model/speech.py | 69
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/src/jarabe/model/speech.py b/src/jarabe/model/speech.py
index 1cb0ad4..24f4152 100644
--- a/src/jarabe/model/speech.py
+++ b/src/jarabe/model/speech.py
@@ -21,6 +21,7 @@ import gconf
import gst
import gtk
import gobject
+import dbus
DEFAULT_PITCH = 0
@@ -30,6 +31,10 @@ DEFAULT_RATE = 0
_speech_manager = None
+# directory exists if powerd is running. create a file here,
+# named after our pid, to inhibit suspend.
+POWERD_INHIBIT_DIR = '/var/run/powerd-inhibit-suspend'
+
class SpeechManager(gobject.GObject):
@@ -138,7 +143,20 @@ class _GstSpeechPlayer(gobject.GObject):
gobject.GObject.__init__(self)
self._pipeline = None
+self.using_powerd = False
+if not self.powerd_running():
+try:
+bus = dbus.SystemBus()
+proxy = bus.get_object('org.freedesktop.ohm',
+ '/org/freedesktop/ohm/Keystore')
+self.ohm_keystore = dbus.Interface(
+proxy, 'org.freedesktop.ohm.Keystore')
+except dbus.DBusException, e:
+logging.warning(Error setting OHM inhibit: %s, e)
+self.ohm_keystore = None
+
def restart_sound_device(self):
+self._inhibit_suspend()
if self._pipeline is None:
logging.debug('Trying to restart not initialized sound device')
return
@@ -147,6 +165,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('play')
def pause_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -154,6 +173,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('pause')
def stop_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -172,12 +192,9 @@ class _GstSpeechPlayer(gobject.GObject):
bus.connect('message', self.__pipe_message_cb)
def __pipe_message_cb(self, bus, message):
-if message.type == gst.MESSAGE_EOS:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
-elif message.type == gst.MESSAGE_ERROR:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
+if message.type == gst.MESSAGE_EOS or \
+message.type == gst.MESSAGE_ERROR:
+self.stop_sound_device()
def speak(self, pitch, rate, voice_name, text):
# TODO workaround for http://bugs.sugarlabs.org/ticket/1801
@@ -223,6 +240,46 @@ class _GstSpeechPlayer(gobject.GObject):
locale, best)
return best
+def powerd_running(self):
+self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK)
+logging.debug(using_powerd: %d, self.using_powerd)
+return self.using_powerd
+
+def _inhibit_suspend(self):
+if self.using_powerd:
+fd = open(POWERD_INHIBIT_DIR + /%u % os.getpid(), 'w')
+logging.debug(inhibit_suspend file is %s % \
+ POWERD_INHIBIT_DIR + /%u % os.getpid())
+fd.close()
+return True
+
+if self.ohm_keystore is not None:
+try:
+self.ohm_keystore.SetKey('suspend.inhibit', 1)
+return self.ohm_keystore.GetKey('suspend.inhibit')
+except dbus.exceptions.DBusException:
+logging.warning(failed to inhibit suspend)
+return False
+else:
+return False
+
+def _allow_suspend(self):
+if self.using_powerd:
+os.unlink(POWERD_INHIBIT_DIR + /%u % os.getpid())
+logging.debug(allow_suspend unlinking %s % \
+ POWERD_INHIBIT_DIR + /%u % os.getpid())
+return True
+
+if self.ohm_keystore is not None:
+
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
On Wed, May 9, 2012 at 12:42 PM, Paul Fox p...@laptop.org wrote:
i would much prefer that we could prevent suspend during any
audio playback, rather than have to have anyone that wants
to make noise do it individually.
But this should be done at a lower level, right?
that being said, you can eliminate any of the code below that deals
with the ohm keystore. if we move away from powerd, it likely won't
be back to ohmd.
Thanks. I was not sure if needed.
Gonzalo
paul
godi...@sugarlabs.org wrote:
From: Gonzalo Odiard godi...@gmail.com
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. Is the same technique used in activities
(the code is copied from Distance activity) but we need decide
if is the right thing to do in sugar.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
src/jarabe/model/speech.py | 69
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/src/jarabe/model/speech.py b/src/jarabe/model/speech.py
index 1cb0ad4..24f4152 100644
--- a/src/jarabe/model/speech.py
+++ b/src/jarabe/model/speech.py
@@ -21,6 +21,7 @@ import gconf
import gst
import gtk
import gobject
+import dbus
DEFAULT_PITCH = 0
@@ -30,6 +31,10 @@ DEFAULT_RATE = 0
_speech_manager = None
+# directory exists if powerd is running. create a file here,
+# named after our pid, to inhibit suspend.
+POWERD_INHIBIT_DIR = '/var/run/powerd-inhibit-suspend'
+
class SpeechManager(gobject.GObject):
@@ -138,7 +143,20 @@ class _GstSpeechPlayer(gobject.GObject):
gobject.GObject.__init__(self)
self._pipeline = None
+self.using_powerd = False
+if not self.powerd_running():
+try:
+bus = dbus.SystemBus()
+proxy = bus.get_object('org.freedesktop.ohm',
+ '/org/freedesktop/ohm/Keystore')
+self.ohm_keystore = dbus.Interface(
+proxy, 'org.freedesktop.ohm.Keystore')
+except dbus.DBusException, e:
+logging.warning(Error setting OHM inhibit: %s, e)
+self.ohm_keystore = None
+
def restart_sound_device(self):
+self._inhibit_suspend()
if self._pipeline is None:
logging.debug('Trying to restart not initialized sound
device')
return
@@ -147,6 +165,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('play')
def pause_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -154,6 +173,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('pause')
def stop_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -172,12 +192,9 @@ class _GstSpeechPlayer(gobject.GObject):
bus.connect('message', self.__pipe_message_cb)
def __pipe_message_cb(self, bus, message):
-if message.type == gst.MESSAGE_EOS:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
-elif message.type == gst.MESSAGE_ERROR:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
+if message.type == gst.MESSAGE_EOS or \
+message.type == gst.MESSAGE_ERROR:
+self.stop_sound_device()
def speak(self, pitch, rate, voice_name, text):
# TODO workaround for http://bugs.sugarlabs.org/ticket/1801
@@ -223,6 +240,46 @@ class _GstSpeechPlayer(gobject.GObject):
locale, best)
return best
+def powerd_running(self):
+self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK)
+logging.debug(using_powerd: %d, self.using_powerd)
+return self.using_powerd
+
+def _inhibit_suspend(self):
+if self.using_powerd:
+fd = open(POWERD_INHIBIT_DIR + /%u % os.getpid(), 'w')
+logging.debug(inhibit_suspend file is %s % \
+ POWERD_INHIBIT_DIR + /%u %
os.getpid())
+fd.close()
+return True
+
+if self.ohm_keystore is not None:
+try:
+self.ohm_keystore.SetKey('suspend.inhibit', 1)
+return self.ohm_keystore.GetKey('suspend.inhibit')
+except dbus.exceptions.DBusException:
+logging.warning(failed to inhibit suspend)
+return False
+else:
+return False
+
+def _allow_suspend(self):
+if self.using_powerd:
+
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
gonzalo wrote:
On Wed, May 9, 2012 at 12:42 PM, Paul Fox p...@laptop.org wrote:
i would much prefer that we could prevent suspend during any
audio playback, rather than have to have anyone that wants
to make noise do it individually.
But this should be done at a lower level, right?
yes, sorry -- that comment wasn't really directed at sugar.
that being said, you can eliminate any of the code below that deals
with the ohm keystore. if we move away from powerd, it likely won't
be back to ohmd.
Thanks. I was not sure if needed.
i'd say that code supporting ohm can be removed anywhere you happen
to find it, these days.
paul
Gonzalo
paul
godi...@sugarlabs.org wrote:
From: Gonzalo Odiard godi...@gmail.com
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. Is the same technique used in activities
(the code is copied from Distance activity) but we need decide
if is the right thing to do in sugar.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
src/jarabe/model/speech.py | 69
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/src/jarabe/model/speech.py b/src/jarabe/model/speech.py
index 1cb0ad4..24f4152 100644
--- a/src/jarabe/model/speech.py
+++ b/src/jarabe/model/speech.py
@@ -21,6 +21,7 @@ import gconf
import gst
import gtk
import gobject
+import dbus
DEFAULT_PITCH = 0
@@ -30,6 +31,10 @@ DEFAULT_RATE = 0
_speech_manager = None
+# directory exists if powerd is running. create a file here,
+# named after our pid, to inhibit suspend.
+POWERD_INHIBIT_DIR = '/var/run/powerd-inhibit-suspend'
+
class SpeechManager(gobject.GObject):
@@ -138,7 +143,20 @@ class _GstSpeechPlayer(gobject.GObject):
gobject.GObject.__init__(self)
self._pipeline = None
+self.using_powerd = False
+if not self.powerd_running():
+try:
+bus = dbus.SystemBus()
+proxy = bus.get_object('org.freedesktop.ohm',
+ '/org/freedesktop/ohm/Keystore')
+self.ohm_keystore = dbus.Interface(
+proxy, 'org.freedesktop.ohm.Keystore')
+except dbus.DBusException, e:
+logging.warning(Error setting OHM inhibit: %s, e)
+self.ohm_keystore = None
+
def restart_sound_device(self):
+self._inhibit_suspend()
if self._pipeline is None:
logging.debug('Trying to restart not initialized sound
device')
return
@@ -147,6 +165,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('play')
def pause_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -154,6 +173,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('pause')
def stop_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -172,12 +192,9 @@ class _GstSpeechPlayer(gobject.GObject):
bus.connect('message', self.__pipe_message_cb)
def __pipe_message_cb(self, bus, message):
-if message.type == gst.MESSAGE_EOS:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
-elif message.type == gst.MESSAGE_ERROR:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
+if message.type == gst.MESSAGE_EOS or \
+message.type == gst.MESSAGE_ERROR:
+self.stop_sound_device()
def speak(self, pitch, rate, voice_name, text):
# TODO workaround for http://bugs.sugarlabs.org/ticket/1801
@@ -223,6 +240,46 @@ class _GstSpeechPlayer(gobject.GObject):
locale, best)
return best
+def powerd_running(self):
+self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK)
+logging.debug(using_powerd: %d, self.using_powerd)
+return self.using_powerd
+
+def _inhibit_suspend(self):
+if self.using_powerd:
+fd = open(POWERD_INHIBIT_DIR + /%u % os.getpid(), 'w')
+logging.debug(inhibit_suspend file is %s % \
+ POWERD_INHIBIT_DIR + /%u %
os.getpid())
+fd.close()
+return True
+
+if self.ohm_keystore is not None:
+try:
[Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
From: Gonzalo Odiard godi...@gmail.com
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. Is the same technique used in activities
(the code is copied from Distance activity) but we need decide
if is the right thing to do in sugar.
Signed-off-by: Gonzalo Odiard gonz...@laptop.org
---
v2: Remove ohmd code
---
src/jarabe/model/speech.py | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/src/jarabe/model/speech.py b/src/jarabe/model/speech.py
index 1cb0ad4..f07171c 100644
--- a/src/jarabe/model/speech.py
+++ b/src/jarabe/model/speech.py
@@ -30,6 +30,10 @@ DEFAULT_RATE = 0
_speech_manager = None
+# directory exists if powerd is running. create a file here,
+# named after our pid, to inhibit suspend.
+POWERD_INHIBIT_DIR = '/var/run/powerd-inhibit-suspend'
+
class SpeechManager(gobject.GObject):
@@ -137,8 +141,10 @@ class _GstSpeechPlayer(gobject.GObject):
def __init__(self):
gobject.GObject.__init__(self)
self._pipeline = None
+self.using_powerd = self._verify_powerd_running()
def restart_sound_device(self):
+self._inhibit_suspend()
if self._pipeline is None:
logging.debug('Trying to restart not initialized sound device')
return
@@ -147,6 +153,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('play')
def pause_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -154,6 +161,7 @@ class _GstSpeechPlayer(gobject.GObject):
self.emit('pause')
def stop_sound_device(self):
+self._allow_suspend()
if self._pipeline is None:
return
@@ -172,12 +180,9 @@ class _GstSpeechPlayer(gobject.GObject):
bus.connect('message', self.__pipe_message_cb)
def __pipe_message_cb(self, bus, message):
-if message.type == gst.MESSAGE_EOS:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
-elif message.type == gst.MESSAGE_ERROR:
-self._pipeline.set_state(gst.STATE_NULL)
-self.emit('stop')
+if message.type == gst.MESSAGE_EOS or \
+message.type == gst.MESSAGE_ERROR:
+self.stop_sound_device()
def speak(self, pitch, rate, voice_name, text):
# TODO workaround for http://bugs.sugarlabs.org/ticket/1801
@@ -223,6 +228,26 @@ class _GstSpeechPlayer(gobject.GObject):
locale, best)
return best
+def _verify_powerd_running(self):
+self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK)
+logging.debug(using_powerd: %d, self.using_powerd)
+return self.using_powerd
+
+def _inhibit_suspend(self):
+if self.using_powerd:
+flag_file_name = POWERD_INHIBIT_DIR + /%u % os.getpid()
+if not os.path.exists(flag_file_name):
+fd = open(flag_file_name, 'w')
+logging.debug(inhibit_suspend file is %s % flag_file_name)
+fd.close()
+
+def _allow_suspend(self):
+if self.using_powerd:
+flag_file_name = POWERD_INHIBIT_DIR + /%u % os.getpid()
+if os.path.exists(flag_file_name):
+os.unlink(flag_file_name)
+logging.debug(allow_suspend unlinking %s % flag_file_name)
+
def get_speech_manager():
global _speech_manager
--
1.7.10.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830
Regarding your general approach, this is okay for the moment, since nothing else in the Sugar shell process will use it, but watch out in future. /var/run/powerd-inhibit-suspend/%s is unique by process id only. See stopwatch.git/powerd.py for a reference counted implementation that would avoid this. In my opinion a reference counted implementation should be added to the Sugar toolkit for use by activities as well as Sugar. Reviewed-by: James Cameron qu...@laptop.org On Wed, May 09, 2012 at 02:39:02PM -0300, godi...@sugarlabs.org wrote: +def _verify_powerd_running(self): +self.using_powerd = os.access(POWERD_INHIBIT_DIR, os.W_OK) +logging.debug(using_powerd: %d, self.using_powerd) +return self.using_powerd This function should not use the word running, since it isn't actually testing if powerd is running, it only tests if powerd inhibit directory is present. There is no need to verify that powerd is present. Just try to create or delete the files and ignore any IOError. + +def _inhibit_suspend(self): +if self.using_powerd: +flag_file_name = POWERD_INHIBIT_DIR + /%u % os.getpid() +if not os.path.exists(flag_file_name): +fd = open(flag_file_name, 'w') +logging.debug(inhibit_suspend file is %s % flag_file_name) +fd.close() This only creates the file if it does not exist, and is a potential race condition. You should just create the file, for example as done in distance.git/activity.py or stopwatch.git/powerd.py + +def _allow_suspend(self): +if self.using_powerd: +flag_file_name = POWERD_INHIBIT_DIR + /%u % os.getpid() +if os.path.exists(flag_file_name): +os.unlink(flag_file_name) +logging.debug(allow_suspend unlinking %s % flag_file_name) + Again, there is no need to check that it exists before unlinking it. The determination of flag_file_name might be placed into a common function, as done in stopwatch/powerd.py -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
