Re: [RFC] enhancing the kernel's graphics subsystem

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Tuesday, May 22, 2007, Jon Smirl wrote:
> On 5/22/07, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > you display text in graphics mode entirely in kernel context. The
> > > driver should also attempt to stop the GPU to try and make sure it
> > > doesn't erase the OOPS display.
> >
> > If we know how yes. Probably the X server needs to provide us with a
> > simple list of operations to perform or failing that write 128K of
> > null to the display then print the characters (the 128K should ensure
> > any running FIFO for commands is stuffed and we get back to the
> > framebuffer)
> >
> > > Another simple thing that needs to be built is a mechanism to run
> > > the VBIOS in x86 mode when the driver is first loaded. This can be
> >
> > We don't want to touch the video bios for most cards, its not as good
> > as the X mode switcher code, nor for that matter does it work in a lot
> > of cases as they use IRQ and DMA functions sometimes.
>
> The only reason the VBIOS is run is to initially reset the card. Once
> we get the card reset it isn't used any more. For almost all cards
> this is the only way to reset them, we have insufficient information
> to write this ourselves.

We should aim to get away from this though.  For Intel and VIA chips, we 
have enough info to do full card setup ourselves.  IIRC there's some early 
code to do the same for ATI chips (not sure about other chips though).  If 
we can avoid using the VBIOS, our drivers will be far more portable and 
featureful than they'd be otherwise.  For example, current ATI drivers 
simply can't do full multihead on many setups because it relies on the 
BIOS to setup external DAC chips, and in many cases the BIOS doesn't.  In 
order to address that, we need to learn how to do it ourselves...  So if 
at all possible, I'd like to avoid baking any assumptions about VBIOS POST 
into this design.

Jesse