From: James A Simmons <jsimmons@acsu.buffalo.edu>
  To  : ggi-develop <ggi-develop@eskimo.com>
  Date: Thu, 17 Sep 1998 13:02:56 -0400 (EDT)

Re: Makefile vote II

On Thu, 17 Sep 1998, Emmanuel Marty wrote:

> Geeze..
> 
> It's "forking week", or is everyone very nervous? Please, all, show some
> social skills.. We all want the same thing.

Yes I agree. Soory. I would more than anything love to see kgicon make to
2.2. When I saw QNX go in I though oh boy we have a chance but time is
running out. 2.2 is due to be out very soon. 

> 
> > Then I will change it for myself and present the my tree to linus. With
> > the new cvs browser I can see what you guys have changed. I see none of
> > guys don't think their is a snowball chance in hell of getting it in.
> > Well I think your wrong. QNX filesystem just got added to 2.1.121. So much
> > for a code freeze. Do you think linus will think QNX filesystem support is
> > more important than KGI.
> 
> Please do not do that. Steffen is right, it isn't a good idea to go ahead
> and change drivers like that. Especially as our plans don't end at the
> linux kernel and fbcon.. The new KGI API will be unveiled soon, we'll
> talk about it (if Steffen wishes) at the IRC meeting. A BSD port should
> finally happen soon..

I can't make the meeting send me a copy.

> 
> James, you have done a lot of appreciated work in the kernel integration
> area. Please find a better solution..? We are open to discussion..
> 

Yes I'm open to discussion. I though to move the header somewhere
else and change code to point their was a small change. Its not a change
to the API. 

  In fact I have a few ideas for the new kgi API. Could you send
me a copy of it. See I have been study other platforms like macs, ppc, and
sparcs. This was in the hopes to make KGI OS/hardware independent. So I
want to discuss some stuff in private. I very BIG into porting KGI. This
is one of the arguments against KGI. I like to see them eat their words.

  Also trying to place the code into the kernel showed me a few things we
need to change to the KGI API. Actually one thing. Here is the scoop.
Building a kgicon for each display is nice and dandy but what if someone
wants to place all their displays directly into teh kernel. Imagine
trying to link several peices of code witgh kgi_chipset_init. You will get
errors. Also what if the OS doesn't support modules (BSD) and they want
to do multiheadedness. Big problems here.  

 In fact the way I'm making the kernel system. If you compile kgicon as a
module it will still compile are vga driver directly into the kernel
instead of vgacon.