The Suspend Functionality

[Tuxedomask29]

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

This sounds better than suspend to me in most cases. It sounds like it will act more like the DS, when the lid is closed it stops, the lid opens it resumes immediately. I like this idea a lot! One question though, let's say you were in the middle of a game on the N64 Emulator and closed the lid, I know you couldn't try to pause the game with the script but how would it respond in this case? Game would just get really slow with processor turned down, screen would go dark, and sound would turn off???

 

[Tor]

For me, suspend is a HUGE convenience that is fairly important. Being able to open this up quickly and check something on the web real quick, etc instead of using a full computer. For netbook like functionality, the suspend feature is very important.

No, suspend is not important at all, for what you list. I do all of that with my N800, and it doesn't suspend. It's always on, but it uses very little power. In addition, I'm getting notified by arriving email, Skype calls come in, I hear a little 'bing' when someone connects for a chat, my RSS reader gets updated, the weather applet.. and there's more. With suspend to RAM nothing of this would work. The Pandora can be an "always on" device, just like the Nokia tablets. Maybe it's just that those here coming from desktop/laptop are not yet used to this paradigm.. it'll come though! The Pandora has the potential to be a fantastic "always on" device due its huge battery (compared to other "always on" devices). This is what the OMAP SoC is designed for.

 

[mali]

^That description is to the point, nothing to add

 

[lulzfish]

One question though, let's say you were in the middle of a game on the N64 Emulator and closed the lid, I know you couldn't try to pause the game with the script but how would it respond in this case? Game would just get really slow with processor turned down, screen would go dark, and sound would turn off???

Applications will have to be written so that they catch the lid sensor events. What's the API going to be like for that?

 

[zhasha]

Applications will have to be written so that they catch the lid sensor events. What's the API going to be like for that?

Might as well be a single callback. Alternatively it could be a DBUS message but I find that to be a bit overkill for most C apps

 

[dflemstr]

Applications will have to be written so that they catch the lid sensor events. What's the API going to be like for that?

Might as well be a single callback. Alternatively it could be a DBUS message but I find that to be a bit overkill for most C apps

Nonsense. D-BUS for the win! I'm wondering, actually, why the pnd discovery daemon isn't a D-BUS daemon...

But now I'm wondering why you don't use HAL directly for this... Why write a script system and whatnot when you can use HAL, or even udev, or even friggin ConsoleKit if you want to?

 

[zhasha]

Nonsense. D-BUS for the win! I'm wondering, actually, why the pnd discovery daemon isn't a D-BUS daemon...

But now I'm wondering why you don't use HAL directly for this... Why write a script system and whatnot when you can use HAL, or even udev, or even friggin ConsoleKit if you want to?

HAL isn't used because it's deprecated in favor of udev and DeviceKit-disks. It's nothing against DBUS for what I was proposing, it's just that most applications on the linux platform is written in C, and maintaining a lot of DBUS code in order to intercept one meager call is a lot of unnecessary work. That said, if it were to merge into a truckload of other events under a common org.pandora something, it'd be fine. no, not fine, more like perfect.

 

[cosurgi]

personally I'll be installing tux-on-ice. It's twice faster than uswsusp.

 

[cosurgi]

[quote name='lulzfish' date='26 November 2009 - 02:39 PM' timestamp='1259239152' Applications will have to be written so that they catch the lid sensor events. What's the API going to be like for that?
[/quote]

uswsusp, tux-on-ice dont need any API for that except for what is already there: `kill -SIGSTOP $PID` ; kill -SIGCONT $PID`. User level apps don't need to know that suspend is happening.

 

[Alec]

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

This is pretty much the description of acpid!

Closing the lid should generate an event for acpid to pick up and execute a corresponding command. Here's my /etc/acpid/events/lm_lid as an example:

event=button[ /]lid
action=/etc/acpi/actions/lm_lid.sh %e

Please don't reinvent the wheel!

 

[laurencevde]

Eehm, I think acpi is a bit x86-only...

 

[Monk]

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.

Lots of head nodding here, although the bit I have put in boldface is one of my background worries with the Pandora - not on this topic specifically, but more generally that something *I* want it to do will get dropped, somewhere along the line, as no-one is desperate enough AND skillful enough to get it going.

Decent end-user easy-peasy WiFi was one such feature, for example, and I believe DJWillis has that done already

I think:

No, suspend is not important at all, for what you list. I do all of that with my N800, and it doesn't suspend. It's always on, but it uses very little power. In addition, I'm getting notified by arriving email, Skype calls come in, I hear a little 'bing' when someone connects for a chat, my RSS reader gets updated, the weather applet.. and there's more. With suspend to RAM nothing of this would work. The Pandora can be an "always on" device, just like the Nokia tablets. Maybe it's just that those here coming from desktop/laptop are not yet used to this paradigm.. it'll come though! The Pandora has the potential to be a fantastic "always on" device due its huge battery (compared to other "always on" devices). This is what the OMAP SoC is designed for.

probably has a lot of bearing on this issue. Before I had a pocket pc I had no idea I had a use for such a thing - by the time it died I realised I desperately NEEDED such a thing as my usage patterns had changed dramatically to make use of how it could benefit me that other belongings hadn't. So I ordered a Pandora...

...but I digress. those of us coming from a background of not owning a Pandora may WELL find that using it will evolve new usage patterns in us, that actually enhance the way we do stuff, rather than forcing it into a netbook mould.

 

[WizardStan]

What I'm thinking is that someone could cobble together some kind of ZOMGEMERGENCYLASTDITCHEFFORTNOCHANCETOSURVIVEMAKEYOURTIME kinda thing where it suspends everything (either to RAM or SD) regardless of whether the drivers will recover or not. It only kicks in when the battery really doesn't have enough power to keep anything alive, like 30 seconds to total failure, but that 30 seconds is enough to keep the ram alive for a couple of hours while you find a power outlet or USB port. I'm thinking about times when you might be typing away at something fairly important, not realize the battery is so low, and *bam* it goes down. You can plug it in, bring it back, a little warning pops up "Recovered from low battery alert. System may be unstable. Save all work and reboot", so you save your work and reboot.
So long as the screen, keyboard, and filesystem can recover after such a suspend, it doesn't really matter what anything else does; you need just enough functionality to save what you were working on.
Put such functionality in place, and someone will start to work on fixing those things that don't recover properly and make the system unstable. That's the best part of open source, someone else annoyed with how something goes will do the work to fix it for you eventually. IF it's worth fixing, that is.

 

[dflemstr]

What I'm thinking is that someone could cobble together some kind of ZOMGEMERGENCYLASTDITCHEFFORTNOCHANCETOSURVIVEMAKEYOURTIME kinda thing where it suspends everything (either to RAM or SD) regardless of whether the drivers will recover or not. It only kicks in when the battery really doesn't have enough power to keep anything alive, like 30 seconds to total failure, but that 30 seconds is enough to keep the ram alive for a couple of hours while you find a power outlet or USB port. I'm thinking about times when you might be typing away at something fairly important, not realize the battery is so low, and *bam* it goes down. You can plug it in, bring it back, a little warning pops up "Recovered from low battery alert. System may be unstable. Save all work and reboot", so you save your work and reboot.
So long as the screen, keyboard, and filesystem can recover after such a suspend, it doesn't really matter what anything else does; you need just enough functionality to save what you were working on.
Put such functionality in place, and someone will start to work on fixing those things that don't recover properly and make the system unstable. That's the best part of open source, someone else annoyed with how something goes will do the work to fix it for you eventually. IF it's worth fixing, that is.

*implements feature*
*drains battery until there are only 30 sec remaining*
Pandora: Now suspending, please stand by
Me: Aww, gotta find a power outlet
*finds a power outlet*
Pandora: KERNEL PANIC: cold restarted module unimportant_led_driver.ko tried to write to 0xCAFEBABE which is mmaped and owned by sgx_dri.ko! Both modules are now corrupt.
*reboots*
*facepalms*

 

[WizardStan]

*implements feature*
*drains battery until there are only 30 sec remaining*
Pandora: Now suspending, please stand by
Me: Aww, gotta find a power outlet
*finds a power outlet*
Pandora: KERNEL PANIC: cold restarted module unimportant_led_driver.ko tried to write to 0xCAFEBABE which is mmaped and owned by sgx_dri.ko! Both modules are now corrupt.
*reboots*
*facepalms*

Hey, at least it had a chance, and now you know unimportant_led_driver needs some tweaking. You've got the source, so get to it.
sudo get to it

 

[Tor]

Just get emacs running and write your stuff there, it'll keep a backup for you.
(maybe not the very last word you wrote, but it updates to a backup file regularly)

 

[dflemstr]

You've got the source, so get to it.

I think that that's what djwillis & co. claim will take too much effort, it being too much of a time sink etc. because *all* modules behave differently if they are resumed compared to when they are cold started, and will thus need changing...

 

[Tor]

As for the low battery emergency case, my N800 has a little battery monitor daemon which starts popping up a warning (and plays a little sound) when battery level gets low. At that point there's still lot of time to finish what I'm doing and either shut down or go find a charger. A daemon like that is easy, much simpler than putting together a suspend feature. It needs a way to actually monitor the battery level of course, but without that you wouldn't be able to make an emergency suspend feature either.

 

[WizardStan]

I think that that's what djwillis & co. claim will take too much effort, it being too much of a time sink etc. because *all* modules behave differently if they are resumed compared to when they are cold started, and will thus need changing...

For a perfect suspend/resume, yes. I'm suggesting that we can fix just enough that it limps along enough for you to save whatever you were doing when it recovers before rebooting.

 

[javaJake]

This discussion reminds me why I tell people "never, ever use the hibernate button in Linux." Ubuntu (and their unlimited amount of resources) launched a concerted effort to make hibernation work better in Linux, but I think it's going to be like video drivers: we'll be forever catching up until the hardware manufacturers finally recognize the need for support.

We might have a good chance of finally stabilizing hibernation for this hardware, but due to our small size I think it'll be forever buggy, and I don't think OpenPandora should release a buggy, potentially data-losing feature.