Os / Firmware Status?

[CodeTwister]

What happens (beside the slower clock) on the hardware side if the device is switched to "low power mode"? The WiFi should be off, but I guess the USB is still working? In this case I could plug in a GPS mouse and track the route with a Pandora in low power mode. Should be working for >24 hours (depending on the GPS power consumption). Interesting ...

 

[dflemstr]

QT is included.

Would this be the best way to write an application that runs on window- and launcher-mode Pandoras?

I don't think that Qt-embedded and Qt-x11 are binary-compatible to one another (but they might be), let alone both included in the default Pandora image...

That the low-fi mode on the Pandora uses the frame buffer instead of a bare bone X server will be the most annoying part of having the two modes.
(but I think that PND files have support for launching a temporary X server for individual apps, will have to check)

 

[verm71]

I think that should be customizable. Some may want WiFi, others not (e.g. what if you're playing MP3s from your local server over WiFi?). Some may want USB, some would rather not.

 

[WizardStan]

I think that should be customizable. Some may want WiFi, others not (e.g. what if you're playing MP3s from your local server over WiFi?). Some may want USB, some would rather not.

I'm going to guess that it is nothing more than a script which is called when the lid is closed, something like "ifconfig down; lcdoff; setcpu 10;" and a counter script called when the lid is opened "ifconfig up; lcdon; setcpu default;" or something like that. That'd be the way I do it, anyway. That way, you don't just have it do standard stuff, but maybe you want it to do something else before going down or coming back up: play a short MP3, send a text message, write to a log file, force savestate the N64 emulator, whatever.

 

[mali]

I'll search for some older quotes...

A true suspend mode means no alarm/wake etc so will often be undesirable.

Low power mode will likely be toggles by a script, run by a little driver app I hope to put together asap. Alarm proggies could call it, or the subtools for backlight/CPU control directly, so piece of cake. Mostly in libpnd already.

Jeff

Panda has a lot of cutting edge, so often poor djwillis and notaz are fixing bugs and sending fixes upstream But more to point, when it comes to sleep/suspend, it is actually an enormous amount of work going on in the kernel and OSthat people are not aware of (and fortuantely most of that infrastructure is already in place in the Linux kernel), but each active driver must be cleanly asked to suspend/hibernate, and awaken later. Applications in the OS must be notified of both events, USB must be re-established, etc and so on. So consider, if your kernel has 50 drivers in it, and any one of them is not perfect for suspend/hibernate, the operation will fail in funky ways. Considering this is not uncommon on desktop machines, it is a large task to address on a cutting edge handheld... triply so when the task involves figuring out other peoples drivers/patchlevels/bugs/etc. I've just not had the time to be able to get into such things, so I am forever impressed with djwillis and notaz taking the load on such things -- they have put _enormous_ time into such things. ie: This is where months get lost.. someone banging on bluetooth -- screw with this or that driver for a few days or weeks, switching versions to ensure some old driver version works with some kernel version, then patchign it up, looking for bugs etc, switchign to another driver, etc. Then wifi. then this, then that .. its a tonne of trial and error and time sink. Ah, if only it were just fixing a bit of well known code

So its not a 'suspend driver' that is a problem per se; it is suspending all the other drivers and waking them. Back a few months ago I was futzing with it and had dozens of issues, big drag Once launch happens and theres more eyeballs, maybe more hands can get in there We're all burnt out wrecks, can only do so many hours each week.. more hands may help (or turn into 'too many cooks in the kitchen'

Anyway, the firmware is in pretty good shape, we're just working on some cleanups and widgets, packaging this or that, themes as you can see, etc. Theres a few gotchas as ED listed (great post!), but a few thigns like suspend/hibernate are real PITAs, so don't underestimate how much pain has been put in there already

jeff

ED had the pretty cool idea of a 'low power mode' there, mentioned above; I'm going to make a little daemon to watch events like lid-open and lid-close (and some other stuff), and have it invoke scripts as a result; then we can have scripts disable the backlight, set the clock down, mess with drivers, all that stuff. Shoudl be a pretty easy and handy system .. close lid, screen goes off and cpu goes down. Change the scripts if you want to change the behaviour. (Heck, I could make it use the libpnd searchpaths, so scripts could be overridden based on SD cards and such, without altering firmware.)

Seems like a clever idea to me

(The same daemon will watch for Menu key and bring up a defined script, so you can define what happens at that point.)

jeff

I know of some work being done with the Beagleboard to lower the idle current to as little as possible. They say they have it down to 17mA right now which is pretty good. Pandora has more hardware that would need to be put into idle mode so let's double that and that would put the idle time at 123 hours. It's still just speculation, but these are the kinds of things being worked on slowly.

Note that this is different than suspending to RAM and turning everything off but the RAM. Off time would be much longer in that case but requires a larger software effort, likely community driven.

Extreme downclocking sounds like a good alternative to an actual suspend to ram, as it should be instant and still give huge power savings. Maybe even preferable in most circumstances.

If done right, it would look like the unit was being shut off and most users wouldn't even know! That's what the iPhone, N8xx devices and all of those do. If you ever put an ammeter in series with the charge path of an iPod/iPhone you will see that thing is constantly bouncing around with different current usage as things wake up and go right back to sleep. They probably don't suspend to RAM because of the complications Notaz speaks off. I can see this kind of faux suspend being done along the timeline ED is hoping for. A full suspend to RAM could take much longer to develop and might get abandoned when people are fine with 5-6 days on standby instead of something closer to two weeks. Still, it would be nice to have both in the long run.

Thread locked so no proper quote. This is from ED:

...But usually, you don't shut it down. When everything is finished, the Pandora can be lying around for approx. 10 days in suspend mode (which means instant-on) without being charged. So you basically only need to shutdown if you don't want to use it for the next few days...

A smartphone doesn't suspend either, otherwise it couldn't receive calls. The 10 days were a quick calculation with exactly such scripts, not with a real suspend mode.

 

[skeezix]

Pmenu can actually run with X11 or without, though theres an opengl performance different with X and without X, dependingon drivers and this or that and so on; we like the idea of pmenu-x11-opengl being the one in use, since then you can depend on X almost always being there, but I'm not as on top of that right now. (Christmas break == fried brain.)

libpnd (specifically pnd_run.sh) knows how to take care of a few situations (such as killing and restarting X around an app) and such, which makes things a lot easier.

As to low hibernate and suspend-to-ram -- the hardware supports it, its just a function of going through any provlematic drivers and fixing them up; to be specific -- if a driver doesn't support it or is broken, its broken for everyone else too, so other deives have the same problem, so its not like Pandora is unique in this regard.

jeff

WizardStan -- more or less right; pndevmapperd daemon sits around waiting for a few events (as configured in a conf file), one of which is lidclose/open; when lidclose happens, a script is fired off, which in turn can lower the cpu and turn off the lcd, or whatever it wants. (Same mechanism for handling the Pandora button.) A button script receives the duration the button was held (so it can react differently for a press versus hold), even.

 

[Grench]

WizardStan -- more or less right; pndevmapperd daemon sits around waiting for a few events (as configured in a conf file), one of which is lidclose/open; when lidclose happens, a script is fired off, which in turn can lower the cpu and turn off the lcd, or whatever it wants. (Same mechanism for handling the Pandora button.) A button script receives the duration the button was held (so it can react differently for a press versus hold), even.

Any chance of a secret close-without-suspend/depower by pushing one or both shoulder buttons at once while closing the lid? I can think of times when I'd want to close the lid without the device going into a standby type mode.

 

[skeezix]

ITs conf file run, essentially mapping a key/event to a script, so could be; right now its not really clever or versatile, but should be soon enough time permitting. ie: My goal with it always has been to ley you just specify some key and somethign to do with it, where most of the time you dont' do anything (let the apps and OS deal with it, who wants to map 'm' to anything?) But if you wanted to map triggers or something, makes sense, you can conf if as you see fit. So if not on launch, than soon after or anhytime someone wants to hack it up, its all open source

jeff

 

[SNESFAN]

Any chance of a secret close-without-suspend/depower by pushing one or both shoulder buttons at once while closing the lid? I can think of times when I'd want to close the lid without the device going into a standby type mode.

+1

like if you hit "up up down down left right left right b a start" on the refrigerator the light doesn't go out when you close the door

 

[fusion_power]

I don't care which methods are choosen to save battery time, I hope at least there will be a few. ^_^
I really hope for effective, dynamic auto-clocking of the Pandora, more important than suspend and hibernation-stuff. I think we don't need 500MHz to play Music or Browse through the web. Wifi/Bluetooth and/or SGX unit don't has to be enabled all the time and maybe there are a few more OMAP Hardware tricks to increase the Battery life.
I know that the Chipset-specs have alot of such features but I also know that the Pandora Devs don't have full access to these Features. Maybe they still can do something for the wellness of the Pandora Battery. I don't know if every software has to have an specific clocking or if the OMAP simply clocks what the App is needing. Maybe this has to be specified in the .pnd files, I just hope users don't have to clock everything per hand like it often was in old GP2X days.
So how smart is the Pandora OS in "smart clocking"?

 

[u9i]

Someone should put a cork in Craigs mouth! Being that obnoxious isn't the best way to lure customers.

 

[mali]

Humour?

 

[moxie]

Besides what fun is a open device if all the software is perfect and there's nothing left to hack when you buy it?

There's always something to hack. But fixing kernel drivers is too hard for an ordinary user and even for application programmer IMHO.

Yes, but see, that is the beauty of open source stuff. I certainly am an "ordinary user", and possibly you too, but the point is that some of those who get the pandora aren't. I won't hack kernel drivers, but since the source is available to look at for me, it is also available to look at for those buyers who are extraordinary users. So, in the end, things that are left to be hacked will be hacked upon, be it icon themes, fancy powerdown scripts or gnarly kernel modules.

 

[Monk]

Any chance of a secret close-without-suspend/depower by pushing one or both shoulder buttons at once while closing the lid?

Wouldn't that cut your fingertips off?

 

[Awakening]

Any chance of a secret close-without-suspend/depower by pushing one or both shoulder buttons at once while closing the lid?

Wouldn't that cut your fingertips off?

Not with the SHOULDER buttons

 

[GizmoTheGreen]

roflmao.

nice one.

 

[Gricey]

Someone should put a cork in Craigs mouth!

You know, I really misread that :lol:

 

[jonlad1]

How is the boot time coming along? IIRC ED said that they were gonna try to get that down....

 

[Sphinxter]

We get a 4000mAh+ battery so a low power mode should suffice, imo.

I will never be satisfied with such kind of workarounds instead of a true solution.

Having a larger battery wasn't a workaround, nor was low power mode. Suspend is useless on this kind of a device if your not using it the Pandora will either be off or charging. I for one would rather them skip "full suspend" all together and worry about truly pressing matters. Like overall look and feel.

Speak! I hope we never get the full suspend. Rather they be light sleepers and able to spot each other while in the pocket for some adhoc style network gaming.

 

[Sphinxter]

Someone should put a cork in Craigs mouth! Being that obnoxious isn't the best way to lure customers.

Go cram a cork in yourself with walnuts ugly style, the customer stated he would never be satisfied and since the customer is always right hopefully that fussy bitch will be satisfied with a full refund. What do you expect him to do, promise something he can't deliver like a chinese plastics factory?