Return from hibernation progress bar

[Nick Steeves]

For Jaunty, it would be really nice if we could have a progress bar to show the user how much longer they need to wait. It's non-essential, functionally, but I think that the feeling of a "professionally polished system" would be much improved with this feature.

[Nick Steeves (nick-0)]

Oops, sorry, I meant to write "Karmic" instead of "Jaunty"!

[fermulator (fermulator)]

Well, it should be for both! :-)

[Nick Steeves (nick-0)]

:-) Cool! The primary reason I think this progress-bar is worthwhile is that people have more and more RAM in their computers, and they're doing more with them, and Ubuntu provides the assurance that their machine state will be correctly restored when they return from hibernation, so the hibernation image tends to be quite large; and as most people use spinning disks, the resume process entails moving a gigabyte or two, which is anything but instant.

I'm not sure how the levels of kernel and pm-utils interact, but it seems like the problem can be solved fairly simply...it's more architecture/planning than tricky algorithm.

1. Either ramsize or imagesize, in kilobytes, should be stored at the end of image creation (I think this is where/when it would go)
1.5 I'm not sure if it's possible, but seems like it might be slightly faster to have this information in front of the image, on the swap partition (but this would require a kernel patch...)
2. I'm not sure when/where it would be most efficient to convert the kilobytes to however many units the existing (unused) progress bar, during suspend/resume.
4. It seems more efficient to read in the size as we build the image; when we restore, it might be faster to just read in this number?
5. Alternatively does kernel might have a function that returns how many blocks/bytes/kilobytes has been restored -- if so, maybe we should use it?
5.5 Otherwise we'll need to patch the kernel, or restore through a pipe of some kind. This pipe is more in pm-utils land than a kernel patch. ;-)
6. The first example that comes to mind, as an efficient way to monitor status, is the ^\ (SIGQUIT) output of "star"....well, this is probably more like the kernel function approach. The way "buffer" works is more pipe-like.
6.5 I'm not sure which way is more likely to accommodate the eventual switch to something like suspend2.
7. the usplash code can handle things from here, one it has a maximum limit, numbers for a progress update, and -- possibly -- touch of arithmetic to change a big image size number into coarser-grained progress update values.

Does this sound like it's on the right track? Regrettably, I only have a bit of sh and C++ experience, and not nearly enough to actually write this progress bar...But I'd love to help with prototyping and testing.

[Chow Loong Jin (hyperair)]

On Sat, 2009-06-20 at 18:25 +0000, sten wrote:
> :-) Cool! The primary reason I think this progress-bar is worthwhile
> is that people have more and more RAM in their computers, and they're
> doing more with them, and Ubuntu provides the assurance that their
> machine state will be correctly restored when they return from
> hibernation, so the hibernation image tends to be quite large; and as
> most people use spinning disks, the resume process entails moving a
> gigabyte or two, which is anything but instant.
>
> I'm not sure how the levels of kernel and pm-utils interact, but it
> seems like the problem can be solved fairly simply...it's more
> architecture/planning than tricky algorithm.
>
> 1. Either ramsize or imagesize, in kilobytes, should be stored at the end of image creation (I think this is where/when it would go)
> 1.5 I'm not sure if it's possible, but seems like it might be slightly faster to have this information in front of the image, on the swap partition (but this would require a kernel patch...)
> 2. I'm not sure when/where it would be most efficient to convert the kilobytes to however many units the existing (unused) progress bar, during suspend/resume.
> 4. It seems more efficient to read in the size as we build the image; when we restore, it might be faster to just read in this number?
> 5. Alternatively does kernel might have a function that returns how many blocks/bytes/kilobytes has been restored -- if so, maybe we should use it?
> 5.5 Otherwise we'll need to patch the kernel, or restore through a pipe of some kind. This pipe is more in pm-utils land than a kernel patch. ;-)
> 6. The first example that comes to mind, as an efficient way to monitor status, is the ^\ (SIGQUIT) output of "star"....well, this is probably more like the kernel function approach. The way "buffer" works is more pipe-like.
> 6.5 I'm not sure which way is more likely to accommodate the eventual switch to something like suspend2.
> 7. the usplash code can handle things from here, one it has a maximum limit, numbers for a progress update, and -- possibly -- touch of arithmetic to change a big image size number into coarser-grained progress update values.
>
> Does this sound like it's on the right track? Regrettably, I only have
> a bit of sh and C++ experience, and not nearly enough to actually write
> this progress bar...But I'd love to help with prototyping and testing.
>

Actually I've got a patch for this, which provides uswsusp with usplash
support. Unfortunately, I keep running into an issue with uswsusp where
it keeps hanging at the end of the resume process. It's possible to
workaround by using Alt+SysRq+E at that part though. A patched package
for Karmic is available in one of my PPAs (bugfixes). Feel free to test
it and work on it if you feel up to it.

--
Regards,
Chow Loong Jin

[Nick Steeves (nick-0)]

Chow, I didn't have any luck when I tested your uswusp work -- maybe uswusp (or the current state of Karmic, when I tested it) just doesn't like my hardware...

Disappointing as it is that Ubuntu is apparently not going to replace usplash with Plymouth, it at least means that implementing this progress bar in usplash won't be wasted work!

[Nick Steeves (nick-0)]

I recently installed took Slackware for a spin just for kicks. What I noticed was that the Linux kernel *already* outputs resume from hibernate status, as a percentage.

Something like:

Resuming from hibernate: 15%

The 15% redraws over itself. I imagine that resume from hibernate exports this value, so we should be able to hook into it for said progress bar. Chow, is this how uswusp works?