15. GGI - General Graphical Interface

This project sought particularly to improve the robustness of graphics handling under Linux. The official "home" is at www.ggi-project.org which has recently been "resurrected" from apparent death. There is a SourceForge project at ggi.sourceforge.net that has not yet released any files as of early 2002.

The GGI project is moving along, albeit somewhat slowly; there have only recently been official releases at Sourceforge, but there have been several thousand CVS commits, indicating that something has been going on...

At present, the easiest method to utterly crash a Linux machine is via graphics applications that by virtue of their access to graphics implicitly reach deeply into the kernel. Programs such as X servers and SVGAlib applications must run as setuid root (e.g. run as the ultimately privileged user, root) in order to access graphics capabilities. This provides these processes with complete access to IO ports and DMA. This represents:

• An enormous security hole,

• An enormous loss of robustness,

• A whopping lot of management work for every program that does any kind of graphics, and

• A lot of code that must be reimplemented in nearly any non-X-based program that does graphics.

Every program that manages a graphics console has to manage video modes independently. Running SVGAlib and X applications simultaneously on different virtual consoles is the most common source of problems as they don't change video modes in a coordinated fashion.

GGI would change this, having the following components:

• A relatively small kernel module called the KGI that represents a display manager; this would allow easy extensibility to multiheaded systems (e.g. multiple video cards/monitors);

• A loadable kernel module that represents the driver for the specific graphics card on the system (or at least for card-specific initialization and access calls that need to be in the kernel);

• A user space library called libGGI that provides an abstract programming interface for applications.

  Note that only the kernel module(s) need to have hardware access. They have "kernel" access to hardware; the user space libraries need only have access to the kernel modules, which does not necessitate root access.

  Since X is expected to be the primary "customer" the API is being optimized for that protocol. Note that this would result in there being only one X server to support unlike the current situation where each family of graphics cards requires a different X server.

  In order to make it more generally usable, the GGI group have made Libggi have multiple "display targets:"

  • KGI - Kernel graphics interface (the "right way" to use GGI)

  • X - run libggi atop X-Windows

  • Memory - simulate display in memory

  • AA - "AAlib text mode"

  The recently introduced "GGI atop X" option is particularly interesting; it allows people to use GGI immediately without having to have a patched kernel in place. This is a critical bit of functionality that should be quite useful in allowing GGI to become more usable by "the public."

• And other libraries that interface to libGGI

  Other libraries could provide interfaces to libGGI that are optimized for other purposes. For instance, an additional "API" that will be provided will provide SVGAlib emulation, which is commonly used to run graphical applications, typically games, on virtual consoles.

  SGVAlib has always been plagued by the fact that it only runs on Intel-compatible systems, only supports a few graphics cards, and has a tendancy to lock up the system on console switches.

  Running SVGAlib atop GGI would give it access to all GGI-supported graphics cards and CPU architectures, thus (hopefully) improving its portability.

  The fact that it would no longer be interfacing directly to video hardware would improve reliability; crashes would no longer be able to directly hang the machine. They might hurt something upstream; if that be a connection to an X server, then the worst that can possibly happen is that an X server dies.

  A library has been demonstrated that is call-compatible with Borland's MS-DOS graphics library, allowing easy porting of some MS-DOS-based graphical applications to Linux. This can breathe new life into some old applications; applications that used to be rather slow atop MS-DOS "FAT" have been found to really fly when you're using the rather more efficient ext2 and often not even touching the disk due to disk caching.

• And perhaps some new GUIs.

All this "good stuff" being said, all is not joy and bliss in paradise. The GGI project has not been quickly adding to their list of supported graphics cards and operating systems. In order to achieve "world dominance," they desparately need to support a wide variety of graphics cards and architectures. The numbers of graphics cards and chipsets are growing faster than they seem able to cope with.

The recent move to allow Libggi run atop various other infrastructures most notably including X is probably the best thing that could have happened; it allows people to start writing applications for Libggi with the expectation that they can run on X-based systems right now, with future efficiency improvements coming from later hosting applications directly atop the kernel-based KGI.

Some projects have come along using GGI; note the PSV - Postscript viewer.