Hello Folks !
-------------

This is a new approach to create something like a GGI (General Graphics
Interface) for Linux.

For all who already know what GGI is: The new version is (as always) on

TSX.MIT.EDU : ftp:/pub/linux/ALPHA/scrdrv/scrdrv-?.?.?.tar.gz

Should there be two versions, the newer is probably very alpha and will 
not compile or work flawlessly.
Please note that the files "fb*" in that directory belong to a different
approach that is now completely separate from scrdrv. 

For the others :

We all know that it is a real mess to work with lots of different graphics
and textmode systems all on the same Linux console :

There is XFree with its own (complicated) config and Svgalib with another
one and SVGATextMode with yet another.(Not to mention DOSEMU using the
cards BIOS).And there are several "special" applications (like vgamp) out
there that use their own approach ...

They all bring along their own drivers (though source is quite the same, as
one adapts it from the other ...) and they do not interact nicely at all
times ...

This is the reason, why I wanted to create a new interface that all systems
could depend on and request all the graphics services they need from.

There were some major flaws in the existing systems that I really wanted to
have corrected:

1. All graphics programs needed to be suid-root, as they needed to use the
   iopl()-call which is super-user only.I deem this to be a major security
   risk,as I personally would not like to install such a program from a
   binary-only distribution,while binary-only is necessary for commercial
   purposes (e.g. DOOM, ...).

2. Ease of configuration <=> optimal usage of system ressources
   While svgalib is easy to configure,it does not use the system at the
   edge of its capabilities - most modes run with quite low refresh-rates.
   On the other hand XFree allows you to configure the system according
   to its limits,but the config-file is VERY hard to setup for the beginning
   user.

3. No "central" control over the graphics,resulting in problems when
   switching between VTs with different graphics-packages running.
   There is also a systematical problem with VT-switching : An ill-
   behaved application can lock the system (except in case you applied the
   SAK patch ...).

4. Special servers for accelerated cards (XFree) or only limited
   acceleration support (svgalib)

(NOTE: ALL THE MENTIONED PROGRAMS/SYSTEMS ARE GREAT AND I DO NOT WANT TO
 FLAME ANYONE WITH THE ABOVE STATEMENTS !)

My approach tries to overcome these limitations/problems by the following
concepts:

1. The graphics-subsystem is installed a KLM (kernel loadable module)
   what results in :

   a) no need for suid-programs,access permissions for the graphics-device
      will be sufficient,thus allowing control over who has access to
      graphics-mode applications.

   b) all graphics/text-modes on all VTs will be controlled from a central
      authority,thus guaranteeing perfect interaction.

   c) easy configuration by choosing the right files (one for the monitor,
      one or more for the graphics-card) and linking them together to a module 
      while still using the hardware at its limits (thus the monitor-driver !).


2. An open interface to the driver via the graphics library:

   The library will first ask the driver to do a requested task (like
   drawing a filled box) on its own.If the driver is capable of doing 
   so (i.e. it has an optimized function for that,maybe the hardware can
   do it all by itself) it will service the request and everything is done.

   If it cannot it will return an error to the library, stating that it is
   not capable to do a DrawBox either just now (maybe due to a strange 
   drawing mode, the library will retry at the next call to this function),
   in this mode (thus the library will retry when modes have changed) or in 
   any case (so the library will never retry). The driver may also give away 
   a hint whether the library should try to use lower-level functions (which 
   might have accelerated support) or use the mmap()ed graphics-buffer 
   directly.

   In these cases the driver will try to emulate the function by reverting
   to more primitive functions - e.g. to draw lots of horizontal lines.
   This function will then be handled as above - either by the driver or the 
   library will use even more primitive functions (like DrawPixel) to fulfill 
   the request.

   Most of the time a hint to use mmap() will be ignored (e.g. it does not 
   matter for drawing circles), but for example filling the screen might use
   another method (memset in the place of several hlines) to gain some speed.

   As a consequence from this architecture, the driver will not need to 
   support hundreds of "standard" algorithms (such as e.g. Bresenham for
   line-drawing),if there is no need to do so,as the library would use
   it anyway,when the driver says "DrawLine is unsupported".

   This will also speed up driver development considerably, as all that
   has to be done is to write code for setting the modes and switching
   pages.Anything else can be done by defaulting to standard functions.

   The driver will already work at this stage and (for unaccelerated cards)
   will probably be almost complete.For accelerated cards you can add
   acceleration support slowly - function by function until it works ...

   The drawback is a slight loss of speed, as every call to a graphics-
   function will include a "switch()"-statement that chooses whether to
   check the function for availability (once only,the function will be 
   performed,if successful,else the switch-argument will be altered to
   "emulate it"), or to use the driver-funtion or to emulate it.
   I consider this to be quite unimportant as a calculated jump does not 
   need that much time.

