[SeaBIOS] [PATCH RFC 0/7] VGA ROM improvements

[Kevin O'Connor]

On Tue, Jan 03, 2012 at 12:42:10PM +0000, Julian Pidancet wrote:
> On Wed, Dec 21, 2011 at 5:39 PM, Kevin O'Connor <kevin at koconnor.net> wrote:
> > I'm not sure which scheme makes the most sense.  I could see using the
> > "cirrus" scheme - each hardware type defines its own "handle_10" and
> > "vga_post" in a file dedicated to that hardware, which then check for
> > hardware specific functions and call "library" code for the standard
> > stuff.  However, I'm not sure how much code duplication there would be
> > for things like the VBE calls which seem to contain a mix of standard
> > info and hardware specific info.
> >
> 
> Happy new year,

Happy new year!

> I havn't studied the cirrus code yet, but the part which implements
> the VBE interface should be quite simillar from one driver to another,
> so I don't think it is necessary to let every hardware type redefine
> its own int10 handler, at least for the vesa part.

Yes - I looked at this closer last week and I agree.  The VBE
interface is too complex to implement multiple times.  (For example,
full VBE support has five entry points.)

I think the main code could call out to hardware specific code where
needed.  The last patch series I sent starts this idea.  The idea is
to have the main code in vgaentry.S, vgabios.c, vgafb.c, and vbe.c,
while the rest of the code is driver specific (with the "standard" vga
interface - stdvga.c and vgatables.c - used by the other drivers as
needed).

I think after reworking it, the hardware specific drivers will only
need to provide X_init(), X_set_mode(), X_save/restore_state(), and
X_mode_info() functions.  The mode stuff can be further refactored -
right now the cirrus, bochs, and stdvga stuff all have similar mode
tables - the main code can reuse those tables if the common
information (memmodel, width, height, depth, cwidth, cheight, segment)
is stored in the same format across drivers.

-Kevin