From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Sun, 15 Aug 1999 15:29:38 -0700 (PDT)

Re: Ping-pong buffers on KGIcon are here!

On Sun, 15 Aug 1999, Marcus Sundberg wrote:

> Jon M. Taylor wrote:
> > 
> >         Well, I have some cleanups to do tomorrow before I commit to CVS, but
> > it all works now.  You mmap() /proc/kgi/kgicommand 
> 
> I'm just back from vacation and haven't had time to look at the code
> yet, but how does /proc/kgi/kgicommand and /proc/kgi/gc work with
> multihead? 

	It doesn't, yet.  All of KGIcon currently runs in one global
context with only one process at a time able to lock the GC or the
KGIcommand FIFO. 

> Shouldn't there be one file for each head?

	Yes.  However, the current (lousy) state of frambuffer
virtualization in the kernel makes proper multiheading very difficult.  I
chose to punt on multihead until the underlying framework is stable.  Also
James Simmons is rewriting the /dev/fb stuff with support for a new
/dev/gfx which will virtualize the accel engine, so I am waiting for that
as well.  And if you have any good ideas about how to implement
multiheading within /proc/kgi, please let me know of feel free to hack
them yourself.
 
> Also, remember that LibGGI is in beta. Don't just break things without
> discussion like with the genkgi sublib. Please add code so it will
> still work with KGIcon drivers that use the older "hacky" GC-mapping.

	I can imagine no situation under which anyone should ever have a
need to use the old 'hacky' GC-mapping, bugs aside.  That is why I removed
it.  If there is a reason that I missed, please let me know.

> And _please_ write code that cleans up after itself:

[snip]
 
> On a related note the procfs code in KGIcon does not
> * check the return code from vmalloc()
> * check the return code from proc_register()
> * use vfree() and proc_unregister() when the module is unloaded.
> and it isn't surrounded by #ifdef CONFIG_PROC_FS
> 
> You are doing a great job on KGIcon as well as MesaGGI, so I'm a little
> surprised that you make these mistakes...

	Sorry about that.  I plead excessive haste.  I really want to get 
this stuff up and running quickly so we can have a competitive solution 
to the XFree86 folks's DRI.
 
> Just remember - everyone!
> Always check your return codes.
> Always free what you have allocated.

	Working in the kernel corrupts your programming habits |->. 
There, you mostly do all your allocations at init time and there are not a
lot of return codes to check....

Jon

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