Re: [Re: resucitando un viejo 486 (GGI?)]
Hell-o Ivan Andres Hernandez Puga!
El día Sat, Mar 22, 2036 at 05:08:33PM CET
>> Ademas, si la gente usara GGI se podr?a elegir sobre como ejecutar las cosas
>> segun las preferencias del usuario y no por imposicion
> GGI? Que es, Graphic Gateway Interface? para que sirve, y donde esta la
> especificacion?
os paso un poco de info ;)
--- ggi ---
What is GGI?
Hartmut Niemann
$Date: 1998/06/29 17:07:22 $
This document tries to give a short (possibly simplified) impression
on what GGI is all about.
______________________________________________________________________
Table of Contents
1. The GGI mission
2. The GGI design principle
3. Things GGI gives you at no extra cost
4. Where is GGI now?
5. Things the GGI team wants to do, too
6. What about including GGI into the Linux kernel?
7. What about X?
8. What is evStack?
______________________________________________________________________
1. The GGI mission
We want to create a reliable, stable and fast graphics system that
works everywhere. We want to allow any program using GGI to run on any
platform requiring at most a recompile.
It all started out with some people being annoyed by the fact that
graphics in Linux means either X or svgalib, and if you use both at
the same time, you can easily crash the graphics card and make the
system unusable.
The Linux kernel does protect the hardware from faulty user access, so
all graphics programs need to be run by root or set-uid root, which
poses security problems. If two applications work at the same time
with the graphics chip, you can expect problems.
The GGI sets out to solve these problems.
The basic rules we identified are
o The kernel must be able to re-initialise the graphics board at any
time. Only then is the system protected from buggy graphics
applications, and only then is a true SAK (secure attention key)
possible.
o To make user-space graphics (outside X) possible, all operations
that require root privileges must be done from the kernel.
However, we can't do everything in the kernel if we want to avoid
having huge graphics drivers bloating it, which led to the GGI design
scheme described in the next chapter.
2. The GGI design principle
As stated above, security-critical functions like mode-negotiation
(you don't want a game to fry your monitor with a too high refresh
rate, do you?) need to be in kernel space. All requests ought to be
filtered, checked, scheduled and generally taken care of by a graphics
device driver in kernel.
All things that can be safely done from user space, typically like
setting a pixel on the display, should be done in user space instead
of the kernel. This has the twofold effect: reducing the size and
complexity of the graphics code in the kernel, and increasing the
speed at which such operations can be performed, since kernel calls
can be relatively expensive.
The big problem is that what operations are 'safe' depends heavily on
the hardware you are using.
o Some displays have a fixed size and resolution, so mode negotiation
is almost non-existent, and the kernel can safely export the
complete video memory (aka frame buffer) to a user application. In
the worst case the program will display garbage on the screen.
o Some displays do not have a frame buffer to give access to.
o Some cards have important accelleration features but are poorly
designed so that erroneous or malicious code could lock up the
computer. Other cards are well-designed enough that accelleration
features can be used directly without risk.
o Some cards use interrupts or allow DMA access -- both are obviously
the domain of the kernel.
As a result, if one wants to create a uniform kernel API to support
all of these features, it must then contain emulation code for all of
those features particular piece of hardware does not support. Under
those conditions, the kernel driver would become massive and slow,
even though many things like line drawing on the framebuffer could
have easily been done in userspace instead.
GGI has proposed a solution to this dilemma -- allow the kernel API to
be hardware-specific. A library, LibGGI, presents a uniform API to
applications.
LibGGI contains functions for all the various graphics operations, and
depending on the capabilities underlying hardware and kernel
interface, it will either emulate them in software, in userspace, or
make use of an accellerator function exported by the kernel in some
manner. The user program need not concern itself with how a particular
graphics function is implemented, or even with what operations the
graphics hardware supports.
Side note: in a later stage, more complex functions like textured
triangles will be supported, and these will go into a separate library
which will use the same design.
Side note 2: Text mode is included as a 'special' graphics mode in
this scheme.
Bottom line: GGI is a graphic API that is implemented partly in a
shared library, partly in Kernel. The line between these parts is
drawn to get maximum stability (first) and maximum performance
(second) with minimum kernel bloat, and that line is drawn on a card-
by-card basis.
3. Things GGI gives you at no extra cost
If you have a library that implements a consistent API on top of
various card-specific kernel APIs, it is not a big step to implement
this same API on top of other userspace APIs as well.
LibGGI, in addition to using (multiple) kernel drivers, can also work
on top of
o X (with currently three different implementations, this runs
successfully on SGI Irix and other Unix systems)
o svgalib
o the 3DFx glide library
o and others.
On Linux, all of these targets are available without recompilation,
using dynamic loading. The same binary runs on all supported display
'targets' -- support for new targets not present at time of
compilation can usually be added without recompiling the application
or LibGGI.
4. Where is GGI now?
GGI is currently under development. The list of supported chipsets is
slowly growing, the API has stabilized. Support for more complex
drawing operations than circles has only just begun.
If you want to use the LibGGI in your application, in my opininon you
can safely start. The user API is not likely to change very much in
the near future (you never know, though). I use it as a very
convenient method for graphics in X now.
If you want to develop a kernel driver, be aware that the kernel
interface is still a (albeit slowly) moving target. If you don't fear
that, you are more than welcome!
5. Things the GGI team wants to do, too
Most notably: we want to improve support for multiple graphics boards
in a single x86-based Linux PC. This already works very well for some
driver combinations.
We want to support natively all other Linux branches, but currently no
one in the team has time, skill and hardware to do so.
We want to support all OSs we can. Once again, there has not been a
chance outside Linux yet except for several Unixes (AIX,IRIX,Solaris)
running the X target and Solaris/DGA.
6. What about including GGI into the Linux kernel?
We are not, and will not be, ready for 2.2. We are planning to try to
come into early 2.3, if we have made sufficient progress.
7. What about X?
X is the de-facto-standard for graphics applications in the Unix
world. The GGI project aims to support X and increase it's
reliability, by providing high-quality, secure video drivers for it.
We believe that letting the X server access the hardware directly is
the second best solution and have implemented an X server, which uses
the LibGGI as an intermediate layer. We believe this will prove to be
more reliable and significantly stabler than X servers that access the
hardware directly.
The next public release of GGI will allow you to use traditional X
servers and other (typically set-uid) legacy graphics applications.
8. What is evStack?
EvStack is a radically new way of programming console and user-input
drivers for the linux kernel. It is based on the idea of passing
events in a streams-like manner (though much more efficient) from one
subsystem to the other to cleanly separate the pieces like
o hardware drivers (keyboard, mouse, joystick, video, ...)
o interpretation (keyboard mapping, mouse protocol, terminal
emulation, ...)
o add-ons (scrollback, selection, conlinux compatibility, ...)
The EvStack system is not directly related to GGI/KGI, but it does
make it considerably easier to take advantage of the advanced
capabilities that KGI offers, like: per-console fonts and font sizes,
graphical VTs, extensive and flexible multihead support, and much
more.
--- ggi ---
--
Nos leemos...
.--.
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |o_o |
SKaVeN - skaven@linuxfreak.com |:_/ |
Linux Pauered (Debian GNU/Linux 2.1 Slink) // \ \
Linux Registered User #158497 (http://counter.li.org) (| | )
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- /'\_ _/`\
\___)=3D(___/
Reply to: