From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Fri, 30 Jul 1999 12:59:22 +0200 (CEST)

Re: Regarding GGI and Xfree 4.0, Forwarded.

Hello,
 
> This is the relevant mail from the discussion that took place, the thread
> more or less died after this letter.
> 
> Johan Karlberg.
> 
> ---------- Forwarded message ----------
> Date: Thu, 29 Jul 1999 11:56:17 -0700 (PDT)
> From: Mark Vojkovich <mvojkovi@ucsd.edu>
> Reply-To: devel@XFree86.Org
> To: devel@XFree86.Org
> Subject: Re: ROM BIOS
> 
> On Thu, 29 Jul 1999 core@triton.net wrote:
> 
> > Has GGI not already implemented a non-os-specific non-architecture-specific
> > multiscreen capable, standardized video card interface?
> > I have noticed that no discussion of GGI has taken place recently on this
> > list, I am fairly new to this list...
> 
>    Perhaps that's because most people here thing GGI is a bad
> idea?

I wonder what information they base their toughts on... Also I cannot follow
their reasoning why GGI/KGI is a bad idea.  However, this touches a 
religious can with an extremely high population of worms in it and I 
am not willing to open it.
 
> > GGI also provides transparent acceleration(currently 2D only), and because it
> > exists in kernel space it would allow direct access to 3D accel functions,
> > which I beleive would be out of place in the Xserver... I think that X should
> > move towords implementing a single server ontop of GGI, and that all of the
> > driver development should move to ggi, this would be congruent with all other
> > modern OSes approach to every other hardware device sound(OSS/ALSA),
> > networking, etc...
> 
>    The fastest approach is having the Xserver access the hardware
> directly.  GGI advocates don't understand the performance implications
> of what they are suggesting.

This is a long-existing and deep-rooted misunderstanding. All XFree developers
I met so far seem to think we want to move the whole server to kernel level
or having it not touch the hardware at all.

This is simply nonsense. 

The driver and in-kernel part (what they are worring about, I guess) are to
do access control and resource/state management, not to do the actual 
rendering. 

With KGI you can have the X server touching the hardware as directly as 
before, but you can also have it using other (saver/faster) methods if
they are there.

This gives me the impression that they never really cared to look at what
KGI (the relevant part for driver development) is really about. I _have_
looked at XFree 3.9.15, the first snapshot available to me and they 
have done a lot of good work to it.

However, the principal approach makes me nervous sometimes, especially when
XFree intends to handle tasks that clearly belong to the kernel, like
bus bridge management, AGP GART management, etc.
 
> > Also for those who might be against this, GGI is a very small kernel module,
> > most of its support(acceleration) resides in user space as a shared library,
> > and it is orginized is a modular fasion, very compatible with XFree86 4.0's
> > structure...
> > 
> > Any comments? please no flames about non-portability, they are simply not
> >               true...
> 
>    I gave the GGI folks a personal invitation to join XFree86 
> to work on a GGI driver for XFree86 4.0.  They declined.

Yes I received Marks invitation, and replied what the status of my 
work was at that time and forwarded his mail to Andy.
I also told him that KGI keeps me busy and that I will work on a XFree4.0
experimental server once the KGI core services are running/tested.

I as well gave before Dirk Hohndel (the XFree86 vice) invitations several 
times(Linux Congress in Wuerzburg, LinuxExpo98), to have someone from 
XFree having a 'guided' look at our work, but none of them seems to worry.
 
>    I'm certainly not going to write a GGI driver; I don't even
> like GGI.  And if the GGI folks don't even want to write a GGI driver
> for XFree86 4.0...
> 
> 				Mark.

a) I certainly not declined interest in an XFree 4.0 based server on top of
   KGI/GGI. So Marks statement 'as is' is not correct. Yes, there has been
   no further discussion/contact, mainly because there is not much sense
   diving into X server code without the KGI-0.9 part being far enough to handle
   mode-initialization and basic resource handling. This is my part to do
   and I am donating the spare time I have to this. You can see the progress
   on my snapshot page (http://www.tu-chemnitz.de/~sse/ggi). Which hasn't 
   been much lately... (amount of spare time)

b) I made clear that this can't be a one-way effort. We do need support
   from someone who is familiar enough with the XFree4.0 architecture willing
   to comment on possible problems with KGI from a X server developers point
   of view. We said that from the very beginning of GGI, and never since 
   anyone close to this profile popped up. (Except Markus, who has done
   good work with XGGI so far).

c) I don't like the XFree approach to hardware access either, but I am 
   actively trying to do something about it. Getting KGI-0.9 running is quite 
   essential for getting an XFree4.0 server running on top of it.

Bottom line is that I learned not to expect any support from the XFree86 team
so I will have to live with it. As much as I would wish any change
to this situation.

Regards,

			Steffen

----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------