[Bug 379673] Re: Return from hibernation progress bar
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? -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379673] Re: Return from hibernation progress bar
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! -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379673] Re: Return from hibernation progress bar
Well, it should be for both! :-) ** Changed in: pm-utils (Ubuntu) Status: New = Confirmed -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379673] Re: Return from hibernation progress bar
:-) 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 starwell, 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. -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 379673] Re: Return from hibernation progress bar
On Sat, 2009-06-20 at 18:25 +, 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 starwell, 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 -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379673] Re: Return from hibernation progress bar
Oops, sorry, I meant to write Karmic instead of Jaunty! -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379673] Re: Return from hibernation progress bar
** Package changed: ubuntu = pm-utils (Ubuntu) -- Return from hibernation progress bar https://bugs.launchpad.net/bugs/379673 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
