On Mon, 07 Jan 2008 02:03:13 +0100 Luca Capello <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
