nanogui: Thread: Nano-X-0.5pre3

On Fri, 21 May 1999, Greg Haerr wrote:
> 	Vidar sent me his working ggi drivers for nanoX v0.4.  Do you have them?
> I don't have GGI installed but it seems like a very cool system.

He got the ggi graphics drivers working? I'd love to have that code...

> 	I like your GPM driver alot.  I was thinking of writing a lower-level
> mouse driver just for systems that don't have GPM, and run on bare hardware...

The problem is that it needs GPM as a seperate process, which isn't ideal
in a lot of cases.

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

On Fri, 21 May 1999, Greg Haerr wrote:
> 	I agree that it'd be a good move to use the generalized variable
> packed pixel drivers instead of the one I've been using.  That means
> we'd support 8, 16, 24 and 32 bpp in one driver.

Yes, that's what I'm doing. The cfb8 driver in pre3 is the original bogl
one.

> 	Only to keep the distribution completely working for those of
> us that want to add more features, while the driver-development can
> continue as well.  Once everything works in a more generalized driver,
> we can toss the earlier driver from the distribution.  This is in line with
> my request to have some stability in the features working.

I'm intending to work on a pre release system, where the full releases are
as stable as possible, and anything that gets broken does so in a pre
release, and gets fixed again before the next full release. So, if you
want stability stay with the full versions, and if you want to be on the
cutting edge work with the pre versions (at your own risk).

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

On 21 May 1999, Ben Pfaff wrote:
> I'm planning to *make* the nanogui version the standard version, and
> figure out a way to leave out features that individual projects don't
> need.

Great!

> I've been missing-in-action when it comes to coding lately; hopefully
> I'll be able to get some work done today or tomorrow.  I've got a huge
> project due by the end of next month that people are paying me to do,
> though.

That's okay. I suspect most of us have plenty of other pressures to
worry about ;)

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

On Friday, May 21, 1999 2:49 PM, Alex Holden ####@####.#### wrote:
: On 21 May 1999, Ben Pfaff wrote:
: > I'm planning to *make* the nanogui version the standard version, and
: > figure out a way to leave out features that individual projects don't
: > need.
: 
: Great!
: 

	Yeah, that's really good news.  One idea, once Alex and I get our
driver stuff straight, would be to take that stuff as the bogl graphics draw routines,
and then add back, in a separate file, your code for the text output and pointer drawing,
and bitmap putting, which aren't used by nano-X currently.  In this way, your
"customers" get what they've always had, and nano-X isn't any bigger.  If we ever
want to change nano-X to use low-level text, pointer, or bitmap routines, we can
always grab it.

	The one other big change is that the clipping code isn't done at the lower
level, since the clipping code needs to be shared with upper level routines like
GrSetClipRect, etc.  Because of this, if your "customers" need low-level clipping,
all that will have to be #defined in or out at compile time.

Greg

On Fri, 21 May 1999, Greg Haerr wrote:
> draw routines, and then add back, in a separate file, your code for the
> text output and pointer drawing, and bitmap putting, which aren't used

It doesn't have to go into a seperate file, #ifdef 's work fine.

> by nano-X currently.  In this way, your "customers" get what they've
> always had, and nano-X isn't any bigger.  If we ever want to change

And they can have the new stuff which we are planning to add if they want
it. The main thing I think we should work towards is a common bitmap
structure format between nano-X and bogl, which is used as the arguments
to bogl's blit functions. I think the blit should be implemented at the
bogl level, and it would be easier if bogl understood the nano-X graphics
format directly...

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

: And they can have the new stuff which we are planning to add if they want
: it. The main thing I think we should work towards is a common bitmap
: structure format between nano-X and bogl, which is used as the arguments
: to bogl's blit functions. I think the blit should be implemented at the
: bogl level, and it would be easier if bogl understood the nano-X graphics
: format directly...

	Blit is not required yet. It only adds value if we extend the upper level
api to draw into offscreen (memory) bitmaps, something that mini-x and nano-x
currently don't support.

	In the meantime, there is already a bitmap structure that nano-X (mini-x)
depends on, which is an array of GR_BITMAPs.  All of the sample programs
require this format for both the cursor bitmap and other images.  In my last
major release, 0.5, I implemented all this for the cursor, and didn't require a new
driver entry point. Remember, we're only talking about monocrhome bitmaps here,
not color pixmaps.

	In my major release today, I've continued to use the GR_BITMAP
structure to implement nano-X's native font format, so that a font can be
displayed using the same routines that display the cursor, etc.

	Another one of the reasons that it's not in our interest to implement
bitblt at the driver level yet is that all the drawing modes also need to be implemented,
SET, AND, OR, XOR at the blt level.  This is a huge job.  I think that it would
be better to agree on a color bitmap structure first.  In any case, until a high-level
api is created that allows offscreen drawing, all this does is make nano-X bigger,
with no user benefit but a slight speed increase.

Greg