3. A really COMPLETE graphics library that will be put together from the
   XFree and Svgalib sources (and anything else we find useful) so that
   EVERY application will find what it needs in this library.

   I do NOT want the old mess of everybody doing its own job to turn up
   again - the new interface should be easy to integrate into all major
   graphics packages - in the best case only a small "compatibility-
   library" should be needed to fuse the worlds together.

   The current version is quite close tho svgalib - a "#define vga ggi" 
   at the beginning of the source should do some of the work.

   But as I wanted to get a really "consistent" interface it seems to
   me that a compatibility-lib will be needed.

   I have ported several applications using different graphics packages
   (DOS BGI,DOS with some own drivers,SVGALIB and the plain assembler
    approach of vgamp) to the driver and it was a matter of a few
   minutes in either case.


So now let's come to the point of it - why all this talk ?
=====================================

I NEED YOUR HELP !
==================

The package you received with this file is FAR from completeness, but that
does not mean it can't be used now - it works really fine for me, except
for some flaws that will need patches to the kernel to correct - particularly 
the VT-switching code.

I am NO graphics-wizard - in fact most of the code in this package is stolen
from other packages (see CREDITS).

So I need volunteers for the following tasks:

1. Creating/improving drivers for all major graphics-cards. For most 
   unaccelerated cards this should be quite easy and maybe I do one for 
   the TVGA8900 Chipset myself, as I have such a card in my secondary 
   system (But tell me,if you want to do it ... ) .

2. Creating drivers for the lots of really good monitors out there,that will
   be better off using a special driver than using the "dumb" one.
   I already have written a "dumb" driver that will only use a given set of 
   modes that are loaded from your existing XF86Config file.
   Thus this is not too important anymore.
   For many multisync-type monitors reconfiguring my multisync driver should
   work. A monosync driver for monitors that offer some fixed frequencies
   is in development.

3. Writing code for the graphics-library (especially emulation-code for
   graphics-primitives like filling polygons,...)
   If you don't feel like writing code you could at least look at the 
   existing source and tell me 
   a) how it can be improved
   b) what you would like to have supported

4. Helping me to improve the interface. 

5. Creating interface-libraries that will make the driver usable for
   svgalib- and libgrx (from DJGPP) applications. A binary compatible
   shared library for svgalib would make the lots of svgalib apps work
   without having the source ...

6. Building an X-Server using the driver. - Big task ... we should just wait
   until we have lots of drivers for just about any hardware - I think the
   XFree-Team will then do this all by itself ...

7. Creating a utility that will autodetect the hardware (if possible) and
   let you choose undetectable HW (like the monitor) from a menu or
   configure new values for generic drivers.
   We have a small menu-driven system right now, but automatic configuration
   would be preferred.
   Maybe SuperProbe would be a good point to start out with.

8. dunno now - but I am sure I will get lots of suggestions ... :-)

So - if you feel like joining my effort - send me EMail or join the mailing-
list that is mentioned in the doc-directory of the package.

Thanks in advance to all who want to help !

Andy
