[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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)

  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

  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

--- 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)      (|     | )
    -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    /'\_   _/`\

Reply to: