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]