Active Topics
-
Porting apps to Leste (29)
to Maemo 7 / Leste by Arno_11 - 2 days, 18 hrs ago -
Install Fonts in N900 (68)
to Maemo 5 / Fremantle by teroyk - 3 days, 21 hrs ago - more...
 |
|
2009-03-01
, 19:35
|
|
Posts: 198 |
Thanked: 273 times |
Joined on Jan 2006
@ Helsinki, Finland
|
#482
|
Originally Posted by Karel Jansens
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.
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".
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.
Which makes it a softpoweroff spoof.
| The Following 5 Users Say Thank You to igor For This Useful Post: | ||
 |
|
2009-03-01
, 22:23
|
|
Posts: 5,478 |
Thanked: 5,222 times |
Joined on Jan 2006
@ St. Petersburg, FL
|
#483
|
Originally Posted by Karel Jansens
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).
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".
Originally Posted by Karel Jansens
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.
Also, the ARM processor in the tablets is quite capable of scaling back power consumption automagically.
Thankfully, though, idling works just great for most users.
__________________
Ryan Abel
Ryan Abel
 |
|
2009-03-02
, 00:08
|
|
Posts: 3,220 |
Thanked: 326 times |
Joined on Oct 2005
@ "Almost there!" (Monte Christo, Count of)
|
#484
|
Originally Posted by GeneralAntilles
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...
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).
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.
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.
__________________
Watch out Nokia, Pandora's box has opened (sorta)...
I do love explaining cryptic sigs, but for the impatient: http://www.openpandora.org/
Watch out Nokia, Pandora's box has opened (sorta)...
I do love explaining cryptic sigs, but for the impatient: http://www.openpandora.org/
|
|
2009-03-02
, 05:40
|
|
Posts: 214 |
Thanked: 30 times |
Joined on Jan 2008
|
#485
|
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.
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.
 |
|
2009-03-02
, 07:45
|
|
Posts: 3,404 |
Thanked: 4,474 times |
Joined on Oct 2005
@ Germany
|
#486
|
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.
That way badly written programs wouldn't be able to eat away battery while idle.
 |
|
2009-03-02
, 08:42
|
|
Posts: 3,790 |
Thanked: 5,718 times |
Joined on Mar 2006
@ Vienna, Austria
|
#487
|
I might want applications to run at full speed when I lock the screen to prevent accidental input.
It's a good idea to provide ways to manually influence the idle state/power consumption. Just don't automatically tie it to "lock".
It's a good idea to provide ways to manually influence the idle state/power consumption. Just don't automatically tie it to "lock".
|
|
2009-03-02
, 10:15
|
|
Posts: 198 |
Thanked: 273 times |
Joined on Jan 2006
@ Helsinki, Finland
|
#488
|
Originally Posted by pycage
I would recommend you to follow the discussion on the linux-pm mailing list about this subject.
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.
Android folks are coming up with similar arguments but so far have had little success.
|
|
2009-03-02
, 13:03
|
|
Posts: 237 |
Thanked: 167 times |
Joined on Feb 2007
@ Powell, OH
|
#489
|
Nokia released the Alpha Maemo SDK today, so they must be coming out of hibernation 
http://maemo.org/
http://maemo.org/
 |
|
2009-03-02
, 13:37
|
|
Posts: 2,535 |
Thanked: 6,681 times |
Joined on Mar 2008
@ UK
|
#490
|
[SIGSLEEP for userspace apps]
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.
Originally Posted by igor
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).
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.
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.
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
| The Following 2 Users Say Thank You to Jaffa For This Useful Post: | ||
 |
| Tags |
| blurry photos, fud, funny farm, haiku, hibernation, not the droids, picnic baskets, straightjacket, trollosaurus rex, what competition? |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 14:40.
But i do keep mine always connected, so I have no clear recollection and I might be wrong.