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.xxxx 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 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
