[Splashy-devel] Bug#459457: Bug#459457: splashy: should not start if requirements aren't satistfied

[Tim Dijkstra]

On Mon, 07 Jan 2008 02:03:13 +0100
Luca Capello <luca at pca.it> wrote:

> Hi Tim,
> 
> thank you for your fast reply and excuse me about my wrong statement in
> my previous mail, read below ;-)
> 
> On Sun, 06 Jan 2008 23:08:18 +0100, Tim Dijkstra wrote:
> > On Sun, 06 Jan 2008 18:56:19 +0100
> > Luca Capello <luca at pca.it> wrote:
> >
> >> - when no vga= or video= command line is provided, AFAIK even if fbcon
> >>   and vesafb are inserted (on Debian kernel they're compiled in by
> >>   default), /proc/fb is present, but with zero size.  Thus, when
> >>   checking for /proc/fb to create /dev nodes we should check for its
> >>   size (test -s).  However, according to [6] and [7], if no vga= or
> >>   video= parameter is specified, fb is not initialised ([2] and [4]).
> >
> > I'm using a system without vesafb, but with the ati vesa driver, which
> > name I'm to lazy to look up now:) But anyway, I don't need a vga=
> > parameter on /proc/cmdline.
> 
> I've a ThinkPad T42p with an ATI card (radeonfb), but ATM its LCD is
> broken, so I cannot test (since I don't have any other external monitor
> at home).
> 
> > IIRC I wrote the initramfs scripts to test for some specific contents
> > in /dev/fb, not just its size.
> 
> If I'm right, the initramfs script does the following.
> 
> 1) check if /sbin/splashy is executable: this is required
> 
> 2) check if /proc/cmdline contains 'splash' (exits if not) or 'single'
>    (exits if present): I'd prefer this tests as `splashy enable`

It is nice to have a way to bail out the initramfs-script as early as
possible. That way you can skip as many bugs as possible if your system
doesn't boot because we introduced a problem in splashy.

> 3) insert fbcon and vesafb: at least on Debian stock kernels, these two
>    modules are compiled in the kernel by default, so this step would be
>    unnecessary, but splashy must support even non-stock and non-Debian
>    kernels...

> 4) create the necessary device nodes WRT to /proc/fb: if that file
>    exists, one node per each entry, otherwise only the first node.  Here
>    the problem: if /proc/fb exists but it's empty, no device node is
>    created.  This situation happens for example with the intelfb module
>    without specifying any video mode at boot:
> 
>    =====
>    intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM chipsets
>    intelfb: Version 0.9.4
>    intelfb: 00:02.0: Intel(R) 945GM, aperture size 256MB, stolen memory 7932kB
>    intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
>    intelfb: Video mode must be programmed at boot time.
>    =====
> 
>    Thus we should check if /proc/fb esists and it's not empty.  FWIW, I
>    found that the same erroneous check is present in the frambeffuer
>    initramfs script [1].

Normally udev should create these nodes, but I guess it should work without udev too.
 
> 5) create the necessary device nodes for the consoles: required

I think this should already have been done by some other initramfs script.

> 6) grep for VESA|VGA in /proc/fb: this was the check I erroneously
>    stated it hadn't never worked for me, but I was wrong (since we're
>    talking about initramfs here and indeed it works).  I'd prefer this
>    test to be performed inside splashy (which seems to be the case since
>    0.3.9), thus checking for /proc/fb *and* /dev/fb0

Yes, I think this was the test I talked about.

> Now, as a prophane, I see some improvements here:
> 
> - point 2) and 6) should be managed inside splashy (giving verbose
>   output if requested, so we can reuse it with the LSB functions)

I think I agree about 6). About 2): well parsing /proc/cmdline seems a
bit to distro specific. I would think this is best done in the
initramfs. After all /proc/cmdline, is the boot cmdline, not splashy's.
 
> - while point 3), 4) and 5) could be completely managed by the
>   framebuffer initramfs script (and they seem to be fully copied from
>   there), as I already stated it seems necessary for non-stock and
>   non-Debian kernels

So, indeed in the debian package we can skip that part and just depend
on the framebuffer script.

> > Well, I'm not really overseeing the situation, but I think mandating
> > vga= is not the proper way to go.
> 
> I fully agree, but for the general case (vesafb) vga= is required by
> 
> 
> The patch I provided was a proof-of-concept: it works, now and without
> anything special.  Since my C skills are poor, I haven't even tried to
> implement it in splashy, but the best solution will be there.

I haven't got the time. I should actually be replying to this e-mail;)

grts Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20080107/91a23a4a/attachment.pgp