nanogui: Thread: Re: nanoGui development

> No, but I was hoping it wouldn't be too difficult to do something very
> simple with a PTY and text output...

You can take the terminal emulation code out of the linux 8086 kernel to 
start with. That will make life simpler

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/

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

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: ####@####.####
> 
> 

Greg Haerr ####@####.#### writes:

	   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:

I'm a little unsure what you mean by ``upper level software mouse
cursor clipping.'' Is this something that's come up on the list
before, so that I should just read the archives for an explanation?  I
assume you don't just mean ``clipping the mouse cursor to the edges of
the screen.''

   [...description of planned architecture...]

Sounds good to me.

Maybe all this should be done in a shared cvs tree.  Is there a
nanogui cvs already?

On 5 May 1999, Ben Pfaff wrote:
> 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.

I think the Linus USB driver is intended to emulate some other mouse (I
think PS2 currently, though people were talking about other protocols), so
you shouldn't have any extra work to do for USB mice.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

The software mouse cursor clipping that is needed works like this:

When various line draw or pixel plotting routines are called, the mouse cursor
must be turned off before the low level graphics routine executes or when the
mouse cursor moves, the screen will be redrawn to the wrong value.  One
implementation of this could have the low level graphics driver turn off the mouse
before drawing.  This requires that each low level graphics designer/implementer
know about mice, etc.

	Since the code required to determine line/mouse intersection can
be shared with the clipping code for intersection detection, my proposal is to 
write (I've already written) a level above bogl which is device INdependent,
which users call instead of the low level directly.  This level implements all 
mouse cursor clipping as well as all pixel/line clipping.  This level also
has an upper level api that allows it to be used by nanogui or by any user
who wants "bigger bogl".

Alex has a CVS tree going for nanogui.  I am still trying to get setup under CVS.
Presently, I will get nanogui going to use unmodifed bogl libraries, then we
can worry about integrating them.

FYI: I've already had to write a bogl stub layer because of the bogl architecture
when bogl_vline is in fact a proc ptr, rather than a hard address.

Greg

On Wednesday, May 05, 1999 2:27 PM, Ben Pfaff ####@####.#### wrote:
> Greg Haerr ####@####.#### writes:
> 
> 	   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:
> 
> I'm a little unsure what you mean by ``upper level software mouse
> cursor clipping.'' Is this something that's come up on the list
> before, so that I should just read the archives for an explanation?  I
> assume you don't just mean ``clipping the mouse cursor to the edges of
> the screen.''
> 
>    [...description of planned architecture...]
> 
> Sounds good to me.
> 
> Maybe all this should be done in a shared cvs tree.  Is there a
> nanogui cvs already?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
>