Now that FC5 has hibernate working for lots of people, how about we do something about the delay which currently is displayed as a black screen?
I click the hibernate button, and am presented with the black screen for about 30 seconds as my ram is swapped out to disk. At resume, I'm presented with a black screen until the desktop re-appears.
I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think that requires a patch to the kernel away from vanilla, so that might not be an option for fedora. Maybe rhgb could be used instead?
Has any work been done, or ideas discussed on this for fedora? Thanks.
Richard.
On Wed, 2006-03-22 at 12:30 +0000, Richard Hughes wrote:
Now that FC5 has hibernate working for lots of people, how about we do something about the delay which currently is displayed as a black screen?
Agreed that this isn't really ideal as it currently stands.
I click the hibernate button, and am presented with the black screen for about 30 seconds as my ram is swapped out to disk. At resume, I'm presented with a black screen until the desktop re-appears.
I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think that requires a patch to the kernel away from vanilla, so that might not be an option for fedora. Maybe rhgb could be used instead?
With the swsusp code currently in the kernel, there isn't really a way to do any sort of useful userspace stuff. Also, rhgb has the downside of being X based which tends to hit "interesting" corner cases and bugs. All the options here kind of suck :-/
Has any work been done, or ideas discussed on this for fedora? Thanks.
Nothing of any substance. But this is a good way to start the discussion :-)
Jeremy
On Wed, 2006-03-22 at 10:44 -0500, Jeremy Katz wrote:
On Wed, 2006-03-22 at 12:30 +0000, Richard Hughes wrote:
I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think that requires a patch to the kernel away from vanilla, so that might not be an option for fedora. Maybe rhgb could be used instead?
With the swsusp code currently in the kernel, there isn't really a way to do any sort of useful userspace stuff. Also, rhgb has the downside of being X based which tends to hit "interesting" corner cases and bugs. All the options here kind of suck :-/
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
Richard.
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
I did some work on splashy a while back because I don't like rhgb and it is way faster. I wanted to submit it to extras but never found the time to actually submit it... if this is actually something people want and would like to have I am more then willing to wipe my spec into shape :)
- Andreas
On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
I did some work on splashy a while back because I don't like rhgb and it is way faster. I wanted to submit it to extras but never found the time to actually submit it... if this is actually something people want and would like to have I am more then willing to wipe my spec into shape :)
Might be a good alternative path to try out.
Rahul
fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
I did some work on splashy a while back because I don't like rhgb and it is way faster. I wanted to submit it to extras but never found the time to actually submit it... if this is actually something people want and would like to have I am more then willing to wipe my spec into shape :)
Might be a good alternative path to try out.
If you are looking at alternatives, the tool set Gentoo uses works really well and has a really nice featureset - we might be able to adapt that to our needs.
- David
On Sat, 2006-03-25 at 07:26 +0100, David Nielsen wrote:
fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
Might be a good alternative path to try out.
If you are looking at alternatives, the tool set Gentoo uses works really well and has a really nice featureset - we might be able to adapt that to our needs.
What do they use?
Richard.
lør, 25 03 2006 kl. 12:30 +0000, skrev Richard Hughes:
On Sat, 2006-03-25 at 07:26 +0100, David Nielsen wrote:
fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
Might be a good alternative path to try out.
If you are looking at alternatives, the tool set Gentoo uses works really well and has a really nice featureset - we might be able to adapt that to our needs.
What do they use?
http://dev.gentoo.org/~spock/projects/gensplash/
I think the developer aims to fix one of my top hated things about rhgb, the fact that it displays ugly kernel messages between grub and loading the splash - I dunno doing that seems very unpolished to me.
- David
On Sat, 2006-03-25 at 14:49 +0100, David Nielsen wrote:
lør, 25 03 2006 kl. 12:30 +0000, skrev Richard Hughes:
On Sat, 2006-03-25 at 07:26 +0100, David Nielsen wrote:
fre, 24 03 2006 kl. 20:09 +0530, skrev Rahul Sundaram:
Might be a good alternative path to try out.
If you are looking at alternatives, the tool set Gentoo uses works really well and has a really nice featureset - we might be able to adapt that to our needs.
What do they use?
http://dev.gentoo.org/~spock/projects/gensplash/
I think the developer aims to fix one of my top hated things about rhgb, the fact that it displays ugly kernel messages between grub and loading the splash - I dunno doing that seems very unpolished to me.
Whats wrong with doing something with the framebuffer (like this) before we do the hibernate:
fbi -a -1 --noedit -d /dev/fb0 -vt 7 /usr/share/backgrounds/images/default.png --noverbose
in pm-hibernate or something. Doing this makes my X not come back after suspending, but I may be being a moron.
Richard.
On Sat, 2006-03-25 at 14:54 +0000, Richard Hughes wrote:
Whats wrong with doing something with the framebuffer (like this) before we do the hibernate:
Well, one major problem is the fact that fbcon and X do not get along on some hardware. In particular, using rivafb and native X nv together is a guaranteed system lockup on all nVidia hardware I've ever tried it on.
Can't really use framebuffer for anything until this is worked out.
Seems to me you could just stick to good old VGA though. (svgalib...) Or maybe just do graphics in textmode... (hint: change the font...)
2006/3/26, Callum Lerwick seg@haxxed.com:
On Sat, 2006-03-25 at 14:54 +0000, Richard Hughes wrote:
Whats wrong with doing something with the framebuffer (like this) before we do the hibernate:
Well, one major problem is the fact that fbcon and X do not get along on some hardware. In particular, using rivafb and native X nv together is a guaranteed system lockup on all nVidia hardware I've ever tried it on.
Can't really use framebuffer for anything until this is worked out.
Seems to me you could just stick to good old VGA though. (svgalib...) Or maybe just do graphics in textmode... (hint: change the font...)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQBEJcdgI3BVKRcrX7cRAjk8AKDCrreDM3GXKsBWXJZp5J4sfzaE0gCZAS1r YCAHmGldC1m2rrWAgq47WKc= =kzsw -----END PGP SIGNATURE-----
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
same with nvidiafb btw. if you got a newer card nvidiafb works quite better than the old rivafb.
On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
I did some work on splashy a while back because I don't like rhgb and it is way faster. I wanted to submit it to extras but never found the time to actually submit it... if this is actually something people want and would like to have I am more then willing to wipe my spec into shape :)
It looks like splashy uses directfb which then requires fbdev. fbdev + accelerated X servers often ends up being a recipe for things to break in odd and "exciting" ways :-/
Jeremy
On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
I did some work on splashy a while back because I don't like rhgb and it is way faster. I wanted to submit it to extras but never found the time to actually submit it... if this is actually something people want and would like to have I am more then willing to wipe my spec into shape :)
I can't comment on rhgb, as I spend most of my time waiting for a suspend or resume, and so I only see rhbg once a week or so.
If you've got a spec already, or a src.rpm post the link and we can give it a try.
Thanks,
Richard.
On Fri, 2006-03-24 at 01:25 +0100, Andreas Bierfert wrote:
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
I did some work on splashy a while back because I don't like rhgb and it is way faster. I wanted to submit it to extras but never found the time to actually submit it... if this is actually something people want and would like to have I am more then willing to wipe my spec into shape :)
http://splashy.alioth.debian.org/wiki/doku.php
Hmm.. No kernel patches and no X... If you submit it you'll get interest from me at least :-)
-Toshio
On Fri, 2006-03-24 at 09:17 -0800, Toshio Kuratomi wrote:
http://splashy.alioth.debian.org/wiki/doku.php
Hmm.. No kernel patches and no X... If you submit it you'll get interest from me at least :-)
Same here, I'd be really interested in a packaged version.
On Sat, 25 Mar 2006 11:06:15 -0500 Dimi Paun dimi@lattica.com wrote:
On Fri, 2006-03-24 at 09:17 -0800, Toshio Kuratomi wrote:
http://splashy.alioth.debian.org/wiki/doku.php
Hmm.. No kernel patches and no X... If you submit it you'll get interest from me at least :-)
Same here, I'd be really interested in a packaged version.
Ok, here it goes: http://fedora.lowlatency.de/review/splashy/
This is _known_ to have bugs like possibly not switching to X. Consider this the first real build packages ;) I know that the spec is still ugly and not checked for BR and such, this will be cleaned up of course but it at least gives you an impression about splashy :) Please let me know if it works and maybe on what hardware it does work/not work so we can add a README.Fedora later on.
I hope I can fix some of the major bugs (trying an upgrade to svn version atm to see what is resolved an what not)
To get it to work your framebuffer needs to be activated (vga=0x317).
Don't try to build your own package as directfb is blocking this from being build correctly (see #186521).
- Andreas
Andreas Bierfert wrote:
Ok, here it goes: http://fedora.lowlatency.de/review/splashy/
/usr/sbin/splashy: error while loading shared libraries: libdirectfb_fbdev.so: cannot open shared object file: No such file or directory
On Tue, 28 Mar 2006 12:29:25 -0600 Ian Pilcher i.pilcher@comcast.net wrote:
/usr/sbin/splashy: error while loading shared libraries: libdirectfb_fbdev.so: cannot open shared object file: No such file or directory
Hu yes :) that is related to the directfb bug... wait I will upload a fixed directfb version to the same location...
- Andreas
On Tue, 2006-03-28 at 21:44 +0200, Andreas Bierfert wrote:
On Tue, 28 Mar 2006 12:29:25 -0600 Ian Pilcher i.pilcher@comcast.net wrote:
/usr/sbin/splashy: error while loading shared libraries: libdirectfb_fbdev.so: cannot open shared object file: No such file or directory
Hu yes :) that is related to the directfb bug... wait I will upload a fixed directfb version to the same location...
This is the latest error I get when trying to run splashy...
[root@scrappy init.d]# splashy test [root@scrappy init.d]# FATAL: video.c <440>: (#) DirectFBError [DirectFBCreate (&video->dfb)]: General I/O error!
[root@scrappy init.d]# rpm -qa | grep splashy splashy-0.1.6-1 [root@scrappy init.d]# rpm -qa | grep direct directfb-0.9.24-6 directfb-devel-0.9.24-6
2006/3/29, Mike Chambers mike@miketc.com:
On Tue, 2006-03-28 at 21:44 +0200, Andreas Bierfert wrote:
On Tue, 28 Mar 2006 12:29:25 -0600 Ian Pilcher i.pilcher@comcast.net wrote:
/usr/sbin/splashy: error while loading shared libraries: libdirectfb_fbdev.so: cannot open shared object file: No such file or directory
Hu yes :) that is related to the directfb bug... wait I will upload a fixed directfb version to the same location...
This is the latest error I get when trying to run splashy...
[root@scrappy init.d]# splashy test [root@scrappy init.d]# FATAL: video.c <440>: (#) DirectFBError [DirectFBCreate (&video->dfb)]: General I/O error!
[root@scrappy init.d]# rpm -qa | grep splashy splashy-0.1.6-1 [root@scrappy init.d]# rpm -qa | grep direct directfb-0.9.24-6 directfb-devel-0.9.24-6
-- Mike Chambers Madisonville, KY
"It's only funny until someone gets hurt, then it's hilarious!"
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
same problem here
On Wed, 29 Mar 2006 17:49:40 +0200 "Rudolf Kastl" che666@gmail.com wrote:
same problem here
Hm, thats strange... so I never tried that... does it work during bootup?
I think tomorrow after my exam I will package up latest svn to see where we go... seems like lots of work has already been put in since this release.
- Andreas
2006/3/30, Andreas Bierfert andreas.bierfert@lowlatency.de:
On Wed, 29 Mar 2006 17:49:40 +0200 "Rudolf Kastl" che666@gmail.com wrote:
same problem here
Hm, thats strange... so I never tried that... does it work during bootup?
negative on that houston :)
I think tomorrow after my exam I will package up latest svn to see where we go... seems like lots of work has already been put in since this release.
- Andreas
-- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert@lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Thu, 2006-03-30 at 10:55 +0200, Andreas Bierfert wrote:
Hm, thats strange... so I never tried that... does it work during bootup?
I think tomorrow after my exam I will package up latest svn to see where we go... seems like lots of work has already been put in since this release.
Nope, doesn't work on boot neither.
On Thu, 2006-03-30 at 04:08 -0600, Mike Chambers wrote:
On Thu, 2006-03-30 at 10:55 +0200, Andreas Bierfert wrote:
Hm, thats strange... so I never tried that... does it work during bootup?
I think tomorrow after my exam I will package up latest svn to see where we go... seems like lots of work has already been put in since this release.
Nope, doesn't work on boot neither.
Has 0.1.8 been released yet, or at least a fix to the latest problem for Fedora Core 5?
On Tue, 28 Mar 2006 12:29:25 -0600 Ian Pilcher i.pilcher@comcast.net wrote:
/usr/sbin/splashy: error while loading shared libraries: libdirectfb_fbdev.so: cannot open shared object file: No such file or directory
Ok i386/x86_64 versions of the fixed directfb package can be found at the same url now.
- Andreas
On Wed, 2006-03-22 at 20:26 +0000, Richard Hughes wrote:
On Wed, 2006-03-22 at 10:44 -0500, Jeremy Katz wrote:
On Wed, 2006-03-22 at 12:30 +0000, Richard Hughes wrote:
I think ubuntu use bootsplash [http://www.bootsplash.org/] but I think that requires a patch to the kernel away from vanilla, so that might not be an option for fedora. Maybe rhgb could be used instead?
With the swsusp code currently in the kernel, there isn't really a way to do any sort of useful userspace stuff. Also, rhgb has the downside of being X based which tends to hit "interesting" corner cases and bugs. All the options here kind of suck :-/
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
But _much_ more risky. We switch away from X because being in graphical mode tends to make suspend/resume break horribly. This would likely cause the same failures.
On Wed, 22 Mar 2006 20:26:25 +0000 Richard Hughes hughsient@gmail.com wrote:
Even displaying a static bitmap (a-la-windows 98) would be better than the black we have now. Not sure if that makes it simpler.
Seems my mail from yesterday did not make it to the list:
I worked on splashy a while back which is really nice and a lot faster then rhgb... I wanted to submit it to extras but never found the time. Reading your post inspired me to work on it again so I will publish something not long from now :)
- Andreas
I would just like to say, after extensively using both suspend2 and whatever the current stock suspend is, suspend2 is vastly superior. Its much faster, it provides better feedback (userui), its more interactive. You can cancel a suspend. (which would have been great with the suspend loop bug I hit...) If you boot with a mismatching kernel, suspend2 will warn you and ask you before it blows away your suspend image, giving you a chance to restart with the right kernel.
Of course, Fedora shouldn't merge suspend2. Upstream should. And apparently the answer to that is "Pavel says no". :P
On Fri, 2006-03-24 at 18:57 -0600, Callum Lerwick wrote:
loop bug I hit...) If you boot with a mismatching kernel, suspend2 will warn you and ask you before it blows away your suspend image, giving you a chance to restart with the right kernel.
We could conceivably do something like this with what we have now -- the problem is that you can't (sanely) do it in the user's native language or keyboard layout :-/
Jeremy
devel@lists.stg.fedoraproject.org