Re: Generic VESA framebuffer driver and Video card BOOT?

["Kendall Bennett" <KendallB@scitechsoft.com>]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Gwe, 2004-10-15 at 19:20, Kendall Bennett wrote:
> > That works great on x86, but this solution was developed for PowerPC and 
> > MIPS embedded systems development not x86 desktop systems. For those 
> > platforms you either need a boot loader that can bring up the system into 
> > graphics mode (possible with U-Boot) or to init the video right when the 
> > framebuffer console driver is brought up.
> 
> Right there are certainly cases where you need to do stuff very
> early. Even then you may benefit because you can keep the kernel
> side init pretty basic and also marked "__init" so it is freed post
> boot. 

Right. I haven't yet figured out how to mark the code as __init so it can 
get tossed out, although if we use the VESA driver after the fact you 
would want to keep it around in that case. But to just boot the card and 
use say the Radeon FB driver it would be nice to toss out the code.

I should probably look into that.

> > >From the sound of it that might be too early to spawn a user mode 
> > process?
> 
> Do the embedded folks want the kernel boot messages via the
> display or are they happy with that via debug port/serial anyway.
> If so is it an issue ? You can bring up the video at the point user
> space begins. 

Well in most cases I think what they really want is for the video to come 
on as soon as possible (instantly would be best) after the power is 
applied, but they probably want their own boot logo on the screen at that 
point and not Linux kernel boot messages.

Also is it possible to run X on a machine that is running from a serial 
console and have it start up on the graphics card at that point? I 
thought about that option since then everything would be in user space, 
but wasn't sure how that would work (plus there would be a long delay 
between when the machine is powered on and something shows up on the 
screen, which is generally not a good thing for consumer products).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~