/* This file contains a summary that was recently posted in our mail-
   channel and some comments (in []) by me. */

> * nominate a maintainer of the specs. (not me either :) who ?
[ Seems I and Steffen do this by having the full development directory at
  hand ... ]
 
> * define specifications (features, how they have to be implemented etc.)
> 	* set of hardware independend ioctl() to standardize video access
[ if based on scrdrv - partially done - this should be documented ... ]
 
> 	* use software to emulate common accelerated functions not present on
> 	  some cards (video acceleration, 3D triangle shading, etc.). Special
> 	  accelerated functions could be somehow 'registered'.
[ partially done ]
 
> 	* one major design goal is speed, but there are others (conflicting)
> 	  as well (portability (linux-68x00), no impact on kernel performance,
> 	  (nearly complete) kernel control over the video card, etc)
[ I am currently thinking of linux-68K compatibility ... it is possible, but
  it might blow up the driver quite a bit, as the linux 68K fb is quite a
  bit different. ]
 
> 	* compatibility libs for to allow older software to run under GGI
[ IMPORTANT THING to be done ! ]
 
> * problems/proposals/soultions mentioned
>    Hardware/KGI
> 	* module design, having a kernel loadable module for each major hardware
> 	  component (so far Monitor, RAMDAC, Clockchip, Chipset)
> 	  - there was a proposal to change this design slightly: the RAMDAC,
> 	    Clockchip and Chipset keep separate source files, but they form one
> 	    driver module which is linked together before inserting it into the
> 	    kernel. However, the monitor driver should IMHO be kept separate. 
> 	    (I would prefer this too, as I got some real headache because of
> 	    the RAMDAC detection: to detect the RAMDAC you need access to the S3
> 	    extended registers during the init_module execution which you don't 
> 	    have (as the chipdriver is not loaded yet). Having the modules tied
> 	    together would simplify this but not decrease modularity if we have
> 	    a clear interface between the drivers. We should also provide a 
> 	    configuration module that is linked to the other binaries giving
> 	    the possibility to give away the binaries only (commercial apps!).	
> 	    This should simply hold all the structures configuring the drivers
> 	    which are there declared external.
[ This is now done this way. Only that the monitor-driver is integrated
  also,but this is no problem for binary distributions - we can (maybe we
  even must to keep flexible) use ld ... ]
 
> 	  - new initialisation scheme.
> [...]
> 	    6) checked by Chipset, RAMDAC, Monitor and then set.
[ System has been changed to allow even for chipset-specific resolution
  schemes - #6 should really be done ... ]
 
> 	* complete state restauration when the modules get removed
> 	  (except video memory??)
[ Not implemented, don't think this is good. 
  Restore on device close is probably better. ]

> 	* power management support (could be done easily)
[ VESA power management is supported in a generic way (like in kernel) and
  somewhat cleaner for S3 - other methods could be done easily. ]

> 	* multiple card support
[ Use multiple devices ]

>    Console Handling
> 	* proper console handling, (virtual consoles, abnormal program
> 	  termination, etc.)
[ Working, but would like more kernel control. ]

> 	  - automatic console swiching when a process becomes active or when
> 	    kernel messages occur... I dont'like that. We should rather queue
[ switching can easiliy be forced using an ioctl. Any program that wants can
  implement it (i.e. klogd). See demos/saver.c for a sample implementation. ]

> 	* generalized pointer device and/or keyboard handling
[ not implemented now, but some hooks are there ]

> 	  - use of hardware cursors (as far as possible) or software cursors if
> 	    no hardware cursor supported (even in text modes?)
[ will do that when we have a mouse ... ]

> 	  - some kind of event generation when reading the device,
[ partially implemented ]

>    User Mode Interface
> 	* mmap interface
> 	  - accelerator functions via MMIO (if possible)
[ unsure about this .. probably dangerous and only possible with a VERY
  limited number of boards. ]

> 	* little/big endian handling. (This may also be done by the hardware as
> 	  some ATT and TI RAMDAC's  support little and big endian decoding 'on
> 	  the fly'.)
[ Not sure if this is necessary. I suppose just informing the application of
  the color scheme in effect would suffice. ]

> Anyhow there is another thing I came about. The ATT20c505 can use the CLUT to i
> index the RGB values in truecolor modes providing gamma correction. I think 
> this could be emulated for DAC's not supporting this. Anyhow we should at least
> tell applications that might use this feature (like xv color editor) that this 
> is possible.
[ Provide a RAMDAC_IOCTL for that. ]