The Suspend Functionality

What is more important for you?

  • Suspend

    Votes: 67 42.9%
  • UI

    Votes: 89 57.1%

  • Total voters
    156

Alec  said:
I can't vote on this because not working on the UI won't really make suspend arrive faster. Working on the UI is completely different from kernel hacking.

Exactly. I'm working on some scripts and theming the OS... and I can't code and definately not kernal hacking or driver fixing.
The rest of the devs fixes the bugs on the main OS at the moment so that we can release it at a working state.
Don't worry, there will be consequent updates and suspend will work some day :)

GPH didn't do a better job though - they have a half-working OS, not even released the current sourcecode, tons of bugs which could've been fixed since months and they have a real simple OS (no Suspend, not X, etc.).

Basically, they have a Linux which runs apps via a framebuffer and SDL. And even their SDL is buggy... Dingux for the Dingoo basically is better and has been developed within a few months by one person.

I'd love to get a better OS for the WIZ though... just one with fixed bugs.
 
Last edited:
hooray for false dichotomy.

I'd love to have both a nice UI and working Suspend. But I don't think this poll will have any bearing on either one of those.

I care slightly more about the Suspend since I expect to modify and/or replace the GUI pretty soon after I get it anyways... and I lack experience with writing device drivers so not something I could easily fix myself.

Edit: How long does it take to boot up? If it's already a quick boot-up (60sec or less) then the suspend functionality is significantly less of an issue for me.
 
if the tech is inbuilt within the system then i'm happy to wait for it to come.
the magnetic closure detection is in the pandora so im not bothered that the drivers arent set up (as long as down the line they will be working)

the UI is more important to me because thats what i'll be seeing every day i use the pandora, i cannot show off the pandora if the UI is rubbish.
 
One thing is that TI made OMAP3 power management extremely complicated. There is much more than peripheral driver suspend going on, take a look at this graph:

http://elinux.org/File:OMAP_PM_future.png
 
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

And yes: Booting time is below 60 Seconds.
 
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

And yes: Booting time is below 60 Seconds.
Whoa, 14 MHz... So the CPU basically won't be use any power, and the DSP and GPU will be off? Sounds "good enough".

Also, everybody's computers boot faster than mine... 1 minute for XP, 1 minute for Ubuntu, 2 for Vista.. my laptop must be slow or something.
 
Last edited by a moderator:
lulzfish said:
Also, everybody's computers boot faster than mine... 1 minute for XP, 1 minute for Ubuntu, 2 for Vista.. my laptop must be slow or something.

Just timed (out of curiosity) my old "surf/email" laptop, a Dell Latitude C610 (P3 1.0GHz, 1Gb RAM, 120GB HDD) running standard Ubuntu 9.10.
From cold start (push power button) it's about 45 seconds before I can insert username and password, and then it's about 1min 40 seconds (in total, from cold start) to start firefox (manually) and load this page (set as homepage) fully.

Timing a loging screen is rather silly, same as when the desktop "appears". I'm more interested in a tad more "real life" situation like "I want to check my email silly computer.. startup!!!"

As long as this is in the "1 to 1 1/2 minute" league for pandora (talking about beeing able to run firefox or so and connected) I'm not sure the real life "experience" will suffer so much.
The only real reason to go full suspend is simply to avoid the "I forgot to turn off" situation.
But again, with my n800 it happend only a few times.
If there is some kind of script that when you close the lid you scale back everything and turn BT/wifi off (or can make it do this) I can get along quite nicely.
 
Last edited by a moderator:
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

I think that would be great for a first release.
 
Last edited by a moderator:
lulzfish said:
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

And yes: Booting time is below 60 Seconds.
Whoa, 14 MHz... So the CPU basically won't be use any power, and the DSP and GPU will be off? Sounds "good enough".

Also, everybody's computers boot faster than mine... 1 minute for XP, 1 minute for Ubuntu, 2 for Vista.. my laptop must be slow or something.

Anything <= 30 secs is fine for me. My Nokia N82 smart-phone takes that long to start for the first time. My laptop running Fedora Linux 11 takes 25 seconds.

Obviously I wouldn't complain if it was faster on the Pandora :)
 
Last edited by a moderator:
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

And yes: Booting time is below 60 Seconds.

I think that is all I wanted to hear... That way Pandora can sleep for weeks =]

Now can we please get our fancy and stable OS? =D
 
Last edited by a moderator:
notaz said:
One thing is that TI made OMAP3 power management extremely complicated. There is much more than peripheral driver suspend going on, take a look at this graph:

http://elinux.org/File:OMAP_PM_future.png
I think all OMAP3-related job is already done since we have Always Innovating Touch Book (doesn't it support suspending?).
 
Last edited by a moderator:
I think those who are seriously concerned about this could use an example from another similar device.
The Nokia 770 internet tablet was released with an only partially functional OS, with many many bugs.
The Nokia developers, and others who worked in the Maemo open source project, did a pretty good job getting the basics working prior to release of the device.
However, after about two weeks on the market, the hacking general public, and a very talented few who understood what was going on, quickly picked through the bugs and helped develop a much, much better OS release.

This will happen with the Pandora as well.
Any bugs released early on will get hammered to submission once more people have it in their hands.
And since the Pandora is a much more open platform than the Nokia, it will be much more interesting, I'm guessing.

Bring it on!
 
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.
As long as I can just shut the lid and save some battery life whilst I move around I'm good with this. I don't plan on going anywhere without an AC adapter very often.
 
Last edited by a moderator:
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

Whoa. So, we can code in bash/python what happens when the lid closes and stuff like that? That'd be brilliantly useful.
 
Last edited by a moderator:
javaJake said:
EvilDragon said:
Don't worry, we'll probably put a quick workaround in until we get real suspend.
Just a small script that switches off backlight, turns off as much hardware as it can and clock the CPU to 14MHz.
That should work pretty well for the beginning.

Whoa. So, we can code in bash/python what happens when the lid closes and stuff like that? That'd be brilliantly useful.

Check out /etc/acpi if you're on Linux ;)
 
Last edited by a moderator:
I'd prefer that the GUI developers embrace cryopid, so that games can be frozen to disk by the shell and defrosted later. This would mean that any game or emu can simply be state-saved to the SD card and restarted again later. So the shell could freeze the currently running executable, shut the machine down to total low-power state, and then when the user wants to, re-animate the frozen app again to pick up where it was left off. This would avoid a lot of hassles with s2ram and the Linux kernel and so on, and it would also mean that any app on Pandora can have save-states without having to implement them.

Cryopid is definitely worth investigating, anyway, imho.
 
Back
Top