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

[Samuel Greenfeld]

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 <simon at schampijer.de>wrote:

> 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 Silbe<silbe at activitycentral.**com<silbe at activitycentral.com>
>> >wrote:
>>
>>  Gonzalo Odiard<godiard at 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 at lists.sugarlabs.**org <Sugar-devel at lists.sugarlabs.org>
> http://lists.sugarlabs.org/**listinfo/sugar-devel<http://lists.sugarlabs.org/listinfo/sugar-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120518/b0e05f12/attachment-0001.html>