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@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
-
Kevin O'Connor