[maemo-developers] [maemo-developers] Maemo alarms ==> retutime

[From: Nils Faerber]

Weinehall David (Nokia-M/Tampere) schrieb:
> On mån, 2006-07-31 at 13:01 +0200, ext Nils Faerber wrote:
> [snip]
>> Well, that is just half of the game, I am afraid.
>> Google indeed points to a post by Jason Mills:
>> http://maemo.org/pipermail/maemo-developers/2006-January/002437.html
>> In this post Jason also sais:
>> "... 4) The osso_alarm and osso_notifier daemons are missing at least
>> from the 2005.51 Nokia build. ..."
>> I think what Chris, me and others are really looking for is the alarm
>> framework for application notification, not the mere RTC alarm.
> There is no alarm framework

Uff!
I would have expected such framework after the longish discussions on
the mailinglist some time ago (effectively more than half a year ago).

>> There must be, at least I hope, a clean way to
>>  - set an alarm by an application
> No clean way.  Retutime is the only way to set alarm,
> with all its limitations.

And there are quite some ... limitations I mean ...

>>  - get notified when alarm is reached
> Nope.

How does the alarm clock handle this then?
It plays a sound when the alarm time is reached.
Or is it simply so that the device will wake-up when the alarm is
reached and each application checks on its own to see if alarm time has
arrived? That would mean to kind of poll on the time which is nasty.

>>  - remove a pending alarm
> Retutime.
>>  - do not conflict with other alarms (in case two aplications set alarms)
> That's easy, but not pretty.  Since the only available means of setting
> alarms are through retutime, and retutime in turn depends on the
> hardware capabilities only, alarms are max 24h into the future,
> and only one can be set.

Well, but if you have two applications and both set an alarm, then
consequently one alarm is lost, isn't it? The application that lost its
alarm would have to set it again. But how does it know that its alarm
got evaporated?
And even worse since the alarms can only be set <24h in advance does
that indeed mean that every application that wants to use alarms would
have to handle this nasty 24h hopping on its own? I.e. if the alarm is
more than 24h in the future then set an alarm for <24h, then check again
and set a new alarm until it is less than 24h away?

That is messy, indeed.

And besides why didn't RETU get a pretty normal RTC device driver :) ?
That would have made things a lot easier...

> Regards: David
Cheers
  nils faerber

-- 
kernel concepts          Tel: +49-271-771091-12
Dreisbachstr. 24         Fax: +49-271-771091-19
D-57250 Netphen          Mob: +49-176-21024535
--