> On Mon, 3 Aug 1998, Jon M. Taylor wrote:
> > On Mon, 3 Aug 1998, Rik van Riel wrote:
>
> > > Maybe the KGI S3 setup code could be ported into the
> > > S3triofb driver? [preferably by someone with both
> > > intimate knowledge of the video code and free time]
> > > nuisance instead of real trouble.
> >
> > Yes, and after all that work you will still have a Trio driver
> > that only supports 8 and 16(?) bpp modes and a few fixed resolutions and
> > mode timings. On the other hand, the kgicon Trio driver supports all bit
> > depths from 1bpp to 32bpp, infinitely variable mode timings, infinitely
> > variable resolutions, MMIO and multiheading, and has real monitor drivers.
> > kgicon supports YPAN, YWRAP, splitline, modesetting via fbset and can be
> > loaded as a module with the initial mode params passed in as module
> > parameters.
> >
> > It seems like people are willing to expend an awful lot of energy
> > to avoid using kgicon, but I don't see why. kgicon is more compliant to
> > the fbcon spec than a lot of the existing fbcon drivers are.
>
> Ahh, but I didn't know that the KGI drivers were fbcon compatible...
Yes. That is what kgicon is for - it is a bridge layer between
fbcon and the KGI drivers. Just the KGI *drivers* - the KGI layer itself,
which implemented a new console system and input device drivers (which
Linus didn't like) is gone. It is still being worked on in the context of
the GGI Console (used to be EvStack), but that is a different project now.
> This changes things an awful lot.
Well, we hope so |->. There are not many x86 fbcon drivers in
the kernel right now. KGI drivers are all x86 at present, and there is
support for:
* Chips & Technologies 655xx
* Cirrus Logic 542x and 546x
* Cyrix MediaGX
* Hercules Mono
* IBM VGA
* Matrox Millennium I & II and Mystique
* S3 928, 96x, Trio64 and ViRGE
* Tseng ET4000 & ET6000
* Western Digital PVGA, WD90c00, WD90c1x, WD90c2x, and WD90c3x
Most ramdacs are also supported. Also, KGI has monitor drivers,
so you can tell the chipset drivers what timing ranges can be used
without having to code XFree86-style mode timings up.
> Volunteers for porting the
> KGIcon drivers into the fb framework that's already inside
> the kernel?
The KGI config system is different than the kernel's. Anyone
remember way back when sound support was first added to 1.1.x, and the
sound config had to be "shelled out" to by the regular kernel make config
system? That's the situation here. Not a showstopper, but it will take
some thought. That's the only big thing left in the way of integrating
kgicon into Linux.
When I first started working on kgicon after 2.1.107 came out, I
managed to get a kgicon driver to compile into the kernel, but it locked
up on boot. This probably wasn't a kgicon problem, seeing as how there
were so many fbcon bugs back then. I have stuck with modules since then,
but I'll wager that kernel integration could be done now.
> [don't look at me, I'm super-busy now but will
> be available again later this year]
We are actually quite close now. Like I said, the only big thing
left is the config system integration. If anyone out there wants to lend
a hand with this, please do. The sooner this is cleared up, the sooner
we can make a stab at kernel inclusion.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html