nanogui: Cleaning up the source trees
Subject:
RE: Cleaning up the source trees
From:
Alex Holden ####@####.####
Date:
29 Sep 1999 20:21:52 -0000
Message-Id: <Pine.LNX.4.04.9909292055520.387-100000@hyperspace>
On Wed, 29 Sep 1999, Greg Haerr wrote:
> It's really more complicated than this thread gives merit.
> BOGL only supports framebuffers. NanoGUI (or at least MicroWindow's
> implementation) supports framebuffer, SVGAlib, ELKS and MSDOS. The funny
> thing is that all these systems are PCs, and have the _same_ VGA card in them.
Because the framebuffer is an abstraction, it will work with any
architecture/graphics hardware capable of supplying a framebuffer.
> So why the heck do we have to write four different drivers? Well, the way
> you're proceeding, we do. But you see, a far smarter approach is to
We don't. To be honest framebuffer is the cleanest solution where you're
running Linux 2.2 and a Linux framebuffer driver is available for your
hardware (because it provides abstraction and mediation between several
programs accessing the hardware at once), direct hardware support is
necessary on non-Linux, but has the disadvantage that only one program can
access the hardware at once and the driver has to be written specifically
to support that hardware, and SVGAlib is really just a way to support SVGA
cards on 2.0 Linux machines.
> separate the VGA read/write code specifics from the framebuffer stuff, for
> instance. In this way, (which I've implemented) you can write a VGA driver
> once, and then write other routines once for framebuffer, once for real mode,
> once for etc, etc. Get it?
I see why that's useful for plugging in a hardware driver for
drain-bamaged hardware which doesn't support a proper frame buffer, or for
providing hardware specific acceleration support, but the frame buffer
code is still useful for getting something up and running quickly and
non-optimally on hardware which can easily provide a memory-mapped
framebuffer.
> I'm not against BOGL. I like BOGL. But we're going quite above and
> beyond what Ben original tried to do with BOGL. There are other tech issues
> as well if you'd like to get into them.
Yep, which is part of why Bogl should be a seperate library which can be
linked into Nano-X together with a bogl screen driver (as opposed to a GGI
screen driver, or a direct hardware VGA screen driver, or a SVGA screen
driver, or a direct hardware hercules screen driver, etc.) rather than
being distributed as standard with Nano-X.
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------
