When libggi opens one of the graph devices for writing, it gets a file descriptor. KGI implements a few standard "ioctl" operations on the file descriptor:
One might immediately wonder: Just some mode setting, some memory copy operations, and that's it? Where's the draw circle, the flood fill, the shade polygon? But remember: the kernel code isn't supposed to do drawing. Its purpose is to support libggi. Adding more drawing primitives would increase the complexity of the kernel --- and libggi just doesn't need them. The operations listed above are plenty for libggi to implement unaccelerated graphics.
For accelerated graphics, libggi needs a little more. To make acceleration possible, display drivers are allowed to supplement the basic set of operations with additional ones. The various video card drivers are not required to standardize on these supplemental operations. For example, the trident 9640 driver could provide a "bitblit" ioctl. The Matrox Millenium driver could provide a "render array of 3D shapes" ioctl. Most video drivers let libggi draw directly into video RAM, by providing a "mmap the frame buffer" function. Many drivers provide functions that bypass the abstraction layer. For example, some display drivers provide a "mmap the video registers" function. If the author of the display driver can think of some fast way for libggi to control the video card, then the author should implement it, by all means. These extra functions, provided for speed, are called the "acceleration functions".
We chose not to standardize the acceleration functions. Doing so would shoehorn video cards into a framework that might not fit them. Worse, it would require display drivers to emulate all the drawing primitives not supported by the card, easily increasing the size of the kernel driver by an order of magnitude.
Most importantly, though, libggi just doesn't need standardization in the kernel display driver. Libggi was designed to be able to draw on many different kinds of devices. It can draw on virtual consoles, but it can also draw on X windows, on 3Dfx devices, even on an ascii art renderer! Libggi dynamically loads device-specific libraries to help it deal with a variety of different display devices. One can add support for a new device by merely adding a device-specific library to libggi's repository. When a KGI display driver adds some unstandardized acceleration functions, it is merely creating a variant of an existing display device. The author of the display driver is expected to write a device-specific library for libggi's repository. This is a simple procedure. In this way, libggi easily deals with the variations in the display drivers created by acceleration functions.
Of course, this all happens transparently to the user of libggi. To the user, libggi just works faster when it's being used on an accelerated card.