There is no reason to keep the devices running 24/7 since they don't receive phone calls, and turning it off and on again just takes too long.
While i completely disagree on that to be useful for the generic user, I think it should be quite easy for you to set the idle timeout period, without the need to power on/off.
But i do keep mine always connected, so I have no clear recollection and I might be wrong.
They have a standby mode, but Nokia has botched softpoweroff since before the Diablo release, and fixes will be "fixed in Fremantle", i.e.: "never for you".
I don't know what you mean. The behavior referred to as softpoweroff in this thread has _never_ been planned to be delivered to the final user, since it was considered to be inferior and a lame workaround to real power management problems.
Seriously, we achieved suspend to ram as first step and it was kept as backup solution, just in case dynamic power management would prove to be too hard to reach. Which has never been the case.
So i don't understand where this expectation for a "fix" comes from.
Iirc an unofficial version was delivered, but what it does is basically cut the connections and disable wakeup sources other than the power button.
They have a standby mode, but Nokia has botched softpoweroff since before the Diablo release, and fixes will be "fixed in Fremantle", i.e.: "never for you".
Softpoweroff is not standby. It doesn't behave differently from Lock keys & screen (other than letting you activate it with a single keypress—I use a short-press on the power button—and allowing you to specific the offline mode behavior).
Also, the ARM processor in the tablets is quite capable of scaling back power consumption automagically.
Yes, this is why there's no standby mode, because when things aren't eating CPU, the tablet is effectively using no power (you can go about 30 days from full to empty with an idle tablet, and about 10-14 in a more average case). Unfortunately this doesn't work out in all cases. Toss in WiFi and you're down to about 4 days, toss in broken WiFi and make it about 24 hours. Adding some process taking 1% CPU and you're down to about a day, combine that with a broken router and you don't get much battery life at all.
Thankfully, though, idling works just great for most users.
Softpoweroff is not standby. It doesn't behave differently from Lock keys & screen (other than letting you activate it with a single keypress—I use a short-press on the power button—and allowing you to specific the offline mode behavior).
It doesn't work on my tablet. All sorts of erratic behaviour tend to occur when I set shortkeypress to softpoweroff, so I just gave up and do the powerbutton-centerDpadbutton duet. It's not as if I really care anymore...
Originally Posted by
Yes, this is why there's no standby mode, because when things aren't eating CPU, the tablet is effectively using no power (you can go about 30 days from full to empty with an idle tablet, and about 10-14 in a more average case). Unfortunately this doesn't work out in all cases. Toss in WiFi and you're down to about 4 days, toss in broken WiFi and make it about 24 hours. Adding some process taking 1% CPU and you're down to about a day, combine that with a broken router and you don't get much battery life at all.
Thankfully, though, idling works just great for most users.
This is -- partly -- why softpoweroff was so useful. In its default behaviour it would cut all wireless connections as well as locking screen and keys and putting the tablet into "standby" (i.e.: allowing the OMAP to throttle back nicely).
Of course, since it "was never meant for endusers", Nokia really doesn't have to care about it, right. Right? I mean, who am I to think that this Nokia tablet ecosystem was supposed to be an open thingie? It's all a spoof really.
Consider this scenario: you browse the web, you go to a website with flash ads and leave the window open. You lock it, put it in your pocket, 4 hours later it is dead.
Or this, more likely scenario, you disable flash to improve performance, you go to iGoogle, which autorefreshes every few minutes. Lock it, put it in your pocket. 6 hours later it is dead.
Suspend to RAM might be a lame workaround, but at least it actually works.
Wouldn't it be good to send SIGSLEEP to userspace processes when the user locks the tablet?
That way badly written programs wouldn't be able to eat away battery while idle.
Wouldn't it be good to send SIGSLEEP to userspace processes when the user locks the tablet?
That way badly written programs wouldn't be able to eat away battery while idle.
I would recommend you to follow the discussion on the linux-pm mailing list about this subject.
Android folks are coming up with similar arguments but so far have had little success.
I would recommend you to follow the discussion on the linux-pm mailing list about this subject.
Android folks are coming up with similar arguments but so far have had little success.
I certainly don't think this should be done in the kernel, but I've been repondering a daemon which would receive DBUS notifications (locked screen etc.) and, after a configurable timeout, start SIGSLEEPing processes with a .desktop file. A particular key in the .desktop could disable the feature (e.g. for IM clients). Things in the foreground could be slept after the ones in the background (which might start sleeping even whilst the device is unlocked).
However, I then start thinking about how annoying it already is to start loading a complex site, lock the screen, walk downstairs and the load has been effectively frozen by that operation, until I unlock the device.
Certainly, this thread has shown that the utopia of an always-on, long-battery life device is out of the reach of some users (based on the AP they connect to or software they install) and far too hard to debug when the device is dead in the morning. A more forceful sleep for user-space apps may be a pragmatic solution to the problems.
