General Graphics Interface

General Graphics Interface (GGI) was a project that aimed to develop a reliable, stable and fast computer graphics system that works everywhere.[1] The intent was to allow for any program using GGI to run on any computing platform supported by it, requiring at most a recompilation. GGI is free and open-source software, subject to the requirements of the MIT License.

General Graphics Interface
Developer(s)GGI developers
Stable release
2.2.2 / January 27, 2007 (2007-01-27)
TypeApplication programming interface
LicenseMIT license

The GGI project, and its related projects such as KGI, are generally acknowledged to be dead.[2]


The project was originally started to make switching back and forth between virtual consoles, svgalib, and the X display server subsystems on Linux more reliable. The goals were:

  • Portability through a flexible and extensible API for the applications. This avoids bloat in the applications by only getting what they use.
  • Portability in cross-platform and in backends
  • Security in the sense of requiring as few privileges as possible

The GGI framework is implemented by a set of portable user-space libraries, with an array of different backends or targets (e.g. Linux framebuffer, X11, Quartz, DirectX), of which the two most fundamental are LibGII (for input-handling) and LibGGI (for graphical output). All other packages add features to these core libraries, and so depend on one or both of them.

Some targets talk to other targets. These are called pseudo targets. Pseudo targets can be combined and work like a pipeline.

One example: display-palemu, for example, emulates palette mode on truecolor modes. This allows users to run applications in palette mode even on machines where no palette mode would be available otherwise. display-tile splits large virtual display into many smaller pieces. You can spread them on multiple monitors or even forward them over a network.


Andreas Beck and Steffen Seeger founded The GGI Project in 1994 after some experimental precursors that were called "scrdrv".

Development of scrdrv was motivated by the problems caused by coexisting but not very well cooperating graphics environments (mainly X and SVGAlib) under the Linux operating system at this time which frequently lead to lockups requiring a reboot. The first scrdrv design was heavily influenced by the graphics subsystem of the DJ DOS extender and some concepts from the SANE project. The basic problem that scrdrv solved was that it provided a kernel mode driver that knew enough of the video hardware to set up modes, thus allowing to get into a sane state even from a messed-up or crashed graphics application.

The first official version appeared in 1995. About 1996, GGI 1.0 was released under the LGPL license. GGI only consisted of the core lib named libggi. It included input handling, a set of 2d graphic primitives and some userspace drivers for graphic boards along with a Linux kernel patch with the userspace interface for the drivers. The patch was known as KGI, the Kernel Graphics Interface.

In 1997, GGI went into a complete re-design. Many new ideas and a decision from Linux made GGI to what it became in GGI 2.0 released in August 2001 under the MIT release.

In 1998, there was a big flame war on the linux kernel mailing list about getting KGI into the kernel. Linus Torvalds explained his concerns[3] about GGI stating, "I think that X is good enough" and expressing concern regarding the overall direction of GGI.

During this time, another design idea called EvStack also added to the flamewar. EvStack was a pretty much complete redesign of the input and output subsystem that allowed for events (thus the "Ev") to flow through a "Stack" of modules that can be configured to manipulate them. EvStack is a very powerful concept, allowing e.g. to have two keyboards attached to the same machine, one operating a text console on one graphics adapter and one operating a graphics console on the other (as was demonstrated on the Linux-Kongreß ´97[4]) and even allows for having different keyboard layouts on different virtual consoles or attaching keyboards via network. However this came at the price of a huge patch to the input subsystem which did not seem acceptable. The modern Linux input event system allows programs (e.g. Xorg) to receive keyboard events other than through the console keyboard, allowing multiseat operation.

A set of talks about GGI, KGI and EvStack were given at LinuxExpo 98.

For GGI 2.0, KGI was split off and became its own project named The KGI Project. GGI 2.0 consisted of a set of libraries. During the 2.0 beta phase in late 1998 the license of the libraries was changed from LGPL to a MIT-style license. Much work was also done on the buildsystem to support more operating systems. It worked on FreeBSD, code for OpenBSD, NetBSD and even MS-Windows were there as well as some support for more hardware platforms.

Input handling was moved into a library called libgii. Generic GGI code was in libgg, a sublib within libgii. The core graphic library, libggi, has a lightweight set of graphic primitives that was common enough to write any kind of graphic application, while higherlevel API went into other libraries on top of libggi. These were called GGI extensions. libggi support a set of targets, most of them were Linux specific: fbdev, X, aa, vcsa, terminfo and some pseudo targets such as tile, multi, palemu and trueemu. The GGI extensions featured higherlevel API. libggiwmh provides functionality for windowed only targets, at that time this was only X. libggimisc provided some basic stuff like vga splitline.

GGI 2.0.2 was released in December 2002. The most user visible change was from the scratch re-designed X backend. Another noticeable change was the huge documentation improvement. Last, but not least, the release cycles changed. From this release on, there was a development and a stable tree. The stable tree is open for bugfixes only, the development tree got the name, following the BSD scheme, -current.

November 2004, the last bugfix from the GGI 2.0.x stable tree was released in favour for a new GGI 2.1.x stable tree.

GGI 2.1.x runs on many Operating Systems: GNU Hurd, Linux, *BSD, System V, Mac OS X and MS Windows. Support for more hardware platforms has been added. NetBSD even created a binary package for NetBSD/Vax! A new GGI library on top of libgii called libgiigic has been added. It allows to combine user actions with events at run time.

GGI 2.2 was released in December 2005. The target auto detection has been reworked and was no longer linux centric. GGI replaced its own integer datatypes with ANSI C99 types for more portability. A target for Quartz has been added. Mac OS X users no longer depend on X11 but still can use the X11 backend. The most user visible change, however, was the support for static linked in targets.

Latest release is GGI 2.2.2, a bugfix release in the GGI 2.2.x stable series. It was released in January 2007.

Status as of 2006

The GGI Project was moving onward to the GGI 3.0 release. libgii had been re-designed. The input handling had been replaced with a reactor event model, which is more flexible than using select() on a file descriptor. This also simplified the input-drivers in general, particularly for those who don't use file descriptors such as input-quartz. libgg had been moved out into a separate library.

libggi had merged some targets into one sublib, multi with tile and mono text with palemu. libggi also had gotten a new VNC target, which allowed to run any application as a VNC server.

In GGI 3.0, the extension mechanism had been re-designed from scratch to simplify interactions between the extensions and the core libs. This required a little API change.

See also


  1. Loki Software, Inc; John R. Hall (2001). Programming Linux Games. No Starch Press. p. 56. ISBN 978-1-886411-49-4.
  2. Larabel, Michael (3 July 2011). "The Kernel Graphics Interface (KGI) Is Effectively Dead - Phoronix". Retrieved 2019-06-08.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.