Bug#459457: [Splashy-devel] Bug#459457: splashy: should not start if requirements aren't satistfied
On Jan 6, 2008 8:03 PM, 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 ;-) [snip] Thanks for submitting this to us. I have applied it as-is to our main git repo. You will see this in Splashy 0.3.9. I'll look back at the bugs to see which ones we can close based on your additions. Regards, -- )(- Luis Mondesi Maestro Debiano - START ENCRYPTED BLOCK (Triple-ROT13) -- Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq. - END ENCRYPTED BLOCK (Triple-ROT13) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459457: [Splashy-devel] Bug#459457: splashy: should not start if requirements aren't satistfied
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
Bug#459457: [Splashy-devel] Bug#459457: splashy: should not start if requirements aren't satistfied
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. IIRC I wrote the initramfs scripts to test for some specific contents in /dev/fb, not just its size. Well, I'm not really overseeing the situation, but I think mandating vga= is not the proper way to go. grts Tim signature.asc Description: PGP signature
Bug#459457: [Splashy-devel] Bug#459457: splashy: should not start if requirements aren't satistfied
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` 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]. 5) create the necessary device nodes for the consoles: required 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 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) - 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 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 linux vesafb documentation * linux/Documentation/fb/vesafb.txt: How to use it? == Switching modes is done using the vga=... boot parameter. Read Documentation/svga.txt for details. You should compile in both vgacon (for text mode) and vesafb (for graphics mode). Which of them takes over the console depends on whenever the specified mode is text or graphics. * linux/Documentation/svga.txt: 1. Intro This small document describes the Video Mode Selection feature which allows the use of various special video modes supported by the video BIOS. Due to usage of the BIOS, the selection is limited to boot time (before the kernel decompression starts) and works only on 80X86 machines. ** Short intro for the impatient: Just use vga=ask for the first ** time, enter `scan' on the video mode prompt, pick the mode ** you want to use, remember its mode ID (the four-digit ** hexadecimal number) and then set the vga parameter to this ** number (converted to decimal first). * linux/Documentation/fb/fbcon.txt (this is a specific Debian case because both fbcon and vesafb are statically compiled): B. Loading Possible scenarios: 1. Driver and fbcon are compiled statically Usually, fbcon will automatically take over your console. The notable exception is vesafb. It needs to be explicitly activated with the vga= boot option parameter. - the splashy documentation itself,
