From: James A Simmons <jsimmons@acsu.buffalo.edu>
  To  : ggi-develop@eskimo.com
  Date: Fri, 11 Sep 1998 21:03:08 -0400 (EDT)

Re: Open list of issues before Degas goes out

On Fri, 11 Sep 1998, Emmanuel Marty wrote:

> It's me again :)
> 
> I guess we should start thinking about a Degas release. Dali has been out
> for a long while now, and things have changed a lot in the linux kernel
> graphics world.
> 
> Here is a list of things that I am thinking about, that need to be done
> before we can start a complete feature freeze, then debug and test like
> crazy until we can consider it as a public release :
> 
> * Licensing issues

I though that was settled.

> * Adapting kgicon configuration to the kernel, or the opposite, but
>   we need to do some seamless integration.

I have done most of this. Its at my web site.
http://www.afterfive.com/~jsimmons/linux-kgi.tgz. I believe I have
directions on my web page.

> * Obviously, decide something on that synchronous rendering topic.

IMHO. Remove SYNC and place it in a extensions library. Use ASNYC as the
default. ASYNC is better. Yes Xlib works by ASYNC. Also being a X windows
programmer there is a specail call that can force Xlib into SYNC mode.
This is only to debug programs. Its nice to see when a error occurs in
your program. In ASYNC mode you can't tell when the error occured.

> * Getting the generic monitor driver to become the standard and
>   remove the others.

Yes. The generic monitor driver is working well. I like the idea of using
a default low level vga monitor setting. Then using utilites to optimize  
your monitor. By the way marcus using ioctl is better than using sysctl
because sysctl is specific to linux, ioctl works with any unix. I just 
hate suser their. Could we put suser in fbcon-kgi.c and pass a flag to
specify if its okay to perform a function like changing a monitor;s
settings.

> * Get all drivers to work in all modes with fbcon, accordingly debugging
>   fbcon if necessary.

We need to figure a way to fix text mode. Geerts does any other frame
buffer device do graphics and text. Something we could model after.

> * Potentially, this autoconf/automake issue.
Lets just post biniaries on our web page. You don't know how many times I
have download software and it didn't compile. I had to hack up the
Makefiles to get it to work. Sometimes the code. But we should make the
code avaliable to anyone who wants it. 

> * Testing
Doing that. I just switched my trident card for a S3 Virge and a Cirrus
Logic Card. Yes multiheaded finally.

> * Debugging

Doing that.

> * Some more testing

Defintely

> ..
> 
> The goal being to provide driver modules that fbcon can use for
> rendering without users messing with kernel compilation; as well

On my web page you just gunzip unatr into kernel. Run make config, make
zImage etc.

> as libggi with if possible an API that really-we-aren't-shitting-
> you will stay the same from then on. Ideally the drivers would
> be integrated in the kernel tree (as, like the QNX filesystem
> that was just added, they don't break _anything_). And libggi
> would be distributed as rpms/debs/whatnots as well.

Yes. Easies to get from your main web page. Big Letters. Grab it now.
With new post place a giant NEW get this biniary.

> 
> Do you think we could aim for a release on the night of 24 to
> 25 december ? Like we were going to do last year :) It's far
> away enough, I think.
> 
Seems reasonable.

> Okay, I'm done babbling for tonight (my from: address isn't
> for the status, it's just that the list doesn't seem to like
> the MX records for suntech.fr, I'll figure it out eventually :)
> 
> --
> Emmanuel
> 
>