> Hi all,
> 
> 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 ?
[ ??? ]
 
> * 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 ]
 
> 	* 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)
[ ... ]
 
> 	* graphics lib to allow user progrms to interface the GGI (no root SUID
> 	  and clearly separated from the kernel part (KGI))
[ ... enhance this by changing names in the drivers ]
 
> 	* 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.
[ ! Change system to meet new requirements ]
 
> 	* complete state restauration when the modules get removed
> 	  (except video memory??)
[ Not really implemented - restore on device close is. ]
> 
> 	* prevention of overdriving any hardware part properly set up (we should
> 	  rely on a proper installation for the drivers) 
> 	  - fixed mode table monitor driver was proposed. (I think this could be 
> 	    easily implemented using the mentioned design)
[ Is done .]
> 
> 	* power management support (could be done easily)
[ Hooks are there. ]
> 
> 	* 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. ]
> 
> 	  - several (virtual) graphics devices, each one may be opened by one 
> 	    application. (something like a graphics tty)
[ Done. ]
> 
> 	  - state save when switching consoles. (video mode, palette, pointer
> 	    shape and position, video memory (optional)) 
[ Done. ]
> 
> 	  - automatic console swiching when a process becomes active or when
> 	    kernel messages occur... I dont'like that. We should rather queue
[ switching can be forced,but I don't like the idea either ... ]
> 
> 	    these (the last 16K) messages up and present them at the end of the
> 	    graphics program. But we could also use the split screen feature 
>             for this. (We reserve memory for one line and let this line pop up
> 	    if a message has to be displayed and then scroll from right to left
>             on the bottom text line of the screen. This could be done by a 
> 	    daemon. ;-)
> 	    BUT: THIS IS VERY SPECIFIC TO VGA!!!
> 
> 	* generalized pointer device and/or keyboard handling
[ not implemented now ]
> 	  - 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. ]
> 
> 	  - extensive use of linear address mapping capabilities. 
> 	    Older cards (like VGA) have to be 'tweaked' to meet this (e.g.
> 	    page selection via page faults).
[ done. ]
> 	    As I have not very much experience with this, please, could someone
> 	    give an explanation of the mmap interface that has developed so far?
> 	    (e.g. how to mmap a linear address window for video memory and one
> 	    for MMIO into user space? How about, Michael? ;-)
[ First one is easy - look into linux/drivers/char/mem.c . For the second I
>   do not know. ]
> 
> 	* 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. ]
> 
> 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.
[ make up a interface ... ]