On Feb 14, 2006, at 8:48 AM, Jared D. McNeill wrote:

> Hey folks, I've been working hard on vesafb lately. It's finally in  
> a state where I'm ready for comments. What the patch adds:

This is pretty cool.  It could go a long way to making it easier to  
have a nice GUI installer, since X configuration would not be  
required (yay wsfb!)

>  * Shadow framebuffer support in rasops; improves scrolling speed
>    significantly if no hardware support is available, at the  
> expense of
>    additional memory usage.

This is cool.  I noticed, however, that you require the individual fb  
drivers to initialize some extra stuff... how about if they just pass  
some flag, and that causes the rasops code to DTRT when initialized?

>  * Splash screen support (w/ optional progress bar), shown in place of
>    the kernel text at boot time. Enabled with options SPLASH (and  
> options
>    SPLASH_PROGRESS)

It seems like the splash support could be better integrated into either:

a) wsdisplay
-or-
b) rasops

Also, SPLASHSCREEN seems like a better name for the option.

The SPLASHSCREEN_PROGRESS (note my subtle name change suggestion :-)  
option also seems too tightly-integrated into the fb driver itself,  
and I'm not sure I like tying it to how many putchar operations have  
been performed :-)

The problem with progress meters, of course, is that you must know a  
priori how many work units will be done, so that you can calculate  
the percentage.  I think it would be better to somehow tie this in to  
the aprint*() stuff, and maybe think of a better widget to display.

Mac OS X Tiger uses the following:

- A spinning spritely-like thing (the one that is gear-like, not to  
be confused with the beachball-of-death) while the kernel is doing  
its thing before letting userland take over.

- Once the Window Server has started, a progress bar (that,  
unfortunately, doesn't really indicate much in the way of actual  
progress :-) is displayed... in previous versions of Mac OS X, the  
service that was being started was displayed here (via the  
ConsoleMessage CLI tool that start-up scripts can call)... perhaps  
the "service being started" model is better for us, and maps nicely  
to what our rc.d scripts already spew out.

Yes, I understand that only the first item is analogous to what you  
have provided so far :-)  That said, I think an animated sprite of  
some sort during the kernel part would be better than a progress  
bar... perhaps something like (use your imagination here ;-)

5 grey dots

           o o o o o

...that darken as aprint*() steps occur:

           * o o o o

           o * o o o

           o o * o o

           o o o * o

           o o o o *

           * o o o o

...and so on.

Anyway, it's an idea, and I think it would work out much better in  
practice than the progress bar itself.

>  * Reference VESA framebuffer driver for i386, that uses the above
>    features. Supports 8, 16, 32bpp and uses the shadow framebuffer.
>    Requires VBE 2.0 or above (for linear framebuffer access).
>  * Patches wsdisplay to prevent multiple children from claiming to be
>    'console'. This allows us to have both wsdisplay@vesafb and
>    wsdisplay@vga in the same kernel. The first one to successfully  
> attach
>    a console "wins".
>
> The patch is available here:
>
>  http://www.invisible.ca/~jmcneill/netbsd/vesa/vesafb-20060214.tar.gz
>
> More information (including a video of the splash screen in action):

I couldn't get the movie to play... everything that I handed it to  
insisted that it was a text file?

>
>  http://www.invisible.ca/core/VESA_Framebuffer_console_in_NetBSD
>
> I'd like to get this code in at some point in the near future (of  
> course, with options SPLASH not enabled by default). Feedback is  
> more than welcome.
>
> Cheers,
> Jared

-- thorpej