Messages in this thread | | | Date | Thu, 26 Feb 1998 01:54:05 -0700 (MST) | From | teunis <> | Subject | Re: GGI, EGCS/PGCC, Kernel source (amusing thread :) |
| |
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
| |