Subject:
RE: FW: nanogui development
From:
Greg Haerr ####@####.####
Date:
5 May 1999 20:21:09 -0000
Message-Id: <01BE9702.85A0F6C0.greg@censoft.com>
Ben,
The clipping patch by Alan Cox is very similar to the stuff that was
included by Alex in nanogui v0.1. The problem with it, as discussed in an earlier
email with Alan, is that some upper level software mouse cursor clipping must
be performed as well, along with line segment reordering. I am building a
three-level driver model that will allow the following to take place:
o unmodifed low-level bogl drivers to be written without regard to clipping
for any number of hw architectures
o upper level nanogui server code
o mid level, shareable clipping and line segment reoordering code that
can be used with the nanogui project, or used with bogl libraries for people
that might want to just run bogl stuff without nanogui. This mid level defines
a screen driver api that will allow bogl or other graphics libraries to be used. It basically
defines as few entry points for things like line and ellipse drawing, and implements
bresenham line draw with clipping or calls fast low level (bogl) routines for vline
and hline.
I've got alot of thoughts on this mid level stuff, as this is where
potential bitmap conversions will have to take place for applications that don't happen
to have match the hw pixel layout with their bitmaps, etc...
I have all this running, and should have an update in a couple days.
In regards to your mouse comments, I like the idea of the bogl project
continuing to support varieties of mice, screens, etc, with the nanogui project
building the next upper layer that allows use of various lower level drivers for some
hardware independence, as well as implementation of more common algorithms,
like bresenham line drawing.
I will model the v0.3 nanogui after your latest bogl libraries, which seem to be revving
as fast as I plan nanogui revving.
On Wednesday, May 05, 1999 1:52 PM, Ben Pfaff ####@####.#### wrote:
> Note: I just subscribed to the nanogui list, hence the CC:.
>
> Greg Haerr ####@####.#### writes:
>
> Ben - I am forwarding you this email concerning my additions to the nanogui
> screen driver interface. I'm glad you're interested in working with bogl to get
> nanogui working well. Presently, I think bogl is on the right track, and shouldn't
> have clipping added to the low level. I will build a piece of nanogui that can be
> used with bogl for users requiring low level graphics plus clipping.
>
> Okay. Have you seen the code written by Alan Cox to do exactly that?
> There's a patch that was clean against older versions at least at
> ftp://cscw.msu.edu/bogl-clipping-ac.patch
>
> What would be cool is for people to write more low level bogl drivers for the
> different display modes supported by their video cards.
>
> The version that is in Debian cvs supports the following visuals:
> * 16-color EGA/VGA
> * 8-bit packed pixel with my original driver
> * 1-, 2-, 4, 8-, 16-, 24-, and 32-bit pseudocolor and
> truecolor packed-pixel visuals (code written by David
> Huggins-Daines ####@####.####
>
> So, I think that just leaves unusual visuals like Atari, etc. (now,
> admittedly, nothing's more unusual than VGA 16-color).
>
> -----Original Message-----
> From: Greg Haerr ####@####.####
> Sent: Wednesday, May 05, 1999 12:38 PM
> To: 'Alex Holden'
> Cc: ####@####.####
> Subject: nanogui development
>
> Following getting the nanogui project working, I propose and am working on the
> following developments:
>
> o complete separation of screen driver interface from the nanogui server proper.
> o integration with separately produced bogl and other graphics libraries
> o operation standalone and on non-linux systems
>
> This is complicated, but here's the idea. Currently the nanogui project uses a custom
> modifed version of the bogl graphics libraries developed initially by Ben Pfaffer over at
>
> s/Pfaffer/Pfaff/
Sorry about that, Ben.
>
> debian. These libraries only work with 8 bit color framebuffers, and require v2.2 linux.
> In addition nanogui clipping support is contained in the graphics libraries. Since nanogui
> v0.1, Ben and others have come out with quite a few more versions of bogl, ones that support
> truecolor, pseudocolor, etc.
>
> I believe that these are all merged in the current version now in
> Debian CVS. There's a recent snapshot at
> ftp://cscw.msu.edu/bogl-19990504.tar.gz
> Instructions for getting it directly from Debian cvs are at
> http://www.msu.edu/user/pfaffben/debian-cvs.html
>
> These libraries work on linux systems setup for truecolor
> display consoles. The console and framebuffer now have to be reset to 8 bit mode for nanogui
> to run.
>
> I propose that nanogui be rewritten to allow unmodified bogl libraries from debian to be
> linked in w/o modification. This will allow nanogui to run on many more systems, as
> well as someone volunteering a svgalib driver that will allow nanogui to run on linux 2.0,
> and ELKS, if someone writes a int 10h realmode driver.
>
> Currently there's a comment in the BOGL README about ``no plans to
> make it work with framebuffer support.'' That's only a statement of
> my own intentions; if someone else writes the driver code, I'm fully
> willing to merge it in.
>
> This requires that an explict screen driver interface be designed, and the clipping code,
> along with a host of other line-segment reordering code stuff be moved up into the
> nanogui kernel. In addition, the v0.2 kernel still doesn't support mouse cursor
> clipping during graphics draw code. This needs a redesign, since it's unlikely
> to be handled by the low level graphics drivers, without a lot of work for each one.
>
> The current iteration of the BOGL user-interface has a special
> pointer-drawing routine designed specifically for use with mouse
> cursors. I recommend that you take a look at it; I'm happy with its
> implementation. A more general getimage/putimage interface might also
> be useful, but it's not currently implemented because it wasn't
> necessary for the purpose that BOGL was originally targeted at.
I'll take a look at this. I haven't completed all the pointer drawing
stuff yet.
>
> I have completed all this work late last night, and should have this ready shortly. (I'm
> still asking for design input though). This will become v0.3.
>
> In v0.4, I should have completed the driver interfaces for the keyboard and mouse
> as well, which would allow nanogui to run *totally* standalone on anything that
> supports a C compiler. (yes, this is my real inspiration for the project, we don't need
> another X server, we need small projects that can run standalone and on top of existing
> operating systems without too much work)
>
> You should note that BOGL already has an associated mouse library,
> which even handles hardware detection to a limited extent (it's enough
> to detect the most common PS/2, PnP, and legacy serial devices). You
> might want to take a look at this. I'm currently considering USB
> mouse support now that 2.2.7 has USB support; it might be time for me
> to go out and buy some USB devices.
As I said above, I think it would be great to have BOGL be the place
for all sorts of people to add specialized hardware support. I'll tie it all into
well-defined screen, mouse, and keyboard apis.
Greg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
