Wishlist/Alarm daemon

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Implementation Recommendations)
 
(12 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
{{Wishlist}}
 
== Overview ==
 
== Overview ==
 
The alarm daemon provides an interface for applications to register times at which an application needs to do a specific task.
 
The alarm daemon provides an interface for applications to register times at which an application needs to do a specific task.
Line 21: Line 22:
 
* If the device is powering down during the alarm we might miss the RTC alarm. Maybe we should just move the alarm time back a minute if we are powering down and the alarm is near?
 
* If the device is powering down during the alarm we might miss the RTC alarm. Maybe we should just move the alarm time back a minute if we are powering down and the alarm is near?
 
* What do we do if the application is already running?
 
* What do we do if the application is already running?
 +
 +
== Time sources ==
 +
 +
An alarm daemon can not operate without accurate time. We have a number of possible time sources:
 +
 +
=== RTC ===
 +
 +
* view: sudo hwclock
 +
* set from system time: sudo hwclock --systohc
 +
* note that ioctl to /dev/rtc can be used to configure wakeup from suspend at a given time (see e.g. fso-frameworkd source code on how this can be done).
 +
 +
=== GPS ===
 +
 +
* view: echo d | netcat -w1 localhost gpsd
 +
 +
=== GSM operator time ===
 +
 +
* It is not known how this can be accessed
 +
 +
=== Other sources ===
 +
 +
* If you never suspend your phone then the system time could be used but this is not very practical.
 +
* Does the GSM chip have its own clock (it is a full-blown ARM afterall)?
  
 
== Questions and Answers ==
 
== Questions and Answers ==
 
(None)
 
(None)
 +
 +
[[Category:Middleware]]

Latest revision as of 19:00, 12 March 2010

Wishes warning! This article or section documents one or more OpenMoko Wish List items, the features described here may or may not be implemented in the future.

Contents

[edit] Overview

The alarm daemon provides an interface for applications to register times at which an application needs to do a specific task.

[edit] Usage Cases

  • An alarm should turn on the phone if needed
  • I want to specify relative and absolute times (i.e. in 5 hours, on May 1st 2007, 2:00pm)

[edit] Constraints

[edit] Architectural Details

The alarm daemon will probably be part of neod since it will need to set the RTC alarm for the next event. The interface for the applications is exposed via dbus.

[edit] Implementation Recommendations

Maemo is using alarmd (howto). We should see if we can modify their approach to fit our needs. We don't want to have to many different solutions to a similar problem, but rather cooperate.

At start neod will have to query the next event in eds (to determine when the next wakeup has to occur). If a new event is added eds will broadcast the change through dbus.

Applications will (de-)register for a specific time at which the alarm daemon (neod) will call the application with a special command line parameter to reflect that the application has been called for an alarm.

[edit] Unresolved Issues

  • If the device is powering down during the alarm we might miss the RTC alarm. Maybe we should just move the alarm time back a minute if we are powering down and the alarm is near?
  • What do we do if the application is already running?

[edit] Time sources

An alarm daemon can not operate without accurate time. We have a number of possible time sources:

[edit] RTC

  • view: sudo hwclock
  • set from system time: sudo hwclock --systohc
  • note that ioctl to /dev/rtc can be used to configure wakeup from suspend at a given time (see e.g. fso-frameworkd source code on how this can be done).

[edit] GPS

  • view: echo d | netcat -w1 localhost gpsd

[edit] GSM operator time

  • It is not known how this can be accessed

[edit] Other sources

  • If you never suspend your phone then the system time could be used but this is not very practical.
  • Does the GSM chip have its own clock (it is a full-blown ARM afterall)?

[edit] Questions and Answers

(None)

Personal tools

Overview

The alarm daemon provides an interface for applications to register times at which an application needs to do a specific task.

Usage Cases

  • An alarm should turn on the phone if needed
  • I want to specify relative and absolute times (i.e. in 5 hours, on May 1st 2007, 2:00pm)

Constraints

Architectural Details

The alarm daemon will probably be part of neod since it will need to set the RTC alarm for the next event. The interface for the applications is exposed via dbus.

Implementation Recommendations

Maemo is using alarmd (howto). We should see if we can modify their approach to fit our needs. We don't want to have to many different solutions to a similar problem, but rather cooperate.

At start neod will have to query the next event in eds (to determine when the next wakeup has to occur). If a new event is added eds will broadcast the change through dbus.

Applications will (de-)register for a specific time at which the alarm daemon (neod) will call the application with a special command line parameter to reflect that the application has been called for an alarm.

Unresolved Issues

  • If the device is powering down during the alarm we might miss the RTC alarm. Maybe we should just move the alarm time back a minute if we are powering down and the alarm is near?
  • What do we do if the application is already running?

Questions and Answers

(None)