On Wed, Jul 10, 2002 at 11:19:23AM +0200, Matthias Drochner wrote:
> 
> junyoung@mogua.com said:
> > "We can do more hack simply because there's already a hack." ;-) 
> 
> Hack or not, it is common practice in our device drivers to
> nest structures the way Takemura suggested.
> 
> Since the core VGA driver doesn't need such data, they are private
> to the chip dependant frontend. (I suppose there is such a thing
> for your mach64 driver.) So they should kept there. As you night have
> noted, I'm playing with a VESA BIOS frontend to the VGA driver. In this
> case, the driver specific data look different of course.

AFAIK, most graphics cards manufactured so far need such timing
information for mode switch. It's not chip dependant. If it were,
for what does XFree86 provide common mode lines in XF86Config file? 

> 
> There is one change needed: The frontend must be able to pass
> a screen type table and a switching function (plus an argument
> opaque to the core vga driver, what we call a "cookie" most times)
> to the "attach" function.
> Well, we need a kind ok "cookie", but it should be done right.
> 
> > wscons has support for both character cell
> > and raster displays, but it doesn't define where to save video mode
> > information for each screen
> 
> This must be done by the specific frontends. The core VGA driver
> only cares about text modes, and it is already bloated enough.
> (There is some stuff which should be split out, the font encoding
> stuff eg, and parts of the font handling can be shared with EGA.)

Adding a mode cookie in wsscreen_descr doesn't require that you modify
the core VGA (even a line!). Mach64 driver is not related to the
core VGA, either.

Jun-Young

-- 
Bang Jun-Young <junyoung@mogua.com>