[maemo-developers] [maemo-developers] Maemo Alarm/Notifier Interface

[From: Igor Stoppa]

On Mon, 2006-01-16 at 14:24 +0100, ext Nils Faerber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Igor Stoppa schrieb:
> > On Fri, 2006-01-13 at 16:11 +0100, ext Nils Faerber wrote:
> > 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.
> 
> I just meant the runtime-state, i.e. all running applications will
> simply be closed. All data will of course be preserved.
My point is that when it gets to usability, the 770 is as close as
possible to any other _Nokia_ consumer devices, i.e. phones, therefore
it has some of those harder constraints.

Of course Meamo is not the 770 but still these features are good, imho.
> 
> > 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?
> > 
> >> 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.
> >> That would be compromised by such an approach of delivering alarms only
> >> when the device is on.
> 
> Well, judging from the rest of the software of the 770 I do not see the
> off case as a regular use case. It is to me more something like a state
> to safe the battery from 100% depletion.
Which is indeed something one might want to do when recharging is not
going to be easy, like when traveling, hicking, you name it.
> 
> >> 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!
And is that good? ;-)

> This is very bad with devices with fixed built in batteries which is why
> I guess that Nokia implemented the Switch-Off). 
I don't get it: the battery is removable :-/
> 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.
Nope. 
> 
> I see that it would be a nice feature but I also see that it is too much
> hassle to implement. Please observe that not only the switch-on from
> power-off case is a problem but also how to handle the reverse
> direction.
poweroff command works just fine

>  After having half booted the machine to signal the alarm you
> would have to automatically shut it down again.
so?

> Then think about plane rides - say the offline mode is not activated,
> i.e. the wireless modules have been on at shut-down time. Now you travel
> in a plane and an alarm goes off in your pocket, bootig the device up.
> Shall the radio be activated according to last saved state or should it
> be switched off? What about user experience here? Last time the user
> shut the device off the radio was on but now it is shut off? Why?
> 
We _don't_ turn on radio components by default. Your point doesn't
really exist. It's yet another complication coming from suspend.

Sleeping while idle avoids taking care of all these issues.

When I take a plane, I put my 770 in flight mode, so I make sure that it
won't try to connect to my phone because of something I might do, like
opening the filemanager. 
But even if it was coming up from OFF state because an alarm triggers,
it wouldn't certainly establish any connection at all, unless I'm the
cause. And then it would be _my_ fault for not selecting flight mode.

> No, sorry, I still see the switch-off case as far too problematic to
> deal with, at least at this point. 
As simple as adding yet another boot reason.

> Since 90% of the system has to be
> booted again to signal an alarm (GUI + DSP sound) it will cause a lot of
> hassle to get this right. 
Only for actually playing the alarm but it's not really a big deal.
btw, what would you prevent from booting?

> The resume from suspend will be good enough as
> a start and can, if someone really wants to, be extended to wake from off.
I disagree and, as long as we are concerned with 770 hw, suspending
doesn't really improve things, as long as running applications are
implemented properly (meaning that they do not waste power).

> > 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.
> 
> Oh, great!
> Though the typical /proc/drivers/rtc is missing on the 770 so I guess
> that this 1710 RTC driver does not exist in the 770 kernel (build) yet.
> 
> 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
> 
> iD8DBQFDy55vJXeIURG1qHgRAgzzAJ9eqOn/GIPbqHUKekD8vyve/cmPaACeNKTl
> ugKTtw571ApbvGFg8Jw0EQw=
> =R+Ho
> -----END PGP SIGNATURE-----
-- 
Igor Stoppa (Nokia M - OSSO / Tampere)