Frequently Asked Questions about GGI
written by Jon Taylor
last update on 8-7-97
Section 1: Introduction and overview
Why is this bad? Several reasons:
- In spite of the fact that X Windows is the de facto historical and current standard graphics interface for just about every flavor of UNIX and UNIX-like OS (including Linux), it is not part of UNIX. It is unreasonable to demand that every user of Linux must use X in order to do any sort of graphics programming.
- X is a very complex, over-engineered and is considered by many to be obsolete and in need of replacement in some form or another.
- Linux should not be dependent on third-party, non-GPLed code and/or binaries for what the GGI project considers necessary base functionality of an OS. XFree86 is distributed with a 'free' license, but it is not as free as the GPL. The commercial X servers are all binary-only.
- Also because of the fact that userspace code is handling the video card(s), there is a significant loss of functionality and flexibility. An example: The average SVGA card today contains 2 MB of video RAM. This fast, bus-connected memory is almost always being drastically underused, because only the highest resolution and color depth graphics modes will use all of that memory. In the kernel, however, the unused portion can be put to work as a fast I/O buffer cache, backing storage of display memory, font caching, or even just extra physical memory. Also, there are lots of graphics pipeline optimization/scheduling techniques that require very close integration with the kernel to work well.
- It's The Right Thing To Do! (TM). The function of an operating system is to sit on top of the hardware and arbitrate access to it by user programs. If the OS, in this case the Linux kernel, cannot control access to a specific piece of hardware, it is not doing its job in this respect. This is not just an abstract point of computer science theory, but a very valid design issue. The current state of affairs with regard to Linux and graphics is a kludge, nothing more. It is a subversion of the primary function of the OS.
Here are some of the advantages of this approach:
- Since all the kernel drivers will do is export their cards' functions in as raw a form as safely possible, the task of writing the kernel drivers becomes MUCH simpler.
- The resultant drivers will also be smaller and faster than otherwise, allowing the bulk of any sort of optimizing to be done at the userspace-library level. This is a big win because userspace code can be multithreaded.
- New revisions of the userspace libraries can be easily recompiled and reinstalled without having to recompile the whole kernel. Likewise, new kernel drivers can be installed without breaking the older userspace libraries. Upgrading the userspace libraries to take advantage of (possible) new features in the kernel drivers will be desirable, of course, but not necessary.
- Just about any sort of API or GUI can be written to use the GGI. A GGI-using X server, for example, would have its own set of dynamic userspace libraries specifically optimized for X. All X programs continue to run without any changes, but at the same time they (through the GGI-optimized X server) enjoy the advantages of GGI.
Section 2: The Details
- The kernel subsection: This half of the GGI is part of the Linux OS proper.
- The KGI: This is the new kernel console interface. It is the foundation upon which all the rest of the GGI is based.
- The KGI video card drivers: These are very similar to other Linux kernel device drivers, such as the sound drivers or ethernet drivers. They plug into the KGI subsystem and provide highly detailed and card-specific hardware control of all video cards in a system. They consist of five submodules:
- The chipset driver: The heart of the video driver. Controls mode setting, register-level programming, multiheading, font handling, and other such base functionality.
- The RAMDAC driver: RAMDAC is an abbreviation for Random Access Memory Digital-To-Analog converter. It is the circuitry on a video card which converts bits in video memory to analog signals that get sent to your monitor. This driver controls aspects of mode setting, palette handling, and sometimes other card-specific functions like video overlaying.
- The clockchip driver: The frequencies at which the display signal scans horizontally and vertically on the monitor to draw each individual frame are driven by clock frequencies synthesized by the clock chip. This driver takes requests for video modes and algorithmically synthesizes appropriate clock frequencies and the register programming needed to implement them.
- The monitor driver: This driver does not control any hardware. It is just a set of mode timing constraints corresponding to the monitor's ability to synchronize with video signal frequencies. Video card can almost always send a video signal with higher frequency than any monitor can handle, so this info is necessary for the other drivers to be able to program valid modes.
- The acceleration driver: Most video cards have built-in hardware-assisted drawing functions of some kind, often referred to as hardware accelerations. These can be simple functions like drawing lines or copying rectangular areas, or they can be complex 3D functions like shading, transparency or polygon drawing. This driver exports ioctl sets corresponding to the present hardware acceleration functions.
- The input device drivers: These drivers plug into the KGI, much as the video card drivers do, but these drivers handle input devices like keyboards, mice, joysticks, touchpads, etc.
- EvStack (kernel subsection): EvStack is the heart of the new hyper-flexible and hyper-extensible Linux console IO routines. It is designed to operate congruently in userspace and in the kernel.
- The userspace subsection: This half of the GGI consists of dynamic function libraries, platforms (such as X Windows or Berlin) and the applications that use them.
- EvStack (userspace subsection): These stacks can be dynamically loaded and unloaded by individual applications or libraries.
- LibGGI: Basic 2D graphics and input library which utilizes the KGI interface to the kernel. Dynamic ELF-based loading and unloading of modular library subsystems allows for transparent integration of hardware acceleration support on a per-card basis.
- XGGI: GGI-Using X server. Currently unaccelerated, but a modular architecture similar to LibGGI's is planned for acceleration support. Will not need to be suid root to run.
- SVGALib-GGI: A drop-in replacement for libvga.so and libvgagl.so that uses the GGI instead of programming the hardware directly. Will not need to be suid root to run, nor will the programs that use it! Currently ELF only, an a.out DLL jumptable library (Doom!) is planned.
- Mesa-GGI: A port of the free OpenGL clone library that uses the GGI. Currently runs unaccelerated, but full per-card acceleration support is planned.
- Berlin: The Berlin Project is designing a replacement for X11. They are not technically part of the GGI project, but Berlin is being designed to run on top of the GGI first.
Section 3: Who, what, where, when, why and how