Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hi, Am Montag, den 16.01.2006, 14:24 +0200 schrieb Igor Stoppa: On Fri, 2006-01-13 at 16:11 +0100, ext Nils Faerber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Stoppa schrieb: [snip] Obviously they have different wakeup latencies but all of them are insignificant, when compared to the delay that would be introduced by a traditional suspend-to-disk, which is the closer state to the poweroff that youu are mentioning. Well, power-off is something like shutdown in the first place, not necessarily connected to suspend to disk - you could simply reboot the device loosing your state. That's not really desired in a consumer device. But as someone ales already pointed out I would also accept and even expect that a device that is switched off (770 power button - switch off) will indeed keep being switched off despite of any occuring alarms. The user should know what he does when switching off his/her device. So I think we can basically ignore the power off problem and concentrate on the other above mentioned power/sleep states. Again, we are talking about something that is actually meant to be sold, so it has to behave nicely. Personally I like to have my alarms to be fire forget. What's the point of setting an alarm if I have to remember to take care of the thing that should remind me of it? What about just warning the user when he tries to power off? [ Poweroff but events are pending [ [ The next event comes up on xx.xx. at xx:xx. [ Are you sure you want to power off and possibly miss the alarm? [ [ [Oops] [Power Off] As a first-time Arm user, I have no deep idea about handhelds and such, but I can tell you that I do want Off mean OFF. If you actually mean that the device could sleep deeper when user is not using it but keeping it switched on, then ok. But if user turns it off manually, the thing better _stay that way_. The point being for example my Nokia cell phone has alarms too. They are nice and dandy, and I do use them... However, 1) It wouldn't occur to me that a switched-off cell phone would deliver the alarm. [somewhat Off-Topic: with cell service providers in our country _tracking where the users are and telling it to random callers_, I'd throw it away the second I would see it reactivating from poweroff] 2) If I have alarms set but switch the cell phone off, I do it deliberately because I want my peace and quiet (also not to be able to be called), and if I had a meeting with the president of the country and now miss the alarm, _so be it_ (of course it could warn me when I try to switch it off, but not after that). Of course that's maybe a personality problem (or just coping with complexity), but that's what I do :) Even if we can achieve roughly 10 days of standby time, that's not much compared to the power saving that can be achieved by effectively switching off the device over very long periods of inactivity. semi-off, you mean. Off except for the RTC and interrupt lines and minimal arm processor power and lines in-between and whatnot. e.g. standby... There is also the side case to consider that when baterry runs low, I turn it off to conserve power for later use when I need it more urgently. If it wouldn't really turn off when I tell it to, how much power would that draw? Would it endanger the later use? Or would it be neglectable? cheers, Danny That would be compromised by such an approach of delivering alarms only when the device is on. These small details make the difference between a device for hackers only and a device that can leverage the benefits of running linux and yet provide a good user experience even to the regular users. As long as there is such a timer which can be used that would be fine. Sounds a little bit similar to what we do on the iPAQ. I used generic terms, but the Omap RTC is what I had in my mind. However this fine-grained resolution would be lost when the device is _really_ off and the usual trick to wake up and wait would be required. And the RTC has to be added to the list of wakeup sources that can trigger the transition from any sleep state to running. That is just a bit in some regsiter - a very trivial kernel modification. The more problem would be to write an OMAP RTC compatible driver for the 1710 (if not yet existent, which it IMHO is not) since there is not documentation for the 1710 publically available. I checked it some time ago for a basic wakeup functionality and apart for a few changes that functionality was already provided. I wrote the first SA1110 RTC driver and this was pretty easy given you have the docs. After toggling the wakeup source register bit for RTC we had proper wakeup alarms on the iPaq ;) This was basically one weekend's work without prior experience with RTC code. No big deal. Next was RTC support for atd, or in fact Rus Nelson started a specialised small scale atd for iPaq and
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On 1/21/06, Danny Milosavljevic [EMAIL PROTECTED] wrote: What about just warning the user when he tries to power off? [ Poweroff but events are pending [ [ The next event comes up on xx.xx. at xx:xx. [ Are you sure you want to power off and possibly miss the alarm? [ [ [Oops] [Power Off] But what if the event's in a week or so? How do you remember to power it up again? Set an alarm somewhere else, perhaps? ;-) However, 1) It wouldn't occur to me that a switched-off cell phone would deliver the alarm. [somewhat Off-Topic: with cell service providers in our country _tracking where the users are and telling it to random callers_, I'd throw it away the second I would see it reactivating from poweroff] Every *single* phone I've owned with an alarm function will turn itself on to sound the alarm. Whether Nokia, Sony Ericsson or other... 2) If I have alarms set but switch the cell phone off, I do it deliberately because I want my peace and quiet (also not to be able to be called), and if I had a meeting with the president of the country and now miss the alarm, _so be it_ (of course it could warn me when I try to switch it off, but not after that). Of course that's maybe a personality problem (or just coping with complexity), but that's what I do :) If you want your phone to be quiet, you set it to silent mode - which is remembered when it turns itself back on to sound the alarm. There is also the side case to consider that when baterry runs low, I turn it off to conserve power for later use when I need it more urgently. Indeed, and my own use case for alarms is that if I've set an alarm to go off that is the absolute most important thing to happen. If my battery's running low and I need to turn the device off to conserve more power, it's still important it'll turn itself on to alert me. If it wouldn't really turn off when I tell it to, how much power would that draw? Would it endanger the later use? Or would it be neglectable? Except off will mean off - the chip which re-awakes the device is already running and keeping track of the time even when the device is hard-off. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: 770 Power Management and power states --- WAS: Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Fri, 2006-01-20 at 16:17 +0200, Riku Voipio wrote: On Wednesday 18 January 2006 15:07, Igor Stoppa wrote: The price for it is that we had to fix drivers and applications so that they would behave decently, without keeping resources (clocks) constantly allocated and without generating unnecessary activity. The problem is 3rd party developers who are not aware of such situation. for example, a periodically updating statusbar plugin will eat your battery away. STOP DOING STUFF WHEN YOU GET system_inactivity_ind should be in big red letters in the first part of api documentation. They will be, when next version of maemo will be relesed. Those requirements are already However almost everything that optimises cpu performance is good for power consumption too (on a fixed frequency system). If I had to summarise, well it would go like: -1)Thou shan't busy-loop -2)Thou shan't poll poll -3)Thou shan't use libraries that will do 1) and 2) in your place. Then we move to a grayer area, like don't do unnecessary stuff. Screen updates with unlit screen are a good example, but only when the effect of the update is not going to be needed later on. Typical case: blinking, glowing and such eyecandies. But that is GOOD anyway because it means having better code, better algorithms. With this argument, multitasking of windows 3.11 is better since it forces developers to write code so that they give time to others. I disagree: this case is just making obvious to people how to leverage hw that they are already using. Quite different. So the 770 can save power even when you have the device in your hand with the screen lit and a wireless connection open, as long as it's not actually doing something, like rendering a web page. Which is a *very* good thing, I don't think anyone suggested removing current dyntick and PM setup, but rather added suspend as well. Many users have grown accustomed in manual suspending, so perhaps adding no-op suspend button to the powerkey menu would make them happy =) bad habits should be discontinued, not supported. Don't tell me that you would like to have a crank on the front of your car so that you can start the engine =) hmm.. maybe just sending SIGSTOP to all user apps is enough to make them release clocks? I doubt: apps are not directly involved in clocks handling: it would be a possible approach for a suspend-based system, but what is really desirable here is that apps just make sure to avoid keeping the processor busy. The system can take care of itself as long as it's idle. -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On mån, 2006-01-16 at 20:46 +0100, ext Frantisek Dufka wrote: snip] Why not let users shutdown easily? Because you keep the state and don't need to boot the device through tons of /etc/rcx.D/* (and do it in advance without user noticing anything) to handle single alarm and then shutdown it again. Because with proper suspend (or should it be called standby?) instead of poweroff you may save enough battery to have it look like real poweroff without any ill effects. Because this is a PDA or 'Internet Tablet' not unix server that can take minutes to boot or shutdown and noone cares because you do it once per several years. We already do the power saving part, we already have all the positive side effects of keeping alive -- but *if* the user wants to do a proper shutdown, which will allow him to keep the device alive even longer than usual -- let them. It's not going to hurt you one single bit -- you're not forced to use the functionality just because it's there... Current 'Switch off!' mode should be something people should do only when the want to put the device to drawer for months and want the battery charged (which you could do by removing battery anyway). On ipaq you have very awkward key combo for this mode buried deep in manual on page noone reads. Not directly in menu on device. And yes in this mode alarms are not supposed to wake up the device :-) I don't really think we should consider iPaq as a reference point of brilliant design... I definitely expect my devices to wake up from sleep even when they're off. Hell, my phone(s) wakes up from sleep even when it's off. Yours probably does too. Power management efficient enough to make suspend meaningless If the suspend is taken as replacement of poweroff the reason is here because it should pause the device in the midle of playing video or sound. Take it as the current 'Lock touchscreen and keys' plus pausing sound and network plus anything that takes power or keeps state that is useless after couple of minutes. Maybe suspending tasks is not needed after all just send them different signal so they know device will be paused for many minutes and may wake up in different environment so they should really finish/stop what they do. So it is probably about more device modes than current offline or flight mode (are they same?) and normal. Introducing something like that would mean that we'd need to modify all programs to handle custom signals. As a side note: yes, at the moment, offline mode and flight mode are the same, that may not remain so. I cannot really understand why a lot of people here seem to want crippled functionality just because other platforms have limitations. Instant poweron and proper pausing of everything when you press one button is not crippled functionality but very simple and neat thing Palm devices do and people expect. If you want the kind of soft poweroff you talk about, try putting the cover on your device some time... Whoops! It pauses video playback! It disconnects network connections!. And if you really want the audio playback to be disabled too when the cover is closed (personally I find it a quite nice that it keeps playing), we can hack that up just for you, no problem. All this said, the powerkeymenu is going to be redesigned to allow for custom actions, and an action that emulates soft powerup by doing enable keypadlock + offline mode + pause sound playback should be trivial enough to implement. Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Weinehall David (Nokia-M/Tampere) wrote: We already do the power saving part, we already have all the positive side effects of keeping alive -- but *if* the user wants to do a proper shutdown, which will allow him to keep the device alive even longer than usual -- let them. It's not going to hurt you one single bit -- you're not forced to use the functionality just because it's there... No problem. My point was about not letting user shutdown _easily_. By this I meant that most people selecting 'Power off' really don't mean shutdown but something like suspend/standby i.e. pause everything. It is consumer device. When you pres red button on TV or hi-fi remote you really don't expect it to poweroff completely and later wait 1 minute until it powers on again. There should still be shutdown in case you want to replace battery safely but this will be used rarely (and can be deliberately a bit more complex like that button combo on ipaq). And my second point was that in such rare ocassion users might accept that alarms do not work. But if you implement it, it is better of course :) I just thought it is hard to do properly (i.e booting up, showing alarm and then shutting it down) and has little value. If someone has reason to poweroff it is likely he will not hear the alarm anyway. But it doesn't hurt of course. Maybe suspending tasks is not needed after all just send them different signal so they know device will be paused for many minutes and may wake up in different environment so they should really finish/stop what they do. So it is probably about more device modes than current offline or flight mode (are they same?) and normal. Introducing something like that would mean that we'd need to modify all programs to handle custom signals. By signal I mean message about device mode change. It is already there, isn't it? It just need more fine-grained control or more modes. And you need it anyway for implementing that special feature for me below :) If you want the kind of soft poweroff you talk about, try putting the cover on your device some time... Whoops! It pauses video playback! It disconnects network connections!. And if you really want the audio playback to be disabled too when the cover is closed (personally I find it a quite nice that it keeps playing), we can hack that up just for you, no problem. Yes the cover is good way to go to this mode but it needs more options. What if you stream your music from home network and want still listen with cover on? Or what if you want it to 'soft poweroff' including the sound because you throw in in the bag then and go somewhere? All this said, the powerkeymenu is going to be redesigned to allow for custom actions, and an action that emulates soft powerup by doing enable keypadlock + offline mode + pause sound playback should be trivial enough to implement. Excellent. Thank you. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On 1/17/06, Weinehall David (Nokia-M/Tampere) [EMAIL PROTECTED] wrote: We already do the power saving part, we already have all the positiveside effects of keeping alive -- but *if* the user wants to do a propershutdown, which will allow him to keep the device alive even longer than usual -- let them.It's not going to hurt you one single bit -- you'renot forced to use the functionality just because it's there... Current 'Switch off!' mode should be something people should do only when the want to put the device to drawer for months and want the battery charged (which you could do by removing battery anyway). On ipaq you have very awkward key combo for this mode buried deep in manual on page noone reads. Not directly in menu on device. And yes in this mode alarms are not supposed to wake up the device :-)I've been using PDAs since the old Palm Professional and I really appreciate the way they handle the power button. No state is lost, it's virtually instantaneous (much like waking the 770!), and I can grab the device, jot down a note/etc., and switch it off very quickly. It's rather confusing to hit the power button on 770 and be presented with a menu; I want it to switch off (or appear to), not ask for more input. I'd also like it to ignore screen taps once it's pretending to be off-- unless it sleeps automatically. This way it doesn't wake up inadvertently in my pocket, but it's easy to tap it to wake it up again if I let it sleep while doing something else. Playing music should keep going as it does currently, although an on-screen button to make it switch the screen off immediately would be great. I really don't like having it glowing in my pocket, and having to place the cover on is awkward enough (not a one-hand operation) that the power button is really important. Behaving like a Palm will make sense to all the former users like myself, and delight Zaurus users (myself included) who hated having to hold down the power button to make it do anything as well as the considerable lag before it was responsive again. I would reserve a long press of the power button for either a hard power down if things lock up, or to present the menu at that point. Just my 2c,Larry I don't really think we should consider iPaq as a reference point of brilliant design...I definitely expect my devices to wake up from sleep even when they'reoff.Hell, my phone(s) wakes up from sleep even when it's off.Yours probably does too. Power management efficient enough to make suspend meaningless If the suspend is taken as replacement of poweroff the reason is here because it should pause the device in the midle of playing video or sound. Take it as the current 'Lock touchscreen and keys' plus pausing sound and network plus anything that takes power or keeps state that is useless after couple of minutes. Maybe suspending tasks is not needed after all just send them different signal so they know device will be paused for many minutes and may wake up in different environment so they should really finish/stop what they do. So it is probably about more device modes than current offline or flight mode (are they same?) and normal.Introducing something like that would mean that we'd need to modify all programs to handle custom signals.As a side note: yes, at the moment, offline mode and flight mode are thesame, that may not remain so. I cannot really understand why a lot of people here seem to want crippled functionality just because other platforms have limitations. Instant poweron and proper pausing of everything when you press one button is not crippled functionality but very simple and neat thing Palm devices do and people expect.If you want the kind of soft poweroff you talk about,try putting the cover on your device some time...Whoops!It pauses video playback!It disconnects network connections!.And if you really want the audio playback to be disabled too whenthe cover is closed (personally I find it a quite nice that it keepsplaying), we can hack that up just for you, no problem. All this said, the powerkeymenu is going to be redesigned to allow forcustom actions, and an action that emulates soft powerup by doingenable keypadlock + offline mode + pause sound playback should be trivial enough to implement.Regards: David Weinehall___maemo-developers mailing listmaemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Le lundi 16 janvier 2006 à 14:24 +0100, Nils Faerber a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Stoppa schrieb: These small details make the difference between a device for hackers only and a device that can leverage the benefits of running linux and yet provide a good user experience even to the regular users. Well, comparing with today's other PDA like devices this behaviour seems pretty normal for me - a switched off PocketPC will be off, no matter what (even worse, some of them cannot be switched of at all in the first place causing their batteries to be drained 100% whan not taken care of! This is very bad with devices with fixed built in batteries which is why I guess that Nokia implemented the Switch-Off). I also guess that most Palms and alike behave the same - off is off. Only exception from that rule I know of are (some) mobile phones. No, all PalmOS PDA (I'm not sure about smartphones based on PalmOS) can't be turned off. They are always in standby mode and are always able to wake up for alarms. -- Frederic Crozat [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Nils Faerber wrote: I also guess that most Palms and alike behave the same - off is off. Only exception from that rule I know of are (some) mobile phones. No in PalmOS off is not off. On Tungsten T2 you can set it to be waked up by initiating bluetooth connection with it when it is 'off'. You can also schedule alarm procedure which gets executed and the display is even not waked up if you wish. Unlike with N770 you really can't shutdown PalmOS and battery is not removable in most units so there is not this type of problem there. Solution for N770 would be to remove the poweroff item to make it behave like PalmOS and maybe also implement suspend in kernel which pauses all tasks and powers off unneeded hardware. But the current system is also good, just don't let users shutdown the device so easily. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On mån, 2006-01-16 at 15:58 +0100, ext Frantisek Dufka wrote: Nils Faerber wrote: I also guess that most Palms and alike behave the same - off is off. Only exception from that rule I know of are (some) mobile phones. No in PalmOS off is not off. On Tungsten T2 you can set it to be waked up by initiating bluetooth connection with it when it is 'off'. You can also schedule alarm procedure which gets executed and the display is even not waked up if you wish. Unlike with N770 you really can't shutdown PalmOS and battery is not removable in most units so there is not this type of problem there. Solution for N770 would be to remove the poweroff item to make it behave like PalmOS and maybe also implement suspend in kernel which pauses all tasks and powers off unneeded hardware. But the current system is also good, just don't let users shutdown the device so easily. Why?!? A mechanism for wake-up from power-off exists (yes, it's a bit sucky, so we'll have to have a workaround for alarms 24h into the future, but at least it's possible) -- check Power management efficient enough to make suspend meaningless -- check I cannot really understand why a lot of people here seem to want crippled functionality just because other platforms have limitations. Regards: David Weinehall ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On 1/16/06, Igor Stoppa [EMAIL PROTECTED] wrote: That's not really desired in a consumer device. I can see I'm going to run a risk here of alienating myself early from the Nokia employees on the list, as I keep coming to this same point when reading a lot of the posts here, and think it still remains an open question (hopefully my comments will be received in the enthusiastic and constructive light with which they're intended): Is the 770 a consumer device? I mean _right_now_, is it a hit w/ consumers? How many internet appliances have made it in the marketplace? Larry Ellison would be a rich man if that whole paradigm were as valuable to consumers as tech pundits think ;-) These small details make the difference between a device for hackers only and a device that can leverage the benefits of running linux and yet provide a good user experience even to the regular users. Well, 10 years ago, PC's running linux were device[s] for hackers only. Now companies run parellel virtualized Linux instances on massive big iron systems to run their businesses. Did we get to that point because IBM massively invested early in making the Linux-on-server user experience good? It was possible in the firstplace to leverage the benefits of Linux because it spent a decade as a _totally_ open platform for experimentation. Those areas where it lagged, it often lagged precisely because of the closed nature of some piece or other or hardwre (think winmodems, think graphics, think ahem wireless). If making a device for hackers isn't the leverage that attaches to running linux, what is (besides low cost and OS vendor lock-in)? I'm really interested in the answer of both Nokia people and other developers to this question, but since I've brought it up more than once on this list OT, I'll shut up about it now except to ask, is anyone else interested in having the conversation, and if so, where? Dave ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Weinehall David (Nokia-M/Tampere) wrote: No in PalmOS off is not off. On Tungsten T2 you can set it to be waked up by initiating bluetooth connection with it when it is 'off'. You can also schedule alarm procedure which gets executed and the display is even not waked up if you wish. Unlike with N770 you really can't shutdown PalmOS and battery is not removable in most units so there is not this type of problem there. Solution for N770 would be to remove the poweroff item to make it behave like PalmOS and maybe also implement suspend in kernel which pauses all tasks and powers off unneeded hardware. But the current system is also good, just don't let users shutdown the device so easily. Why?!? Why not let users shutdown easily? Because you keep the state and don't need to boot the device through tons of /etc/rcx.D/* (and do it in advance without user noticing anything) to handle single alarm and then shutdown it again. Because with proper suspend (or should it be called standby?) instead of poweroff you may save enough battery to have it look like real poweroff without any ill effects. Because this is a PDA or 'Internet Tablet' not unix server that can take minutes to boot or shutdown and noone cares because you do it once per several years. Current 'Switch off!' mode should be something people should do only when the want to put the device to drawer for months and want the battery charged (which you could do by removing battery anyway). On ipaq you have very awkward key combo for this mode buried deep in manual on page noone reads. Not directly in menu on device. And yes in this mode alarms are not supposed to wake up the device :-) Power management efficient enough to make suspend meaningless If the suspend is taken as replacement of poweroff the reason is here because it should pause the device in the midle of playing video or sound. Take it as the current 'Lock touchscreen and keys' plus pausing sound and network plus anything that takes power or keeps state that is useless after couple of minutes. Maybe suspending tasks is not needed after all just send them different signal so they know device will be paused for many minutes and may wake up in different environment so they should really finish/stop what they do. So it is probably about more device modes than current offline or flight mode (are they same?) and normal. I cannot really understand why a lot of people here seem to want crippled functionality just because other platforms have limitations. Instant poweron and proper pausing of everything when you press one button is not crippled functionality but very simple and neat thing Palm devices do and people expect. Regards, Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Thu, 2006-01-12 at 15:55 +0100, ext Florian Boor wrote: Hello, Igor Stoppa wrote: 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. i'm not that familiar with the power states of the 770. Does it actually reach poweroff during normal use without turning it off with the power switch? Nope. Omap has basically idling states: -arm idle -big sleep -deep sleep and which one is reached at a certain time depends on which peripherals/clocks are active. Obviously they have different wakeup latencies but all of them are insignificant, when compared to the delay that would be introduced by a traditional suspend-to-disk, which is the closer state to the poweroff that youu are mentioning. 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. As long as there is such a timer which can be used that would be fine. Sounds a little bit similar to what we do on the iPAQ. I used generic terms, but the Omap RTC is what I had in my mind. However this fine-grained resolution would be lost when the device is _really_ off and the usual trick to wake up and wait would be required. And the RTC has to be added to the list of wakeup sources that can trigger the transition from any sleep state to running. Greetings Florian -- Igor Stoppa (Nokia M - OSSO / Tampere) ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Igor Stoppa schrieb: On Thu, 2006-01-12 at 15:55 +0100, ext Florian Boor wrote: Igor Stoppa wrote: 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. i'm not that familiar with the power states of the 770. Does it actually reach poweroff during normal use without turning it off with the power switch? Nope. Omap has basically idling states: -arm idle -big sleep -deep sleep and which one is reached at a certain time depends on which peripherals/clocks are active. Obviously they have different wakeup latencies but all of them are insignificant, when compared to the delay that would be introduced by a traditional suspend-to-disk, which is the closer state to the poweroff that youu are mentioning. Well, power-off is something like shutdown in the first place, not necessarily connected to suspend to disk - you could simply reboot the device loosing your state. But as someone ales already pointed out I would also accept and even expect that a device that is switched off (770 power button - switch off) will indeed keep being switched off despite of any occuring alarms. The user should know what he does when switching off his/her device. So I think we can basically ignore the power off problem and concentrate on the other above mentioned power/sleep states. As long as there is such a timer which can be used that would be fine. Sounds a little bit similar to what we do on the iPAQ. I used generic terms, but the Omap RTC is what I had in my mind. However this fine-grained resolution would be lost when the device is _really_ off and the usual trick to wake up and wait would be required. And the RTC has to be added to the list of wakeup sources that can trigger the transition from any sleep state to running. That is just a bit in some regsiter - a very trivial kernel modification. The more problem would be to write an OMAP RTC compatible driver for the 1710 (if not yet existent, which it IMHO is not) since there is not documentation for the 1710 publically available. I wrote the first SA1110 RTC driver and this was pretty easy given you have the docs. After toggling the wakeup source register bit for RTC we had proper wakeup alarms on the iPaq ;) This was basically one weekend's work without prior experience with RTC code. No big deal. Next was RTC support for atd, or in fact Rus Nelson started a specialised small scale atd for iPaq and then RTC was added to it. This forms the alarm framework for Familar Linux. Cheers nils faerber - -- kernel concepts Tel: +49-271-771091-12 Dreisbachstr. 24 Fax: +49-271-771091-19 D-57250 Netphen Mob: +49-176-21024535 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDx8MFJXeIURG1qHgRAoMbAJ0Sh0Gmj/y6rxxPJmZ3AP6fQiaVjwCeOlz3 Xhixt4nciHrthDbaY7LtTpo= =q0Yx -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Maemo Alarm/Notifier Interface
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
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 20:20, ext Simon Budig wrote: Kimmo Hämäläinen ([EMAIL PROTECTED]) wrote: We have also other places where multiple simultaneous programs would screw things. Usually this can be avoided by the fact that the user can only use one application at a time. Oh right. Our System is broken anyway, so lets add more broken stuff. Sorry, this is *not* good software engineering. In general, no; but sometimes it's good to think before overengineering stuff... On Wed, 2006-01-11 at 18:50, ext Simon Budig wrote: The crontab(1) command cannot add an entry to the crontab, all it can do is pop up $EDITOR for the user to edit the crontab. Not what you want. My man page (old debian/testing) says that it can: The first form of this command is used to install a new crontab from some named file or standard input... Right, I missed that. It doesn't really help, since it installs - as far as I understand the manpage - a *new* crontab, discarding old entries. We can avoid this with some nice wrapper. Note that we can use separate, named crontabs for each alarm. Glib also is not always a good idea: It can handle timeouts but does not make any guarantees about them. Plus - as florian already mentioned - it would require your program to run all the time and waste memory. I think the user does not except atom clock precision anyway. Cron would allow the application to be launched closer to the set alarm, so the running time of the application could be minimised. Well, OTOH I don't think that differences = 1s are acceptable. If we launch an application to just play the sound we very well are in this range of prescision. We will try to re-use existing (preferably standard) software, so unless cron is not enough, it will be preferred over some new daemon implemented from scratch. I'd love to have an API call that enqueues an alarm at a specific time (maybe even with a specific sound, but I doubt that it should provide any dialog facilities, that would make it quite complex) that calls back into the application via dbus. That would make it possible to disable alarms globally (similiar to the flight mode - a cinema mode :) and would enable a list of scheduled alarms, regardless of the application that scheduled it. You can use DBus from a crontab if you want (e.g. with dbus-send). Also, stopping and restarting cron is possible. The question IMHO is not what I *can* but what I *want*. Of course I can implement applications write()ing the X-protocol to a socket of the system, that hopefully results in a window presented by the X-Server, but that does not mean that it is clever or feasible. Libraries exist for a reason. You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. What was so difficult with cron? Ok, let me try some pseudo code to add an crontab entry for an alarm from within an application written in C. minutestring = g_strdup_printf (%d, minute); hourstring = g_strdup_printf (%d, hour); addcommand = g_strdup_printf ((crontab -l ; echo \%s %s %s %s %s %s\) | crontab -, minutestring, hourstring, *, *, *, commandstring); system (addcommand); g_free (addcommand); g_free (minutestring); g_free (hourstring); We can avoid this with some wrapper, I think. Removing an entry from the crontab would require more advanced trickery with sed to remove the entry from the crontab -l listing. Beware to not remove an entry by another application! And make sure to get the quoting for your shell commands exactly right. How do you quote spaces in an argument to dbus-send when invoking the above command? Of course some of this complexity could be hidden by custom shell scripts. You'll always have the quoting issues though. Getting a list of the currently scheduled alarms needs another mechanism, according to your approach it would probably mean implementing a parser to get the information from the output of a shell script. Now. Someone not too familiar with shell programming wants to use this and it does not work. What do you tell him? Now compare this to this: osso_time_schedule_alarm (context, alarm_time, OSSO_ANNOYING_SOUND, my_custom_callback_function); (or whatever, I did not think very deeply about the arguments). It would be typesafe, incredibly easy to use and if it doesn't work the blame is on Maemo. Great for application developers :) I think we'll just have a wrapper for crontabs. The function above looks
Re: [maemo-developers] Maemo Alarm/Notifier Interface
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. 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. 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 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 4. IN case of reshedule, or cancel, only the app which scheduled it, is able to do that [some kind of inbuild security] 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) 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
Re: [maemo-developers] Maemo Alarm/Notifier Interface
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)
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hello, Igor Stoppa wrote: 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. i'm not that familiar with the power states of the 770. Does it actually reach poweroff during normal use without turning it off with the power switch? 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. As long as there is such a timer which can be used that would be fine. Sounds a little bit similar to what we do on the iPAQ. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hello, 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. waking up the device from power off would take some time anyway. So it might be necessary to deal with power off in two steps: One raw timer waking up the device early enough to ensure some other instance (like the RTC) is able to care about the event while the device is running. Not that nice, but maybe the only way to deal with this. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On 1/10/06, Devesh Kothari [EMAIL PROTECTED] wrote: I am currently looking for what developer requirements would be from such an Alarm/Notifier interface. Specially lot of developers working on applications which need to schedule events and notifications like PIM aplications need this functionality, and it is just not there yet in the Maemo Development Platform. Some starters 1. API to - enable notifier/alarm events - cancel previously scheduled events - ability to specify sound file to be played for events [I guess this can be done by the application handling the notifier event, so maybe not relevant] I would like to have a simple-to-use approach, just like GObject does with the additional option to set to a given time (can be seconds since unix epoch, time_t or something like this). As GObject functions it should return the id and then you should be able to remove by this id. I would like to have the system subsys to play and also specify a message (Rich text) to be displayed, this would eliminate the need to start the application just to say the alarm was due. For user and dev conveniece, this subsystem would get the option to postpone events at alarm creation time... maybe developers may specify the next value, something like: add_alarm( sometime, You need to backup, one_day_delay, backup_callback ); That would be presented to user like: You need to backup [ Do it ] [Postpone to tomorrow ] If user click the second button, alarm subsys will reschedule the event automatically. Many kinds of PDA apps would benefit from this. Also, the subsystem would need to enable 2 options of callback: using DBUS and executing a program (like cron does). The last option is needed since the user may not have the application opened or don't need to open it to do the action (some shell script provided may do the trick). 2. Alarm/Notifier sub system features - ability to schedule multiple notifier alarm event - ability to wake up device on events Great. -- Gustavo Sverzut Barbieri -- Computer Engineer 2001 - UNICAMP Mobile: +55 (19) 9165 8010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hello! Devesh Kothari wrote: I am currently looking for what developer requirements would be from such an Alarm/Notifier interface. Specially lot of developers working on applications which need to schedule events and notifications like PIM aplications need this functionality, and it is just not there yet in the Maemo Development Platform. This is a feature i really missed porting gpe-calendar. I'm convinced that there are some more applications which could need a feature like this. The most important reason to introduce a notifier interface is that you can easily introduce a battery drain problem with applications doing frequent updates/checks. That would have a negative influence on the reputation on the 770 and maemo. Some starters 1. API to - enable notifier/alarm events - cancel previously scheduled events - ability to specify sound file to be played for events [I guess this can be done by the application handling the notifier event, so maybe not relevant] I'd keep the interface as simple as possible. Call a function to schedule an event and get back an unique id. This is used to identify the event in a callback function and to cancel it. Playing sounds should be the job of the calling application, it usually needs to do some more action anyway. I can imagine that this might be useful for scheduling tasks which are not related with user interaction too. 2. Alarm/Notifier sub system features - ability to schedule multiple notifier alarm event - ability to wake up device on events Waking up the device would be important, yes. Another feature to think about would be to set some command to run (and pass information to) or a dbus service to fire if the event time is reached. That would make it possible to have timed events without the need to have the calling application running all the time. For calendar applications this would be very useful. I had some discussion with Kimmo about this topic some time ago. One idea was just to use atd. This one would need to become part of the default filesystem because we can't start it automatically. In addition to this we would need to extend it by some feature to wake up the device. I suggested to extend the libosso time API which currently covers system clock changes. Making it a comprehensive interface for time-related tasks would be an option if it really fits into the intended purpose of libosso. Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 14:00, ext Florian Boor wrote: Hello! Devesh Kothari wrote: I am currently looking for what developer requirements would be from such an Alarm/Notifier interface. Specially lot of developers working on applications which need to schedule events and notifications like PIM aplications need this functionality, and it is just not there yet in the Maemo Development Platform. This is a feature i really missed porting gpe-calendar. I'm convinced that there are some more applications which could need a feature like this. The most important reason to introduce a notifier interface is that you can easily introduce a battery drain problem with applications doing frequent updates/checks. That would have a negative influence on the reputation on the 770 and maemo. Some starters 1. API to - enable notifier/alarm events - cancel previously scheduled events - ability to specify sound file to be played for events [I guess this can be done by the application handling the notifier event, so maybe not relevant] I'd keep the interface as simple as possible. Call a function to schedule an event and get back an unique id. This is used to identify the event in a callback function and to cancel it. Playing sounds should be the job of the calling application, it usually needs to do some more action anyway. I can imagine that this might be useful for scheduling tasks which are not related with user interaction too. Doesn't Glib has this kind of functionality already? 2. Alarm/Notifier sub system features - ability to schedule multiple notifier alarm event - ability to wake up device on events Waking up the device would be important, yes. Another feature to think about I think the system/HW takes care of wakeups automatically. would be to set some command to run (and pass information to) or a dbus service to fire if the event time is reached. That would make it possible to have timed events without the need to have the calling application running all the time. For calendar applications this would be very useful. I had some discussion with Kimmo about this topic some time ago. One idea was just to use atd. This one would need to become part of the default filesystem because we can't start it automatically. In addition to this we would need to extend it by some feature to wake up the device. Instead of atd, we will use cron. So, we don't have an extra daemon in the system. Alarms 5min or something should use cron and faster alarms implemented in the application (or in a library). I suggested to extend the libosso time API which currently covers system clock changes. Making it a comprehensive interface for time-related tasks would be an option if it really fits into the intended purpose of libosso. No! :) Isn't Glib+cron enough? BR; Kimmo Greetings Florian ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hi, HimKimmo Hämäläinen wrote: Doesn't Glib has this kind of functionality already? you can have recurring events with glib, yes... but that involves that you have the application running all the time. In combination with the fact that you can't have custom software packages starting up some deamon on boot this feature doesn't cover all the needs. In addition to this i think it would be much more convenient if you just set a time of an event instead of an interval, but thats my personal opinion. I think the system/HW takes care of wakeups automatically. That would make this part pretty easy :-) Instead of atd, we will use cron. So, we don't have an extra daemon in the system. Alarms 5min or something should use cron and faster alarms implemented in the application (or in a library). Will there be some defined API to use this? From the application developers point of view you don't want to care about which mechanism the system uses, you just want to make it right and working. If you want to see the correct solution accepted by the developers its absolutely necessary to provide a useful API. Do we have any experience on how cron influences power consumption? From what i see on my 770 we don't have it running in the current software image. No! :) Isn't Glib+cron enough? It depends on two questions: - Does it work? - How do you expose this to the application developers? Well... i know that i'm complicated :-) Greetings Florian -- The dream of yesterday Florian Boor is the hope of todayTel: 0271-771091-14 and the reality of tomorrow.Fax: 0271-771091-19 [Robert Hutchings Goddard, 1904][EMAIL PROTECTED] 6C 44 30 4C 43 20 6B 61 16 07 0F AA E6 97 70 A8 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Hi, On Wed, 2006-01-11 at 17:12, ext Florian Boor wrote: Hi, HimKimmo Hämäläinen wrote: Doesn't Glib has this kind of functionality already? you can have recurring events with glib, yes... but that involves that you have the application running all the time. In combination with the fact that you can't have custom software packages starting up some deamon on boot this feature doesn't cover all the needs. In addition to this i think it would be much more Looking at crontab(5) man page, cron allows you to execute a program once in startup, so you could start some kind of daemon like that. convenient if you just set a time of an event instead of an interval, but thats my personal opinion. You could have a shell script launched by cron that checks the current time of day and, if the time is right, starts some program that plays annoying alarm sound at full volume. I think the system/HW takes care of wakeups automatically. That would make this part pretty easy :-) Instead of atd, we will use cron. So, we don't have an extra daemon in the system. Alarms 5min or something should use cron and faster alarms implemented in the application (or in a library). Will there be some defined API to use this? From the application developers point of view you don't want to care about which mechanism the system uses, you just want to make it right and working. If you want to see the correct solution accepted by the developers its absolutely necessary to provide a useful API. I guess the 'API' is crontab(1) + crontab(5). It has probably been tested in the course of time and proven good and stable. Do we have any experience on how cron influences power consumption? From what i see on my 770 we don't have it running in the current software image. I assume it will sleep most of the time and poll once in a minute (according to man page). No! :) Isn't Glib+cron enough? It depends on two questions: - Does it work? - How do you expose this to the application developers? I think the application developer will use the crontab(1) command and the Glib API. We will try to re-use existing (preferably standard) software, so unless cron is not enough, it will be preferred over some new daemon implemented from scratch. BR, Kimmo Well... i know that i'm complicated :-) Greetings Florian ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On 11/01/06, Kimmo Hämäläinen [EMAIL PROTECTED] wrote: I assume it will sleep most of the time and poll once in a minute (according to man page). Polling once a minute is much too often, though! The daemon (even if it's crond) should get told, possibly over DBUS, when a scheduled event is added. It then recalculates its sleep time, and goes back to sleep until the next currently known event is due. Looking at the source to atd(8), this is what it seems to do. Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Kimmo Hämäläinen ([EMAIL PROTECTED]) wrote: I guess the 'API' is crontab(1) + crontab(5). It has probably been tested in the course of time and proven good and stable. Uh, not if you have potentially multiple programs simultaneously modifying the crontab. One faulty program could mess up your whole cron environment and you don't really want that. I think the application developer will use the crontab(1) command and the Glib API. The crontab(1) command cannot add an entry to the crontab, all it can do is pop up $EDITOR for the user to edit the crontab. Not what you want. Glib also is not always a good idea: It can handle timeouts but does not make any guarantees about them. Plus - as florian already mentioned - it would require your program to run all the time and waste memory. We will try to re-use existing (preferably standard) software, so unless cron is not enough, it will be preferred over some new daemon implemented from scratch. I'd love to have an API call that enqueues an alarm at a specific time (maybe even with a specific sound, but I doubt that it should provide any dialog facilities, that would make it quite complex) that calls back into the application via dbus. That would make it possible to disable alarms globally (similiar to the flight mode - a cinema mode :) and would enable a list of scheduled alarms, regardless of the application that scheduled it. You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 18:50, ext Simon Budig wrote: Kimmo Hämäläinen ([EMAIL PROTECTED]) wrote: I guess the 'API' is crontab(1) + crontab(5). It has probably been tested in the course of time and proven good and stable. Uh, not if you have potentially multiple programs simultaneously modifying the crontab. One faulty program could mess up your whole cron environment and you don't really want that. We have also other places where multiple simultaneous programs would screw things. Usually this can be avoided by the fact that the user can only use one application at a time. I think the application developer will use the crontab(1) command and the Glib API. The crontab(1) command cannot add an entry to the crontab, all it can do is pop up $EDITOR for the user to edit the crontab. Not what you want. My man page (old debian/testing) says that it can: The first form of this command is used to install a new crontab from some named file or standard input... Glib also is not always a good idea: It can handle timeouts but does not make any guarantees about them. Plus - as florian already mentioned - it would require your program to run all the time and waste memory. I think the user does not except atom clock precision anyway. Cron would allow the application to be launched closer to the set alarm, so the running time of the application could be minimised. We will try to re-use existing (preferably standard) software, so unless cron is not enough, it will be preferred over some new daemon implemented from scratch. I'd love to have an API call that enqueues an alarm at a specific time (maybe even with a specific sound, but I doubt that it should provide any dialog facilities, that would make it quite complex) that calls back into the application via dbus. That would make it possible to disable alarms globally (similiar to the flight mode - a cinema mode :) and would enable a list of scheduled alarms, regardless of the application that scheduled it. You can use DBus from a crontab if you want (e.g. with dbus-send). Also, stopping and restarting cron is possible. You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. What was so difficult with cron? BR; Kimmo Bye, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, Jan 11, 2006 at 07:33:41PM +0200, Kimmo Hämäläinen wrote: You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. What was so difficult with cron? Perhaps cron should grow dbus support so applications can register jobs without having to worry about locking the crontab file or run another daemon? -r ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On Wed, 2006-01-11 at 19:40, ext Ralph Giles wrote: On Wed, Jan 11, 2006 at 07:33:41PM +0200, Kimmo Hämäläinen wrote: You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. What was so difficult with cron? Perhaps cron should grow dbus support so applications can register jobs without having to worry about locking the crontab file or run another daemon? Or maybe we have that function in Libosso that allows setting and unsetting a crontab... That could also implement the locking. BR; Kimmo -r ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo Alarm/Notifier Interface
Kimmo Hämäläinen ([EMAIL PROTECTED]) wrote: We have also other places where multiple simultaneous programs would screw things. Usually this can be avoided by the fact that the user can only use one application at a time. Oh right. Our System is broken anyway, so lets add more broken stuff. Sorry, this is *not* good software engineering. On Wed, 2006-01-11 at 18:50, ext Simon Budig wrote: The crontab(1) command cannot add an entry to the crontab, all it can do is pop up $EDITOR for the user to edit the crontab. Not what you want. My man page (old debian/testing) says that it can: The first form of this command is used to install a new crontab from some named file or standard input... Right, I missed that. It doesn't really help, since it installs - as far as I understand the manpage - a *new* crontab, discarding old entries. Glib also is not always a good idea: It can handle timeouts but does not make any guarantees about them. Plus - as florian already mentioned - it would require your program to run all the time and waste memory. I think the user does not except atom clock precision anyway. Cron would allow the application to be launched closer to the set alarm, so the running time of the application could be minimised. Well, OTOH I don't think that differences = 1s are acceptable. If we launch an application to just play the sound we very well are in this range of prescision. We will try to re-use existing (preferably standard) software, so unless cron is not enough, it will be preferred over some new daemon implemented from scratch. I'd love to have an API call that enqueues an alarm at a specific time (maybe even with a specific sound, but I doubt that it should provide any dialog facilities, that would make it quite complex) that calls back into the application via dbus. That would make it possible to disable alarms globally (similiar to the flight mode - a cinema mode :) and would enable a list of scheduled alarms, regardless of the application that scheduled it. You can use DBus from a crontab if you want (e.g. with dbus-send). Also, stopping and restarting cron is possible. The question IMHO is not what I *can* but what I *want*. Of course I can implement applications write()ing the X-protocol to a socket of the system, that hopefully results in a window presented by the X-Server, but that does not mean that it is clever or feasible. Libraries exist for a reason. You'd have to hack a lot around crontab to enable all this and I doubt that would be significantly less error prone than implementing that stuff e.g. in the Desktop application or a new demon specific to that task. What was so difficult with cron? Ok, let me try some pseudo code to add an crontab entry for an alarm from within an application written in C. minutestring = g_strdup_printf (%d, minute); hourstring = g_strdup_printf (%d, hour); addcommand = g_strdup_printf ((crontab -l ; echo \%s %s %s %s %s %s\) | crontab -, minutestring, hourstring, *, *, *, commandstring); system (addcommand); g_free (addcommand); g_free (minutestring); g_free (hourstring); Removing an entry from the crontab would require more advanced trickery with sed to remove the entry from the crontab -l listing. Beware to not remove an entry by another application! And make sure to get the quoting for your shell commands exactly right. How do you quote spaces in an argument to dbus-send when invoking the above command? Of course some of this complexity could be hidden by custom shell scripts. You'll always have the quoting issues though. Getting a list of the currently scheduled alarms needs another mechanism, according to your approach it would probably mean implementing a parser to get the information from the output of a shell script. Now. Someone not too familiar with shell programming wants to use this and it does not work. What do you tell him? Now compare this to this: osso_time_schedule_alarm (context, alarm_time, OSSO_ANNOYING_SOUND, my_custom_callback_function); (or whatever, I did not think very deeply about the arguments). It would be typesafe, incredibly easy to use and if it doesn't work the blame is on Maemo. Great for application developers :) I hope that helps you understanding the importance of a proper API. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: [maemo-developers] Maemo Alarm/Notifier Interface
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. 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
Re: [maemo-developers] Maemo Alarm/Notifier Interface
On 1/11/06, Andrew Flegg [EMAIL PROTECTED] wrote: On 11/01/06, Kimmo Hämäläinen [EMAIL PROTECTED] wrote: I assume it will sleep most of the time and poll once in a minute (according to man page). Polling once a minute is much too often, though! The daemon (even if it's crond) should get told, possibly over DBUS, when a scheduled event is added. It then recalculates its sleep time, and goes back to sleep until the next currently known event is due. Looking at the source to atd(8), this is what it seems to do. Cron must do something like this, it's not dumb, it's a program really mature and should have this. My only concern is that this adds latency to the process (cron - shell -program), but we need to gather use cases to see if it's acceptable or not. My guess is that it's acceptable. But as already told, we should have an easy-to-use API to avoid writing to crontab directly. -- Gustavo Sverzut Barbieri -- Computer Engineer 2001 - UNICAMP Mobile: +55 (19) 9165 8010 Phone: +1 (347) 624 6296; [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] ICQ#: 17249123 MSN: [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
