Index: [thread] [date] [subject] [author]
  From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 12 Aug 1999 13:58:02 -0700 (PDT)

Re: GGI and XFree86 and stuff

On Thu, 12 Aug 1999, Jeff Garzik wrote:

> "Jon M. Taylor" wrote:
> > 
> > On Thu, 12 Aug 1999, Jeff Garzik wrote:
> > 
> > > Jos Hulzink wrote:
> > > > We discussed this before. Trying to see all S3 cards as one big family is
> > > > not done, for the chips differ far too much, so it would make the code
> > > > unreadable.
> > >
> > > Not if it is well-written.  I think it can be properly virtualized, and
> > > that there is enough common elements to make it worthwhile.
> > > ViRGE is
> > > not likely be supported; it is already well-supported and also less like
> > > other S3 chips.
> > 
> >         You will not be able to support all the older DACs that the
> > pre-Trio chipsets used without producing an XFree86-style monolithic
> > driver.  And ViRGE is not much more than a Trio64 with 3D features.
> 
> From looking at my ViRGE GX/2 databook its higher CRTC registers are
> sufficiently different enough to discourage me from implementing ViRGE
> support at least until Trio and Savage families are working.

	Once you get Trio, ViRGE and Savage will be easy.  I wish I could
help with Savage - I have a 2D/3D accelerated Savage4 KGI driver with
STREAMS up and running - but I am still under NDA.

> With regards to supporting all the DACs, that is indeed a problem.  I am
> skirting the issue for now by working on Trio and Savage support first. 
> Those are sufficiently similar to be supported with the same base
> driver, including RAMDAC code.  Function pointers can be employed to
> efficiently handle chip-specific differences, along with judicious use
> of static tables.

	Sure.
 
> However, since I have committed to porting the XF86 3.x S3 server to
> 4.0, I will eventually have to support all those ramdacs in s3lib, if
> the XF86 drivers use s3lib.  In that case, the code can easily be shoved
> into an optional "s3oldramdac" module.  That implies some duplication of
> RAMDAC code, but such is required in order to have the XF86 4.0 driver
> be as fully functional as the XF86 3.x driver.

	Hm.  Well, an SUIDKGI-XFree86 4.0 wrapper layer will instantly
give XFree86 4.0 full accelerated support for pretty much all S3 chipsets
ever made, including Savage4 (my driver), so I basically consider this a
nonproblem.  You would be much better served by writing that wrapper layer
instead of S3lib, IMHO.  Much less work for much more gain.

> P.S. There exists 'linux-s3@gtf.org' list.  E-mail majordomo@ to
> subscribe.  All discussions of S3 on Linux are welcome, XFree86, GGI,
> fbdev, etc.

	Will do.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed

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