Index: [thread] [date] [subject] [author]
  From: Brian S. Julin <bri@tull.umassp.edu>
  To  : Jos Hulzink <josh@stack.nl>
  Date: Fri, 13 Aug 1999 09:09:20 -0400 (EDT)

Re: GGI and XFree86 and stuff

On Fri, 13 Aug 1999, Jos Hulzink wrote:

> Problem is that the ViRGE chipset is a "just hack a little around and hope
> it will work" chipset. The trick is that (see XFree code) for the ViRGE VX
> some registers must be set at strange moments, the DX must be booted in IO
> instead of MMIO, the ViRGE crashes if registers are written in the right
> order for ViRGE DX, etc. Many S3 register definitions are not right for
> Virge, some ViRGE definitions are not right for ViRGE VX. When I look
> thorugh the code, I think the only part that is portable is the clock
> driver and the code that sets the basic resolution (11 registers out of
> 70). Even the "compatible" Trio64 gives trouble...

With this level of incopatibilty, I'd say you'd be fully justified
in having separate drivers for various virge sub-families.

> But if you want me to I'll make the code exportable, don't blame me
> if it doesn't work. 

Well, no there's point in exporting anything that's really chipset 
specific.  I'd only separate things that are easily made reusable.
For the registers there's no harm in having extra unused macros kicking
around (in my driver the wd90c2x chipsets all use the same register
macro header even though some don't have a few of the registers listed
there), for object code having unused functions and data structures
would be bad.

--
Brian

Index: [thread] [date] [subject] [author]