KGICON is a way of using KGI video drivers as framebuffer drivers. These drivers acts as a bridge layer between the fbcon and the KGI interfaces KGI is an acronynm for Kernel Graphics Interface, and it is part of the CGI project (http://www.ggi-project.org), which is concerned with producing a video card driver API and a set of video drivers to be used with Linux. Conceptually, KGI is much like the framebuffer device drivers, but there are important differences - one difference in particular is that standard framebuffer console drivers are monolithic (all the code is contained in a single module), whilst KGI drivers are modular - each driver is composed of five subsections that are selected separately, and linked together at compile-time. These subsections are:
This modular architecture allows driver code to be reuseable, and also enforces a clean separation of functionality and implements a consistent code layout.
Chipsets supported
Most clockchips and RAMDACs that were/are used with any of the supported chipsets are also supported. Acceleration support varies widely from card to card, but there is a generic software acceleration driver which can be used if a hardware acceleration driver is not present. The acceleration driver is not currently used by KGICON anyway, as its functionality does not fit into the fbcon API very well.
Monitor drivers are divided into three categories: monosync, multisync and timelist.
Monosync monitors can only use a fixed set of one or more mode timings. There are three monosync drivers available: MDA (old monochrome drivers), VGA and SVGA. Each allows only the timings which are standard for the given hardware. SVGA standard timings are the VESA standard timings.
Multisync monitors can use any mode timings within specified ranges. Each driver corresponds to a particular make and model of monitor, since they all have their own unique timing constraints. A database of monitor names and their timing specs is used.
Timelist monitors are similar to multisync monitors, but they have sets of allowable timing ranges rather than one continuous range. Some older monitors have this property.
KGICON can be obtained from the main GGI CVS source tree. If you know what CVS is, you can use it to fetch the tree ananymously from the GGI project's CVS server. If not, the whole tree is downloadable as one .tar.gz archive from the GGI web page at http://www.ggi-project.org. Yes, you currently have to download the whole source tree, which contains a lot of other stuff besides KGICON. Sorry for the inconvenience. If enough people complain, we will try to arrange for KGICON to be available separately.
Untar the archive, and you should have a directory named 'degas'. Each release of the CGI project are named after famous painters. The last release of CGI was 'dali'.
Anyway, if you look in degas/, you will see a directory named 'kgicon'. Change to that directory and type 'su -c "make install"'. This will create a symlink to the kgicon/include/ directory from /usr/src/linux/include/kgi. If you do not have your kernel sources in /usr/src/linux, you will need to make the symlink by hand.
After you have done this, change directories to kgicon/kgi and do a make. A dialog-based config menu will pop up (yes, dialog is required) which will lead you through the process of selecting the various subsection drivers. After this is done and you exit from the config system, dependencies will be built and then the driver itself will be compiled.
Assuming that all goes well, you should end up with a file called kgicon.o in the kgicon/kgi/ directory. This is your KGICON video driver. Go on to the next step. If all did NOT go well (i.e. the compile died), retrace your steps and review these instructions to make sure you didn't screw something up somewhere along the line. If you still have problems, make notes on what config you are trying to use and what errors you are getting (straight error logs are preferred) and post an error report to the GGI mailing list.
Next, you want to sync your disks to minimize filesystem corruption in case some bug surfaces and locks your system up. Of course we hope this won't occur and it isn't really all that likely, but video cards tend to be particularly nasty about being misprogrammed and it is better to be safe than sorry until you have gotten KGICON to work reliably for you.
KGICON comes with an 'insert' shell script in the kgi/ directory that will insmod the driver module and call the con2fbmap utility to remap your virtual consoles from the old driver (usually vgacon) to the new KGICON driver. By default, all VCs are remapped. If all goes well, you should see your screen flicker and probably change somewhat in appearance and font style. Congratulations, you are up and running with KGICON! Look elsewhere in this FAQ for ways to play with your new toy.
If you are experiencing problems, make sure it doesn't work right with the standard 'insert' script. Don't try anything wierd until you have the insertion working. If you still have problems, see if you can reboot. If you can, your syslogs may give some clue as to what went wrong. If everything is frozen, just reset. In either case, collect all the pertinent info and syslogs if you could get them and mail a bug report to the GGI mailing list.
Not before 2.3, and even then it is still up to Linus. We wanted to try to get it in before 2.2, but it just wasn't ready in time. The big issue was the lack of kernel makefile integration - the KGI makefile system is quite different from Linux's. Work in underway to remedy this, but in the meantime it is necessary to use modules.
The reason for this is that up until recently, KGI was explicitly x86-oriented. Also, there are a LOT more x86 boxes running Linux out there than other types, and this was even more true a couple of years back when KGI development started. It is what people had to work with. Another factor is that until the m68k Linux ports were merged, the m68k guys had fbcon and didn't need KGI.
Nevertheless, there is no reason why non-x86 KGI drivers cannot BE written. There are a couple of developers working on PPC and Sparc KGI drivers right now. But it is up to those with access to Linux running on non-x86 platforms to step up and volunteer to do the work. If you are interested, look on the GGI project website for more information or ask on the mailing list.
GGI project web page: http://www.ggi-project.org
FAQ author: Jon Taylor taylorj@ecs.csus.edu
GGI mailing list: ggi-develop@eskimo.com. See the web page for subscription information and list archives.