nanogui: Thread: Bogl changes & Nano-X-0.5

I was just wondering what is happening with the Bogl code in Nano-X?
How far are we away from being able to use an unmodified Bogl library?
The reason I ask is that I would like to make a NanoGUI demo disk which
uses the VGA16 driver; I have the boot disk setup with a VGA16 frame
buffer okay, but the VGA16 driver in Nano-X doesn't work any more...
Is there anything I can do to help things along myself?

BTW, since Greg has volunteered to clean up all the loose ends I mentioned
in an earlier mail, I'm working on rewriting the networking code according
to David's suggestions.

On the subject of changes, I think we should have several pre-5 releases
before we release an official new version this time, and make sure
everything works properly before we release it. Since I've been having
some problems getting the CVS server to behave, and Greg doesn't want to
use it anyway, I'll have to juggle the patches myself and put up new
pre-releases whenever I get a few new things working together.

Okay, I'd like to make up a "To do for V0.5" list. So far I have:
Rewrite networking code.
Make Nano-X work with the latest Bogl.
Tidy up code in general.
Make whatever API changes are needed to support GDK.
Implement a basic WM API.
Document the APIs.
Make demo disk.

I'd like to hear suggestions as to what else people think should be done
before the 0.5 release.

I'll discuss the WM and GDK API stuff in seperate mails on the subject
(note that I'm not suggesting writing a WM or porting GDK, just getting
the necessary changes over with now, so that someone can do it before
Nano-X-0.6).

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

On Tuesday, May 18, 1999 9:36 AM, Alex Holden ####@####.#### wrote:
> I was just wondering what is happening with the Bogl code in Nano-X?
> How far are we away from being able to use an unmodified Bogl library?

There are considerable changes that need to be made to use unmodified bogl libraries.
The first major issue is that all the bogl entry points need to have code added
to support drawing in AND, OR and XOR modes, in addition to SET, which is
already implemented.

Secondly, bogl code currently resets the keyboard, etc when asked to open the
screen.  This code should be removed, or called separately by the upper level.
NanoX currently has separately controlled keyboard drivers.

Thirdly, a ReadPixel() entry point needs to be added to all bogl drivers.

Fourthly, with my nano-X v0.5 modifications (detailed following) I have re-designed
cursor management and no longer use the low-level pointer draw routines in bogl.
This was to give some common upper-level code that knows about a nanoX cursor
format so that we could support the GR_BITMAP format for cursors.  In addition, 
nanoX now supports color cursors, which bogl doesn't.  The new mid-level cursor
routines depend on scrdev.DrawPixel and scrdev.ReadPixel to support any cursor
included with the mini-x demos.

So, the scr_bogl.c routine and the included server/drivers/bogl directory contain
the modifed bogl library code that's necessary to support the advanced draw code
requests in the current demos.  Ben is very interested in contributing, but
I have been discussing a more advanced monochrome/color bitmap format
that would allow pictures etc to be displayed with nanoX using 8/16/24/32 bit color
formats.

So, basically, unless alot more people start coding, we're using the single driver
that I've made work for the demo functionality.  I also have serious architectual
concerns about using non-nanoX drivers, for speed and future bitblt issues...

BTW, in the nano-X v0.5 release that I've prepared, I've included a hardware VGA
driver for 640x480x16 color mode that supports the damned VGA hardware 4-plane
mode.  Currently, this driver is limited to running under DOS or NT DOS emulation.

Some research that needs to be done is how the Linux framebuffer device supports
more than just MODE_SET draw modes, while being just a memory-mapped device.
The VGA hardware supports XOR/AND/OR drawing by setting bits in a control register.
Is this the way that the framebuffer device is supposed to be used also?



> The reason I ask is that I would like to make a NanoGUI demo disk which
> uses the VGA16 driver; I have the boot disk setup with a VGA16 frame
> buffer okay, but the VGA16 driver in Nano-X doesn't work any more...
> Is there anything I can do to help things along myself?

	This shouldn't be too hard, the server/drivers/bogl directory contains
an earlier VGA16 driver.  Just define BOGL_VGA16_FB=1 in the included
makefile, and type make clean; make from the server directory.  That driver
needs all the other mods made in the bogl-cfb8.c file.


> 
> BTW, since Greg has volunteered to clean up all the loose ends I mentioned
> in an earlier mail, I'm working on rewriting the networking code according
> to David's suggestions.

	I've made the changes so that, for instance, Dave's mini-x world
program compiles and runs with a few lines of code changes.


> 
> On the subject of changes, I think we should have several pre-5 releases
> before we release an official new version this time, and make sure
> everything works properly before we release it. Since I've been having
> some problems getting the CVS server to behave, and Greg doesn't want to
> use it anyway, I'll have to juggle the patches myself and put up new
> pre-releases whenever I get a few new things working together.

	I have completed work on an interim v0.5, that, should you want it,
contains the following changes:

 	* Rewrote cursor routines
	* Separated mouse from cursor routines
	* Removed DrawCursor from device driver
	* Added ReadPixel to device driver
	* Made demo programs work with cursor changes
	* Added support for color cursors
	* Added polygon draw and fill routines
	* Added area pixel reading/writing, removed 8-bit limit for colors
	* Reworked color model
	* Added direct hardware 640x480x16 support for VGA real mode systems
	* Made api backwards compatible with mini-x
	* Ported mini-x world demo program to examples library


	I recommend that we post this stuff, since it contains
considerable changes to the driver level, and then you work on a v0.6.
Maybe I'll work on some other things for a while.


Greg

> 
> Okay, I'd like to make up a "To do for V0.5" list. So far I have:
> Rewrite networking code.
> Make Nano-X work with the latest Bogl.
> Tidy up code in general.
> Make whatever API changes are needed to support GDK.
> Implement a basic WM API.
> Document the APIs.
> Make demo disk.
> 
> I'd like to hear suggestions as to what else people think should be done
> before the 0.5 release.
> 
> I'll discuss the WM and GDK API stuff in seperate mails on the subject
> (note that I'm not suggesting writing a WM or porting GDK, just getting
> the necessary changes over with now, so that someone can do it before
> Nano-X-0.6).
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

On Tue, 18 May 1999, Greg Haerr wrote:
> There are considerable changes that need to be made to use unmodified
> bogl libraries. The first major issue is that all the bogl entry points
> need to have code added to support drawing in AND, OR and XOR modes, in
> addition to SET, which is already implemented.

I'll take a look at it 

> Secondly, bogl code currently resets the keyboard, etc when asked to open the
> screen.  This code should be removed, or called separately by the upper level.
> NanoX currently has separately controlled keyboard drivers.

It'd probably be a better idea for us to use the Bogl keyboard driver when
Bogl is available, and maybe the mouse driver too.

> Fourthly, with my nano-X v0.5 modifications (detailed following) I have
> re-designed cursor management and no longer use the low-level pointer
> draw routines in bogl. This was to give some common upper-level code
> that knows about a nanoX cursor format so that we could support the
> GR_BITMAP format for cursors.  In addition,  nanoX now supports color
> cursors, which bogl doesn't.  The new mid-level cursor routines depend

Is there any point having colour cursors? I don't think I have ever seen X
or 'doze produce a colour mouse pointer.

> Some research that needs to be done is how the Linux framebuffer device supports
> more than just MODE_SET draw modes, while being just a memory-mapped device.
> The VGA hardware supports XOR/AND/OR drawing by setting bits in a control register.
> Is this the way that the framebuffer device is supposed to be used also?

The XFREE86 FB driver might be a useful reference; I have a copy
somewhere.

> 	This shouldn't be too hard, the server/drivers/bogl directory contains
> an earlier VGA16 driver.  Just define BOGL_VGA16_FB=1 in the included
> makefile, and type make clean; make from the server directory.  That driver

