From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Fri, 12 Nov 1999 12:15:18 +0100 (CET)

Re: Multiple users

 
> > I can only make suggestions, but he should have a look at using KGI-0.9 as a 
> > base and simply enhance the somewhat neglected KII input interface a bit.
> > Thanks Brian there is a patch that allows the input interface to be used
> > with kgi-0.9. 
> 
> I already told him about your work several months ago. In fact he did take
> several ideas from it :) I don't know if he has looked at it recently. I
> haven't talked to him in several months. I have been very busy with fbdev
> and now I'm helping port IRIX graphics infrastructure to linux :->

The whole thing? Could I have a look at it or is it 'closed source'?
I had a talk with some SGI engineers doing the OpenGL effort for Windows
about creating a proper DirectRendering environment.
I would be very interested in having a 'compatible' environment.
SGI's direct rendering infrastructure may contain quite some solutions
for problems I still have to resolve...

I don't want to reinvent the wheel every time... Though I don't hesitate to
do it if neccessary. :-))

> > I would be very grateful if his work could be used with KGI without having
> > to rewrite it again. 
> 
> Drop him a email (vojtech@ucw.cz). He is one of the most open minded
> kernel developers I have meet. I'm sure the two of you can merge your work
> together to make one kick ass system. You could learn alot from each
> other.

I've done that. We'll see his reply.

> > > [...EvStack..]
> > > He thinks it was really good work. The only real difference is its 
> > > less streams orientated. Linus hates AT&T Streams for some reason :(
> > 
> > Or other three-letter words...
> 
> I know. I'm having fun with PI DRI interface vs true direct rendering from
> IRIX unix. Yes SGI is helping port this over :) Alot of core developers
> are sold on DRI. I'm not. DRI doesn't even handle issues like the DMA to
> regular memory transfer problem. With serval card, evenb the g400, you can
> send commands to the dma to tell it to transfer the framebuffer image to
> memory. Now with this card you can transfer the data to anywhere in system
> memory. So you could even the first 16 Megs in your system. This is
> really bad. The way it handles locking is horrible.

Is this is because DRI leaves DMA programming to userspace code?
KGI drivers have to program DMA too, but 'validity checking' is done
by the graphics mapper. The application does never see physical addresses
in my model (yet, and I would be very unconfident having normal applications 
messing with physical addresses used somewhere in the kernel). 

How does it handle locking, and why is this horrible?
 
> > > Vojetch is working on the keyboard
> > > part and I'm working on fbcon so we can have a true multiheaded system.
> > > Note also the newest 2.3.x kernels have real resource management now. Its
> > > being worked on for other types of buses. So linux is finally evolving to
> > > the KGI level.  
> > 
> > Good to hear.
> 
> On a personal note. I have learned radical changes will never go in. I
> totally redisigned the fbdev API. I have a huge patch but I couldn't get
> it in. Now I am. You have to do it a small patch at a time. I make a tiny
> little change that hardly noticable. After awhile those changes add up.
> Even Vojtech is making that mistake. He has this new massive design which
> never got into 2.3.x but should of. What he needs to do is port it to the
> standard kernel a piece at a time.  

What if the underlying concept is so different that you have no
chance to code it a piece at a time?

			Steffen

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