From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Mon, 16 Aug 1999 21:49:52 +0000

Re: Ping-pong buffers on KGIcon are here!

Jon M. Taylor wrote:
> > 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.

Even if Linus will put that in (he doesn't seem to be very positive to
adding more features to fbcon...), it surely won't happen in the 2.2
series.
We should do the best we can, and at the very least support several
applications running on _different_ heads like we have done from the
beginning.

> 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.

Simply use a /proc/kgi/<n>/ subdir where <n> is the number of the
framebuffer as stored in the_info.info.node.
Breaking the multihead support is not a nice way to demonstrate KGIcon's
competitiveness. ;)

> > 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.

Because we don't want to force people using an old kgicon version to
recompile and reboot the machine if they don't want to. It's less than
10 lines of non performance critical code, so there is no reason not
to keep the old method.

> > 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....

Hmm? You need to check return codes at init time just as much as at
any other time.


Oh, and while I remember it - please add changelog entries for your
previous as well as future commits to LibGGI in libggi/ChangeLog.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se