On Thu, 2006-01-12 at 10:55 +0200, Devesh Kothari wrote: > Great this is feedback I was looking for. Now just to bring on same page > again > > First the end user use cases > 1. An application e.g Calender or task wanting to alart and notify the > user of scheduled events. This notification should have a certain > accepted granularity and delivery promise > - Resolution of most end user use case can live with 1 minutes > granularity [IMHO] > - Events must be delivered regardless of the device state e.g sleep, > deep sleep or poweroff state [but with battery plugged in] > - User should be able to schedule Events/Notification in any future > time e.g my mothers birthday which is 8 months away. Base assumptions: -since the Retu rtc has a minimum resolution of 1s, that's our minimum error: +/- 1s -only whole days are subtracted from the Retu days counter, so that no skew is introduced in the timeline by silent resets of the seconds counter
Then the time daemon would schedule the wakeup from poweroff early enough (i.e. 1 minute earlier) and then deliver the "alarm" to the user, with an almost arbitrary high time resolution, because it would use a fine-grained timer synchronised with Retu rtc. There is a problem, though: I'm omitting time skews, but in order to program the alarm in i.e. 8 months and 6s a calibration of the Retu rtc is required and it would need support from the DSP for measuring the deviation over time. However this seems unlikely to be needed. > > Every other use case is more secondary use case > 2. User is able to work on all scheduled events from one common point > UI (e.g as simon pointed, in a cinema, want to silent all alarms, cancel > or enable alarms). > - You can argue that switching off the device speaker would result the > same, though you might have the nuisance of screen turn ons. > - The ability to cancel/enable alarm might make things complicated for > application developers, as then events not delivered to the registered > apps, somebody need to tell them that the alarm was either cancelled or > rescheduled, so they can reach a sync state. The device can run out of power and the alarm not being delivered, so applications have to be able to cope with missing an alarm notification. And any form of polling or busy looping is not an option. > > From a Developer Perspective > 1. There should be a easy to use API enabling/disabling and notification > of scheduled events. > 2. Alarm/Notifier sub system should have the capability to delivery > events to applications, even in case the application is not running [e.g > starting the app with a specific startup reason code, so that the whole > app window need not be started e.g in case of calendar, only a dialog > pops up saying event due ... with option like open event (causing all > app window to come), reschedule/snooze, cancel This should also take into account the loading time for the application and whatever it might need. > 3. It would also be useful that the implemented solution is also > available/complaint/builds upon other solutioins like that mentioned > about hh.org and iPAQs That's using a HW timer and we already do the same. On the 770 the Omap RTC is not capable of waking up the device from power off, so it is out of scope for a 770 specific discussion. > 4. IN case of reshedule, or cancel, only the app which scheduled it, is > able to do that [some kind of inbuild security] > If a common UI is presented to the user that shouuld also provide a single entry point for events-management. > What I have learnt on this discussion thread > First the hardware > - On n770 RTC is the provided by retu, which has a granularity of 1 > minutes and can only handle 1 event at a time and that too for only > between now and 23:59 > - I am assuming that it is capable of waking up the hardware, even if it > is powered off [but with a alive and kicking battery] > > About the implementation (As a application developer I would not care > about the real implementation, till I can get a simple to use API > interface enabling basic use cases :) but from Maemo perspective, it is > benificial that the Maemo development Platform get a sane design. > > - some kind of D-BUS to auto activate and deliver events > - some kind of library to abstract the inner working of the > implementation [good also from point of view of application > portability], could be extension to lib_osso or another brand new > lib_alarm or whatever. This should also enable simultaneous concurrent use. > - some kind of UI , maybe a control panel applet to work with all > alarms/events scheduled. Now that depends if it is free for all to know > about all events scheduled by other apps [not so nice from security > point of view, so if security of this time is important then to drop > this completely] > - some sort of a daemon to provide software intelligence to make up for > hardware constrains. > - existing open source components should not be changed e.g reduces > maintainence overhead (proposals being crond, atd) Unfortunately these require the device to be running and waste battery. A much more desirable feature for a battery powered system would be having the "alarm/timer/event/whatever daemon" providing interfaces compatible with these programs so that no change would be requiured in applications using them. > > > I think it would be good idea to have a wiki page? My objective is > quite achieved that there is community participation, and people inside > nokia need to look into what the community had wanted and what was > delivered :) even when I know product schedules and requirements are > highest priority [read as , you wont get always what you wanted ;)]. > > cheers > Devesh > > > > > > > > > ext Igor Stoppa wrote: > > >On Wed, 2006-01-11 at 11:35 -0800, ext Jason Mills wrote: > > > > > >>A few items: > >> > >>0) The RTC subsystem is served off a chip known as "Retu". Most of the ASICs > >>on the Nokia 770 board seem to have nice nordic names to them. :-) > >> > >> > >>1) The RTC subsystem only supports one future alarm event, and that event > >>may > >>not be more than 24h59m from "now". Maximum alarm granularity is +/-1 minute > >>or so. > >> > >> > >23h59m if memory serves me well > > > >Only Retu can wake up the device from poweroff state at a preset time; > >unfortunately this is the time resolution that it canprovide. In order > >to extend alarms and events scheduling one could have the daemon > >scheduling periodic wakeups (every 24h) till the real alarm is closer > >than 24h. > >The granularity problem could be overcome using either a sw timer or an > >internal HW timer, with better resolution than 1m. > >It would be programmed by the daemon, after the last wakeup and before > >reaching the scheduled time for the event. > > > > > > > >>2) The actual definition of "now" is a bit arbitrary, because of how the RTC > >>synchronization works. > >> > >> > >>3) There is a functional, albeit spartan CLI utility already available to > >>talk to the RTC subsystem, -and- to set/check the alarm. > >>/mnt/initfs/usr/bin/retutime > >> > >> > >>4) The osso_alarm and osso_notifier daemons are missing at least from the > >>2005.51 Nokia build. No bug is currently filed against this, and I haven't > >>had a chance to file one yet. I think, though am not 100% sure, that these > >>two daemons are required in order to fetch the actual alarm signal from the > >>RTC subsystem. > >> > >> > >>-JMills > >>_______________________________________________ > >>maemo-developers mailing list > >>maemo-developers@maemo.org > >>https://maemo.org/mailman/listinfo/maemo-developers > >> > >> > > > > > > > -- Igor Stoppa (Nokia M - OSSO / Tampere) _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