I suppose you haven't tried then, I got a screenfull of errors when I
tried :). Seriously, I haven't looked at how much needs changing yet.

> > On the subject of changes, I think we should have several pre-5 releases
> 	I have completed work on an interim v0.5, that, should you want it,

I'll be releasing that in about half an hour as 0.5pre1

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

On Tue, 18 May 1999, Alex Holden wrote:

> On Tue, 18 May 1999, Greg Haerr wrote:
> > Fourthly, with my nano-X v0.5 modifications (detailed following) I have
> > re-designed cursor management and no longer use the low-level pointer
> > draw routines in bogl. This was to give some common upper-level code
> > that knows about a nanoX cursor format so that we could support the
> > GR_BITMAP format for cursors.  In addition,  nanoX now supports color
> > cursors, which bogl doesn't.  The new mid-level cursor routines depend
> 
> Is there any point having colour cursors? I don't think I have ever seen X
> or 'doze produce a colour mouse pointer.

At least in the case of X, that is because X uses X bitmaps for pointers,
and X bitmaps are mono only, so X doesn't _support_ colour mouse 
pointers... Don't know about Windows though - I only rarely touch Windows
machines :)

Regards,
Vidar

On Tue, 18 May 1999, Greg Haerr wrote:
> There are considerable changes that need to be made to use unmodified bogl libraries.
> The first major issue is that all the bogl entry points need to have code added
> to support drawing in AND, OR and XOR modes, in addition to SET, which is
> already implemented.

After thinking about this, and looking at the code, isn't the best way to
do this for the graphics screen to be mirrored in main memory, and do the
processing on that then copy only the altered areas out to the buffer on
the graphics card? That way, you aren't shipping large amounts of data
over a PCI or ISA bus... I seem to recall Allegro had about five different
ways of dealing with this problem though, so there probably isn't one
answer which is best for all situations. It doesn't seem that reading from
the frame buffer, performing an operation on it, and writing it back out
again is going to be a very good idea, and I couldn't see any obvious way
to use the hardware capabilities of the graphics card to do it with the
Linux Framebuffer interface (maybe you can do it with the accelerated ones
though).

BTW, I've just switched the newest bogl library in place of the old one.
Very few changes at all were needed, though I didn't copy the readpixel()
stuff (as I said above, I don't think reading it from the framebuffer
itself is the best way to do it anyway) so you can "rub out" the screen by
waving the mouse over it. The Map program looks good in VGA16 mode, but on
the NetWinder it's just a mess of random lines (structure alignment
problems, no doubt).

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

> > Is there any point having colour cursors? I don't think I have ever seen X
> > or 'doze produce a colour mouse pointer.
> 
> At least in the case of X, that is because X uses X bitmaps for pointers,
> and X bitmaps are mono only, so X doesn't _support_ colour mouse 
> pointers... Don't know about Windows though - I only rarely touch Windows
> machines :)
>

	There isn't much point, other than user fascination with bells and whistles.
Monocrhome bitmaps (the same as those used by nano-X) can be drawn with
different foreground and bg colors.  This is the new algorithm that is used for all bitmap
draws, including cursors in v0.5, thus color cursors for free.  The bogl driver assumed
a fixed palette, which won't work if we ever want to display pictures, and ignored
the currently set fg and bg colors.  In addition,  a very similar routine needed to
be written for regular bitmap drawing....

BTW, Windows supports not only full color cursors, but also animated ones as well.

It's little gizmos like this that can add considerable customer zeal to a product.  On
small LCD machines, for instance, the mouse cursor can be told to "slide" along the
screen leaving a faint memory.  This allows users to spot the mouse quicker when
there's only two colors.

Greg

On Tue, 18 May 1999, Greg Haerr wrote:
> It's little gizmos like this that can add considerable customer zeal to a product.  On
> small LCD machines, for instance, the mouse cursor can be told to "slide" along the
> screen leaving a faint memory.  This allows users to spot the mouse quicker when
> there's only two colors.

