From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  Date: Tue, 15 Jun 1999 12:07:58 -0700 (PDT)

Re: KGIcon 0.9 pre-alpha released

On Tue, 15 Jun 1999, Steffen Seeger wrote:

> Hello Jon,
> 
> > 	In KGI-0.9, the familiar chipset/clockchip/accel/etc modules are
> > still defined, but now instead of being hardwired into the API these modules
> > are predefined instances of a generic KGI_SUBSYSTEM class (not an OOP
> > 'class', ICYWW). 
> 
> ICYWW??? 

	In Case You Were Wondering |->.  I've used that one like four times
in nine years on the net, but it does come in handy sometimes. 

> This is the basic idea. I want to add the common intra-module 
> API functions as well to the kgim_<subsystem> structs. These so it 
> becomes quite like OOP in the end. The benefit is that we only need
> to have the various init_module() functions public.

	Yes.  I forsee a nice COM layer developing.
 
> > Therefore, fbcon-kgi.c has both an easier and more
> > difficult job now.  It is easier in that, once loaded, fbcon-kgi.c just sits
> > around and waits for other KGI_SUBSYSTEM-exporting modules to be loaded and
> > hook themselves into fbcon-kgi.c's management framework.  All the
> > special-case handling that fbcon-kgi.c does now (initializing
> > chipset/ramdac/etc, mapping the GC/MMIO region, setting up the sysctl
> > interface for the monitor driver, etc) will thankfully be EOLed.  All that
> > the new fbcon-kgi.c needs to do is be able to map generic objects which it
> > gets from the KGI driver(s) in a predefined set of ways, and handle
> > driver-specific abstracted commands - __MUCH__ cleaner and more powerful.
> 
> If possible, kgicon should not make assumptions about the internals
> of drivers. 

	It has to, at least to some degree.  It has to be able to interpret
the top-level kgi_mode in order to properly implement the fbdev interface. 

> The reason is that the KGI-driver modules are taylored to
> the most common -- but nontheless particular -- hardware model.
> 
> So, ideally kgicon would just do minimal management, provide the environment
> (display registration) and do the bridging to fbcon.

	Yes, but some assumptions will have to be made somewhere IMHO.  
Hopefully they will be small and clean.
 
> > What will (might?) change:
> > ==========================
> > 
> > * The KGI core will now be a logically separate kernelspace entity, able to
> > export and implement its own communication channels and APIs through /proc. 
> > This means that we can stop doing any KGI communications through /dev/fb.  No
> > more GC/MMIO mapping hacks using the mmap() offset parameter as a map-type
> > flag - each will have its own mapping(s) handled properly through /proc/kgi. 
> > This will break the LibGGI genkgi target and perhaps the fbdev target as
> > well.
> 
> If possible (and if you agree in terms of copyright) I would like to use this
> technology for KGI-0.9 as well. This could allow us to have the same 
> userspace environment for true KGI and KGICON.

	Sure!  Creative has agreed to let me release non-proprietary code
under X-style licenses, so as long as the (C) Creative Labs remains on any
substantial portion of the code it should be fine. 
  
> > * The mondrivers will probably be loaded separately at runtime before the
> > actual video hardware drivers, so they cannot assume the existence of the
> > other driver subsystems.
> 
> All driver modules can now be loaded separately. To make a particular card 
> driver out of it, I wanted to use a simple binding module, that gets 
> loaded last; calling the appropriate _init_module() functions.

	Isn't that 'module' the KGI/KGIcon modesetting framework itself?

> This should even allow to link all subdrivers statically and do the binding
> with /proc... I have to think about this in detail.

	Yes, we need to plan this out.  In fact the binding probably _will_
be static for the first Savage4 KGI driver beta. 

> > * The ability to logically divide up the total functionality of a piece of
> > video hardware into any set of KGI_SUBSYSTEMs will mean that the LibGGI code
> > can no longer assume the existence of any particular subsystem interfaces,
> > only the top-level KGI interface.  For example, my Savage4 driver will 
> > (eventually at least) consist of the following separate KGI_SUBSYSTEMs:
> > 
> > 	* Chipset (chipset+clockchip+ramdac)
> > 	* 2D accel driver
> > 	* 3D accel driver
> > 	* DDC helper
> > 	* I2C helper
> > 	* STREAMS helper
> > 	* XAA API implementation helper
> > 	* D3D immediate mode API helper
> > 	* ...many others...
> 
> Right. But some of these may be implemented as userspace library modules.

	Sure.  The question of user vs. kernel is always present, and you
just have to ask if the code really needs kernelspace features to work well. 
But at least we have a more flexible choice now.... 

> The in-kernel part should just coordinate the hardware access and provide
> virtualization. 

	Also things like:

	* Provide IRQ/pagefault handling to usersapce
	* Implement interfaces which can benefit from kernelspace
	features (IRQ hooking, critical sections, etc).
	* Manage consoles/multiheading/events

> The libraries in the kgi-0.9/lib directory are an early
> study of this. Ideally applications would go through a libKGI that does 
> the neccessary communication with the low-level drivers.

	Yes.  If the LibGGI targets would use a LibKGI instead of a
helperlib, LibGGI could still make full use of KGI, portably, _and_
applications could also use the KGIcommand interface directly when possible
for maximum speed for games, etc.

> > LibGGI needs to be aware of all of this and be able to intelligently navigate
> > it as it currently does with its own userspace DLs.
> 
> We should probably separate this into a libKGI, but I am not yet sure 
> about this. libKGI should do all the stuff neccessary to establish the
> mapping to particular resources.

	Yes.
 
> > 	Steffen, I am sorry to report that I felt it necessary to make some
> > changes to your header files (no changes to the essence of the KGI 0.9 API
> > itself, of course).  Some of them are minor, like making all preprocessor
> > #defines uppercased to minimize namespace clashing.  However, there is one
> > major change that I made which I do not think you will approve of but I which
> > I strongly feel is necessary: the removal of the ggi* namespace and the
> > conversion of all its members to the kgi* namespace.  The ggi* namespace
> > belongs to LibGGI, and while it may be legitimate for some LibGGI userspace
> > code to use the kgi* namespace, the reverse should never be done.  The KGI
> > API must be able to stand on its own if it is to be truly portable.
> 
> Just checking: GGI namespace/references are used 
> 
> * in the portability layer (__ggi_sys_). Actually it should be __sys, but 
>   that might give clashes with the system in general. I am fine with
>   __kgi_sys.
> 
> * for error codes. (historical reasons)
> 
> * in the word 'debugging' (interestingly :-)
> 
> So, as this is only internal to KGI/not yet used, I am fine with that cleanup.

	Great!

> You could save me the time to redo the changes by sending a diff of the changes
> against the original tree. Thanks.

	I will do that today.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed