On Tue, 2006-02-14 at 09:46 -0800, Jason Thorpe wrote:
> 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!)

Yeah, plus you get to run at securelevel >= 1 (double-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?

The only thing the hw driver needs to do is allocate ri_hwbits. But
yeah, that can be easily changed. rasops can calculate the size easily
enough by doing ri_height*ri_stride. I'll make this change.

> >  * 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

It was originally part of rasops, but it was suggested on ICB that the
dependency be removed for cases where a splashscreen is desired but
rasops isn't used.

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

I'll change it.

> 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 :-)

Agreed -- that was a simple hack to show the concept. I don't know where
the right place would be to update the progress if we decide to go this
route.. init_main was one place I was thinking, but I'd hate to pollute
this with calls to splash_progress_set.

> 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.

My original plan was to tie it into aprint, but I wasn't in the mood of
converting all of the code in the kernel to use it ;)

> 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.

I like it. Care to draw some icons for me? ;) I'm not much of an art
person. I can convert them using The GIMP and use splash_render to draw
them.

> >  * 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?

I updated mime.types on my web server to return video/quicktime for .mp4
files. Please try again.

Cheers,
Jared