Re: GGI, EGCS/PGCC, Kernel source (amusing thread :)

teunis (teunis@mauve.computersupportcentre.com)
Thu, 26 Feb 1998 01:54:05 -0700 (MST)


On Wed, 25 Feb 1998, Nathan Uno wrote:

> On 25 Feb, Jes Degn Soerensen wrote:
> > X different drivers means X times acceleration functions in the
> > kernel or am I missing something here? (no it doesn't matter that one
> > should only compile what one uses, its still in the kernel tree).
>
> I'm not sure I see a way around having sources in the kernel tree.
> Either you support a piece of graphics hardware, or you don't. If
> linux wants to support graphics hardware, the drivers have to be in the
> kernel tree. Is that a bad thing?

The nice thing about GGI's abstraction is it allows binary-only drivers
(aka Permedia support) and other privately-developed drivers to be
incorporated simply...

Now things are still changing (a lot slower than last year but...) but the
scheme is designed so that _NO_ video driver code will be required in the
kernel.

Unlike any of linux-kernel it is (will be for the most part) possible to
compile a videodriver in a seperate source tree. Or even just install
binary drivers for those companies too stuborn to provide public info (or
unaware that the GGI Media/GX support was written under NDA with Cyrix's
blessings and is nonetheless in source form).

> If it is, then adding hardware support to the kernel is ALWAYS a bad
> thing. I know of very few pieces of hardware that EVERYONE wants to
> use. Your logic seems to be that drivers that not everyone needs are
> source bloat.

Hope above comments help.

BTW:
- My card locks my system when running SVGAlib or X.
(GGI fixes this... mostly. Gotta finish the drivers :)
[S3-ViRGE or S3-Trio64V+.. take yer pick]

- I run multiple videocards. fbcons does _NOT_ support multiple
PCI adapters. At least ones that don't initialize themselves.

- I've been pestering for kernel/userspace communications since
1.1.83-ish. EvStack is actually the first operational implementation
I've seen yet....

One last comment:
Anyone coding for libGGI is at an advantage on a KGI-supported
system. but their programs will run under X, text, terminfo, svgalib, or
other interfaces as well (without recompilation). The system may have a
lot of work to do but this library alone makes the project worth paying
attention to IMHO... (but it's a userspace issue and offtopic for
Linux-kernel, right?)

G'day, eh? :)
- Teunis (another GGI convertee :)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu