On Tue, Jun 02, 2009 at 08:35:35PM -0700, Greg KH wrote: > On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote: > > Could flickerfree-bootsplash be a topic? Or is that completely > > pushed into the userspace these fastboot days? > > We have that working today, no in-kernel work needed other than the > already-present KMS stuff. See the recent Moblin images for proof of > this. Well, I assume that the issue you've addressed is being flicker free between the kernel and x.org; what I mean is flicker-free even with the bootloader in mind. What we want to address is another problem which is present on almost all display-enabled SoC-type embedded hardware. This kind of hardware is BIOS-free and is booted from an embedded bootloader like u-boot. These processors are often pretty slow, being in the 200 MHz ARM926 league. The boot scenario on these boxes looks like this: 1) power-on 2a) on NAND-only systems, pre-bootloader is fetched from NAND block 2b) bootloader starts from NAND or NOR flash 3) the bootloader fetches Linux from NAND/NOR flash 4) kernel starts 5) userspace starts 6) application starts (i.e. app against qt+dfb or gtk+dfb) These SoCs are usually built into "devices" which don't look like PCs; think of it as mobile phones (although our applications are usually more industry-style, like machine controllers, measurement systems etc). Most industry applications have been built with microcontrollers + 2x16 alpha numeric displays in the last generation; this type of hardware has a boot time (from power-on to full operation) of something like 0.5 s. So what I would like to see is this: a) power on b) almost immediately (< 1s) a splash screen appears c) optionally be able to do some animation, progress bar etc d) application appears (instantanously or by fading) At the moment, we do this by using random hacks in the kernel, which is pretty bad. So what I'm searching for is a clean API which may be accesptable form the Linux mainline. Here's a proposal from my kernel team: - u-boot initializes framebuffer on some <address> + shows image - kernel commandline: mem=127MB framebuffer=<num>:<address>:<size> The framebuffer is reserved at the given address (i.e. 1 MB at the upper end of the memory, so we have to reduce the overall memory available for Linux) - kernel driver recognizes that the framebuffer was already set up and skips the initialisation step (which would otherwhise result in flicker) A second step could be: - Have this initial framebuffer as /dev/fb0 (mem at the end of RAM) - In order to avoid flicker, the driver sets up a 2nd framebuffer, in dynamically allocated memory -> /dev/fb1. This framebuffer continues to display the splash image (or an animation). Switching from fb0 -> fb1 is done during VSync. - While the splash image is still visible in fb1, the application starts, up to the point where it shows it's main screen. This usually never works flicker-free, but we don't see it, as fb1 is visible. - switch back to fb0 (during a VSync to avoid flicker) - optionally discard fb1 ressources On some hardware, the switch could be done by fading from fb1 to fb0 (i.e. on i.MX27 this should be possible). Drivers which see the framebuffer= parameter would have to skip their hardware initialisation step. What do you think? Would something like this be acceptable? Other ideas? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
