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

> I'd like to 'summarize' the last week to have the discussed things collected in
> one list. This should also give some points of further discussion and simply
> list the things we agreed on so far. And here we go:
> 
> * 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 use ld ... ]
 
> 	  - new initialisation scheme.
> 	    1) chipset driver enters desired resolution (xwidth, ywidth, depth)
> 	    2) monitor driver changes VCLK to meet it's limits
> 	    3) RAMDAC changes VCLK to it's limits and enters DCLK
> 		(please note: this is different from my first proposal, as I
> 		had to realize that the RAMDAC is the limit here. (VRAM-RAMDAC's
> 		have fixed mutliplexing schemes thus the chipset has to meet the
> 		RAMDAC, not vice versa.)
> 	    4) Checked by chipset driver, modifies VCLK, DCLK (keeping ratio) to
> 	       meet it's limits.
> 	    5) Clock driver enters next suitable value for DCLK, modifies VCLK
> 	       and DCLK keeping the ratio.
> 	    6) checked by Chipset, RAMDAC, Monitor and then set.
[ System has been changed to allow even for chipset-specific resolution
  schemes. ]
 
> 	* complete state restauration when the modules get removed
> 	  (except video memory??)
[ Not really implemented - restore on device close is. ]

> 	* power management support (could be done easily)
[ VESA power management is supported - others could be done easily. ]

> 	* multiple card support (no solution/ideas so far :-( )
[ 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). ]

> 	* 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. ]

> 	* 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. ]