Index: [thread] [date] [subject] [author]
  From: Jon M. Taylor <taylorj@gaia.ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 16 Aug 1999 15:24:51 -0700 (PDT)

Re: Ping-pong buffers on KGIcon are here!

On Mon, 16 Aug 1999, Marcus Sundberg wrote:

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

	OK.
 
> > 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. ;)

	OK, I already did that for the auxbuffer mappings, but I'll move
the gc and kgicommand mapping files there as well.  Is that what you mean? 
 
> > > 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.

	Fair enough.  I'll put it back.

Jon 

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

Index: [thread] [date] [subject] [author]