Ompower
From Openmoko
(First edition, not proof read) |
(-cat) |
||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 2: | Line 2: | ||
== How does it work? == | == How does it work? == | ||
| + | ''ompower'' manages suspension, but does not enforce it. It does this by a request mechanism. Applications may request either suspension or power-on. | ||
| + | As long as requests for "power on" are active, the phone will not suspend. If no such requests are active (all "power-on" requests are removed or no requests have been made so far) ''ompower'' will suspend the phone (via calling ''apm -s''), if "power-off" requests are active. The "power-off" requests are usually issued by some application such as [[Illume]]. If neither "power-on" and "power-off" requests are in ''ompower''s queue, nothing will happen. | ||
| + | |||
| + | === List available resources === | ||
| + | |||
| + | To get a list of the available resources (at the time of writing, there is only ''cpu'', nothing for backlight, yet...): | ||
| + | dbus-send --system --print-reply --dest=org.openmoko.Power / org.openmoko.Power.Core.ListResources | ||
| + | |||
| + | === List current state === | ||
| + | |||
| + | To get the current state: | ||
| + | dbus-send --system --print-reply --dest=org.openmoko.Power / org.openmoko.Power.Core.GetResourceState string:cpu | ||
| + | |||
| + | There seems to be no way (yet) to get a list of the 'my-system-names' that have requested a resource state. | ||
| + | |||
| + | === Avoid suspension === | ||
If an application wants to tell the phone that it should not suspend, it should send a dbus message. This message could be send by dbus API. In case of a shell script, sending dbus messages could be achieved by the command ''dbus-send'': | If an application wants to tell the phone that it should not suspend, it should send a dbus message. This message could be send by dbus API. In case of a shell script, sending dbus messages could be achieved by the command ''dbus-send'': | ||
| − | dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RequestResourceState | + | dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RequestResourceState \ |
string:cpu string:my-system-name string:on | string:cpu string:my-system-name string:on | ||
If the application then is in a state it could be suspendet, it should send: | If the application then is in a state it could be suspendet, it should send: | ||
| − | dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RemoveRequestedResourceState | + | dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RemoveRequestedResourceState \ |
string:cpu string:my-system-name | string:cpu string:my-system-name | ||
"my-system-name" is an identifier telling dbus the requesting source. In case of tangogps, this could be "application-tangogps". | "my-system-name" is an identifier telling dbus the requesting source. In case of tangogps, this could be "application-tangogps". | ||
| − | + | === Requesting suspension === | |
| − | + | The daemon is also able to request a suspend by explicitely requesting a "power off": | |
| + | dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RequestResourceState \ | ||
| + | string:cpu string:my-system-name string:off | ||
== Ticket == | == Ticket == | ||
For further reading see Ticket [https://docs.openmoko.org/trac/ticket/2008 #2008 (Do not suspend when certain apps are running)]. That ticket was the reason for writing this article. | For further reading see Ticket [https://docs.openmoko.org/trac/ticket/2008 #2008 (Do not suspend when certain apps are running)]. That ticket was the reason for writing this article. | ||
| − | |||
| − | |||
== Source == | == Source == | ||
| Line 24: | Line 40: | ||
http://svn.openmoko.org/developers/raster/ompower/ | http://svn.openmoko.org/developers/raster/ompower/ | ||
| + | == Strategy == | ||
| + | |||
| + | What ompower does is actually what screensavers usually do. So it might be worth thinking about adding the extra features or options (e.g. dbus-control) to (an) existing screensaver project(s). In contrast, a decision in favour of a new screensaver project would mean extra work to get missing features (e.g. locking with password) that are already implemented in existing screensavers. | ||
| − | [[Category: | + | [[Category:Battery]] |
Latest revision as of 09:46, 19 July 2009
ompower is a suspend handling daemon talking dbus installed by default since Om 2008.8. It is responsible for triggering or aborting suspension of your phone. Applications send dbus messages which are evaluated by ompower. This may be used, for example, to abort suspending the phone while doing GPS tracking.
Contents |
[edit] How does it work?
ompower manages suspension, but does not enforce it. It does this by a request mechanism. Applications may request either suspension or power-on. As long as requests for "power on" are active, the phone will not suspend. If no such requests are active (all "power-on" requests are removed or no requests have been made so far) ompower will suspend the phone (via calling apm -s), if "power-off" requests are active. The "power-off" requests are usually issued by some application such as Illume. If neither "power-on" and "power-off" requests are in ompowers queue, nothing will happen.
[edit] List available resources
To get a list of the available resources (at the time of writing, there is only cpu, nothing for backlight, yet...):
dbus-send --system --print-reply --dest=org.openmoko.Power / org.openmoko.Power.Core.ListResources
[edit] List current state
To get the current state:
dbus-send --system --print-reply --dest=org.openmoko.Power / org.openmoko.Power.Core.GetResourceState string:cpu
There seems to be no way (yet) to get a list of the 'my-system-names' that have requested a resource state.
[edit] Avoid suspension
If an application wants to tell the phone that it should not suspend, it should send a dbus message. This message could be send by dbus API. In case of a shell script, sending dbus messages could be achieved by the command dbus-send:
dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RequestResourceState \ string:cpu string:my-system-name string:on
If the application then is in a state it could be suspendet, it should send:
dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RemoveRequestedResourceState \ string:cpu string:my-system-name
"my-system-name" is an identifier telling dbus the requesting source. In case of tangogps, this could be "application-tangogps".
[edit] Requesting suspension
The daemon is also able to request a suspend by explicitely requesting a "power off":
dbus-send --system --dest=org.openmoko.Power / org.openmoko.Power.Core.RequestResourceState \ string:cpu string:my-system-name string:off
[edit] Ticket
For further reading see Ticket #2008 (Do not suspend when certain apps are running). That ticket was the reason for writing this article.
[edit] Source
You can fetch the source here: http://svn.openmoko.org/developers/raster/ompower/
[edit] Strategy
What ompower does is actually what screensavers usually do. So it might be worth thinking about adding the extra features or options (e.g. dbus-control) to (an) existing screensaver project(s). In contrast, a decision in favour of a new screensaver project would mean extra work to get missing features (e.g. locking with password) that are already implemented in existing screensavers.
