Power manager specification... (request for comments).

[Mike C. Fletcher]

Walter Bender wrote:
> Lets please be careful not to over-engineer. While Mike makes good
> points, we have this wonderful human social network we can depend upon
> as well. E.g., If I am downloading something from your machine, I can
> ask you to hold on a second until I finish. Let's take advantage of
> the fact that the kids are in the same community/school most of the
> time and not worry so much about corner cases until we have some more
> breathing room.
>   
Perhaps I was unclear, I was referring to another program *on the same 
machine* needing the machine to remain active in order to complete a 
task.  That is, things such as:

    * playing music in the background while you read
    * downloading a file from the school server which you need for
      homework while you are reading the assignment/textbook
    * recording an audio stream while you are taking notes in write
      (i.e. interviewing someone)
    * upgrading the OS/downloading updates while you are working in class

that is, all single-user on a single-machine use cases.  No social 
networks involved.  These are all fairly common use cases.  We see the 
same basic "inhibit_suspend" operation in media-players on Linux or 
Windows wrt screen savers.  You don't want your machine going to sleep 
in the middle of recording your interview, so the recording activity 
needs a way to say "hey, I'm working, don't go to sleep right now" 
(assume we've got a signed activity that can do background record for a 
moment).

I'm not saying that the implementation needs to be there today, I'm just 
saying that we likely need to eventually move toward an implementation 
that uses need-based signaling rather than direct manipulation of the 
whole computer state by any activity.  Something as simple as a 
decorator icon on the home view, (e.g. a bed with a circle-plus-slash 
over it for western audiences) should be sufficient to let the user know 
which activity is inhibiting suspension.

Hope that's clearer,
Mike
...
>> On the original topic of the thread (what the power manager should do):
>>
>>    I'm guessing eventually we'll want some of the logic currently in
>>    the read activity to migrate into HardwareManager.  That is, allow
>>    for signaling "inhibit_suspend( )" and "allow_suspend()"[3], rather
>>    than directly setting suspend, such that a given activity can
>>    declare that it must be allowed to continue processing in the
>>    back-end.  Then you'd want something like "suggest_suspend()" so
>>    that a foreground activity can tell the system "hey, I don't expect
>>    to do anything for a second or two, if no-one objects, feel free to
>>    suspend".
>>
>>     From there, a second level does a suggest-suspend from Sugar (or
>>    whoever) on no-cpu, no-network (other than the autonomous routing),
>>    no-input, for a given period.  No opinion on where/how to put that.
>>
>>    HardwareManager should likely send dbus events so that activities
>>    can watch for resume, suggested-suspend, or what have you and adjust
>>    behaviour accordingly.  Example usage scenario: switch a per-second
>>    clock-updating timer to a per-minute timer.
>>
>> Hope this helps,
>> Mike
>>
>> [1]
>> http://dev.laptop.org/git.do?p=projects/read-activity;a=blob;f=readactivity.py;h=3eeb858cc5ea1dc67a60faee90628100479509be;hb=HEAD
>> [2]
>> http://dev.laptop.org/git.do?p=hardware-manager;a=blob;f=hardwaremanager.py;h=3154b17553621cc41fa947cbff2756372e6e37ec;hb=HEAD
>> [3] with allow-suspend happening automatically after a short-ish timeout
>> if the activity doesn't re-assert the inhibition
>>     
-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com