"Ee, when I was a lad..." I remember with 'doze 3.1 on my PC it would lock
the machine solid if you enabled that option. I later used a friend's
laptop which had it on, and it drove me insane after two minutes.

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

On Tuesday, May 18, 1999 4:56 PM, Alex Holden ####@####.#### wrote:
> On Tue, 18 May 1999, Greg Haerr wrote:
> > There are considerable changes that need to be made to use unmodified bogl libraries.
> > The first major issue is that all the bogl entry points need to have code added
> > to support drawing in AND, OR and XOR modes, in addition to SET, which is
> > already implemented.
> 
> After thinking about this, and looking at the code, isn't the best way to
> do this for the graphics screen to be mirrored in main memory, and do the
> processing on that then copy only the altered areas out to the buffer on
> the graphics card? That way, you aren't shipping large amounts of data
> over a PCI or ISA bus... I seem to recall Allegro had about five different
> ways of dealing with this problem though, so there probably isn't one
> answer which is best for all situations. It doesn't seem that reading from
> the frame buffer, performing an operation on it, and writing it back out
> again is going to be a very good idea, and I couldn't see any obvious way
> to use the hardware capabilities of the graphics card to do it with the
> Linux Framebuffer interface (maybe you can do it with the accelerated ones
> though).

	That is precisely my point about the VGA hw registers that do this
operation for you.  In the mean time, XOR draw mode is a must for all the demos...

No, it is far too slow to draw everything twice, once in main, then in graphics ram.  In
addition, you'd never know what's been modified.  However, the bitblt operations you
speak of are solved with a rearchitecture of the driver model I spoke of in an earlier
mail msg.  This involved allowing all graphics operations to be performed on a "bitmap",
where the bitmap is either offscreen memory or the graphics memory.  Thus,
the low-level draw primitives take a buffer address into account for all their operations,
and record how many bits per planes, etc.  This is how Allegro does it.  This is
how nanoX should do it.


> 
> BTW, I've just switched the newest bogl library in place of the old one.
> Very few changes at all were needed, though I didn't copy the readpixel()
> stuff (as I said above, I don't think reading it from the framebuffer
> itself is the best way to do it anyway) so you can "rub out" the screen by
> waving the mouse over it. The Map program looks good in VGA16 mode, but on
> the NetWinder it's just a mess of random lines (structure alignment
> problems, no doubt).

	Please copy the readpixel routine into your new driver.  Readpixel is required
for demo.c program to run, as well as the ReadArea api, as well as the cursor drawing.

Greg


> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

> > Secondly, bogl code currently resets the keyboard, etc when asked to open the
> > screen.  This code should be removed, or called separately by the upper level.
> > NanoX currently has separately controlled keyboard drivers.
> 
> It'd probably be a better idea for us to use the Bogl keyboard driver when
> Bogl is available, and maybe the mouse driver too.

	I'd rather see separate capabilities for mouse and kbd, then people
can add/modify them if desired.
> 
> The XFREE86 FB driver might be a useful reference; I have a copy
> somewhere.


	I'd love to see the Xfree86 FB driver.

Greg

On Tue, 18 May 1999, Greg Haerr wrote:
> No, it is far too slow to draw everything twice, once in main, then in graphics ram.  In

I don't know if there is a way to specify the write mode with the
framebuffer drivers, but if there isn't then the best way is to use a
buffer.

> addition, you'd never know what's been modified.  However, the bitblt operations you

That depends on how you implement it.

> speak of are solved with a rearchitecture of the driver model I spoke of in an earlier
> mail msg.  This involved allowing all graphics operations to be performed on a "bitmap",

That's a seperate issue to the drawing modes. 

> 	Please copy the readpixel routine into your new driver.  Readpixel is required
> for demo.c program to run, as well as the ReadArea api, as well as the cursor drawing.

I never suggested not having a readpixel() routine.

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