Re: fbsplash: introducing fbplash in debian (howto)
On Sat, 30 Oct 2004 19:22:32 +0200, website <website_debian@tiscali.it> wrote:
> On Saturday 30 October 2004 17:47, Luis M wrote:
<snip>
> > * Go into "super silent" mode where fbsplash/debsplash would NEVER
<snip>
> Please contact the developers before send a message like this to the ml.
> How you must know, this "super-silent-mode" exists. It is done by a line in
> the config file.
Uh? Who? I'm sorry. Don't see why. We need people to help; and the
only way we can do this is by creating some interest. Letting others
know what we are doing makes this possible.
I didn't know super-silent is there. I have yet to find this. I read
the whole kernel patch and didn't see it.
In line 46 of the patch: (fbsplash-0.9-r6-2.6.8.1.diff)
+Kernel command line parameters
+------------------------------
+
+Framebuffer splash can be configured from the kernel command line by passing
+options in the following way: "splash=option1,option2".
+
+The following options are recognized:
+
+off - do not enable fbsplash after fbcon initialization; this is
+ default behaviour
+verbose - switch fbsplash to verbose mode after fbcon is initialized
+silent - switch fbsplash to silent mode after fbcon is initialized
+
+theme:<name> - use theme 'name' on the first console, default theme name
+ is 'default' (who'd have guessed?)
+
+Example - you want to get verbose splash with the theme 'tux' right after
+fbcon is up:
+ splash=verbose,theme:tux
+
+The userspace helper
Then in line 1220-1:
+ (fbsplash_mode == FB_SPLASH_MODE_SILENT) ? "s" : "v",
+ vc_cons[vc].d->vc_splash.theme,
Essentially only two args: verbose and silent.
Silent does not work for all systems. It always goes into verbose mode
for me and for others. We need to make this "supersilent" for these
systems. And that might mean patching the patch :-)
<snip>
> And not, it is fake. we are in 4!
> Me, you, Glyn and Mattew
fake == false ?
Well, so far Matt and I have been in #debsplash for many days... (and
yes you were away in vacation.) I get your point nonetheless.
> > The goal is to get this working with progressbar and all the initrc
> > stuff needed. Hopefully we won't need to patch any Debian inirc
> > scripts (like it used to be the case with buggy bootsplash).
> >
> Why do this?
> fbsplash is designed to work with the newest initramfs images.
I mean by initrc: /etc/init.d and /etc/rc*; and not /sbin/init or any
other binaries (just to be clear).
So, the goal should be to NOT patch or modify any of the existing
debian rc's. I know that for bootsplash this was needed, and perhaps
it would be easier for us to patch them than to write a patch that
handles this better.
As an example of what I mean, this is one way that this can definitely work:
1. admin downloads debsplash-utils and kernel-patch-debsplash
2. admin downloads kernel sources from kernel.org or debian's
kernel-source-* packages
3. admin re-compiles kernel after patching it with almost the same
.config file (copied from /boot/config-* or /proc/config.gz) and a
"make oldconfig" that's done by make-kpkg for you (or my own
interactive make-kpkg.sh for those who don't know much about how this
works; or don't care to know)
4. admin enables bootlogd in /etc/default/bootlog
5. admin generate initramfs with debsplash-utils
6. admin edits grub/lilo configuration files to pass the needed initrd
and kernel arguments to the kernel at boot time
7. reboots
What should happen then is:
1. system goes into supersilent mode with progressbar
2. debsplash takes over the screen (graphical mode) and it reads
/var/log/boot for current state of the boot progress. Then it updates
the progressbar accordingly.
3. if fsck is detected in boot log, then it creates another smaller
progressbar clearly label (System checking drive N). And it will do
this for all other fsck processes recursively
4. If at any point user gets desperate and hits F2, he/she will be
drop in the standard "verbose" mode
So, as you can see. There are ways to NOT patch the existing initrc
scripts from the debian init.d dir. We should do this. If this method
doesn't work, for whatever reason, then we must modify the patch so
that it reads this /var/log/boot file itself and "prints" something in
a file we can read /proc/debsplash /dev/debsplash, or any other
special file. You name it.
<snip>
> It is fake again. To implements it we need to hack the standard init process
Not true. Refer to my arguments above. There is NO need to change the
initrc scripts. Perhaps only to introduce a new one that will need to
go in /etc/rcS.d with a very early number (but not too early). And
this will update our progressbar as needed.
> > whatever we do to it will be passed on upstream (they are working
> > closely with us). gensplash code and build system is UGLY.
>
> Yes it should be "ugly" but remember that without gensplash, debsplash is
> nothing
Hey, i'm not being ungrateful here :-) I'm glad spock took time to
port bootsplash. We have been talking about this for months, we never
got the process started. For one, I'm not a "kernel hacker" and I'm
mostly a GUI/C++ guy who happens to like simplicity (yes, I'm a Mac
user too; in case somebody says: get a mac). However, if I need to
learn about how the kernel works, then I will. And using gensplash as
a starting point is not bad. However, after being coding in C for some
time (in many other projects that I'm currently involve). I see the
ugliness of the current fbsplash kernel patch. I'll do my best to make
it clean, simple and feature rich.
> > I'm doing
> > my best to use -dev packages from Debian and clean up the code as much
> > as possible.
--
----)(-----
Luis M
System Administrator
LatinoMixed.com
"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb
No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html
Reply to: