nanogui: Thread: NanoX version 0.3 released

Fellow NanoX interested parties:

I have today finished work on nanoX version 0.3, which includes the following features:

	o completely seperate driver api and drivers for screen, mouse and keyboard.
All drivers are in a drivers/ subdirectory.  It's really easy to write a driver set for some
strange box, providing you know how the strange box's low-level graphics code should
work.

	o low level screen driver doesn't need to know anything about clipping, and
can run with as little as DrawPixel implemented.  All common code, such
as Bresenham line draws and circles, ellipses, etc and clipping is in the common
mid level nanoX code.

	o Linux drivers include support for BOGL screen libraries, GPM mouse
and /dev/tty keyboard support. (we still can't use unmodified BOGL libraries, I'm working
with Ben on this)

	o MSDOS driver support.  I wrote a 640x480x16 color driver in about 45 minutes.
NanoX now runs on DOS!  (OK, I did this only to see how portable nanoX is, and the 
mouse driver still isn't written)  This still uses MSC graphics library.  I'll have the bios
int10 version driver done shortly, which will allow nanoX to run on ELKS!  We should
have an ELKS version shortly...   BTW, the nanoX kernel is around 20k on DOS...

	o Full cursor clipping is now working, which makes cursor
movement over graphical output work well.  (This version still doesn't quite
draw rectangles properly, more on coordinate systems in another email...)

	o Many bug fixes

Greg

Whow ....

This sounds like amazing work, dude.

Can't wait to try it out ...

... after my diploma thesis :-(

- alex

On Mon, 10 May 1999, Greg Haerr wrote:

> Fellow NanoX interested parties:
> 
> I have today finished work on nanoX version 0.3, which includes the following features:
> 
> 	o completely seperate driver api and drivers for screen, mouse and keyboard.
> All drivers are in a drivers/ subdirectory.  It's really easy to write a driver set for some
> strange box, providing you know how the strange box's low-level graphics code should
> work.
> 
> 	o low level screen driver doesn't need to know anything about clipping, and
> can run with as little as DrawPixel implemented.  All common code, such
> as Bresenham line draws and circles, ellipses, etc and clipping is in the common
> mid level nanoX code.
> 
> 	o Linux drivers include support for BOGL screen libraries, GPM mouse
> and /dev/tty keyboard support. (we still can't use unmodified BOGL libraries, I'm working
> with Ben on this)
> 
> 	o MSDOS driver support.  I wrote a 640x480x16 color driver in about 45 minutes.
> NanoX now runs on DOS!  (OK, I did this only to see how portable nanoX is, and the 
> mouse driver still isn't written)  This still uses MSC graphics library.  I'll have the bios
> int10 version driver done shortly, which will allow nanoX to run on ELKS!  We should
> have an ELKS version shortly...   BTW, the nanoX kernel is around 20k on DOS...
> 
> 	o Full cursor clipping is now working, which makes cursor
> movement over graphical output work well.  (This version still doesn't quite
> draw rectangles properly, more on coordinate systems in another email...)
> 
> 	o Many bug fixes
> 
> Greg
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Mon, 10 May 1999, Greg Haerr wrote:

> Fellow NanoX interested parties:
> 
> I have today finished work on nanoX version 0.3, which includes the following features:
> 
> 	o completely seperate driver api and drivers for screen, mouse and keyboard.
> All drivers are in a drivers/ subdirectory.  It's really easy to write a driver set for some
> strange box, providing you know how the strange box's low-level graphics code should
> work.

Wow..

I looked at nano-X a few days ago, and almost dismissed it due to the
problems I had getting the framebuffer device up and running on my
machine (I've got a S3 Trio card... One of those that _doesn't_ work with
vesafb, arg.), and the mess in the graphics driver code at that time.

Guess this means will almost certainly use nano-X for our Linux based
set-top box/ webpad type machine.

I've got a long list of features I'd like, and if nano-X keeps improving
at this rate we'll be putting at least one full time developer on helping
out with further development.

And one of the requirements we have, is that we need to port Mozilla to
whatever graphics library we use - we plan to allocate people to that
too... :)

Keep up the good work!

Regards,

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

COOL!!! Where can I find the source?  I checked LHO but it only has
0.2 for dl...

Thanks
Louis

On Mon, 10 May 1999, Greg Haerr wrote:

> Fellow NanoX interested parties:
> 
> I have today finished work on nanoX version 0.3, which includes the following features:
> 
> 	o completely seperate driver api and drivers for screen, mouse and keyboard.
> All drivers are in a drivers/ subdirectory.  It's really easy to write a driver set for some
> strange box, providing you know how the strange box's low-level graphics code should
> work.
> 
> 	o low level screen driver doesn't need to know anything about clipping, and
> can run with as little as DrawPixel implemented.  All common code, such
> as Bresenham line draws and circles, ellipses, etc and clipping is in the common
> mid level nanoX code.
> 
> 	o Linux drivers include support for BOGL screen libraries, GPM mouse
> and /dev/tty keyboard support. (we still can't use unmodified BOGL libraries, I'm working
> with Ben on this)
> 
> 	o MSDOS driver support.  I wrote a 640x480x16 color driver in about 45 minutes.
> NanoX now runs on DOS!  (OK, I did this only to see how portable nanoX is, and the 
> mouse driver still isn't written)  This still uses MSC graphics library.  I'll have the bios
> int10 version driver done shortly, which will allow nanoX to run on ELKS!  We should
> have an ELKS version shortly...   BTW, the nanoX kernel is around 20k on DOS...
> 
> 	o Full cursor clipping is now working, which makes cursor
> movement over graphical output work well.  (This version still doesn't quite
> draw rectangles properly, more on coordinate systems in another email...)
> 
> 	o Many bug fixes
> 
> Greg
> 
> 
> 

The nanoX site is:

http://www.linuxhacker.org/pub/nanogui/nano-X/

It should be up there in a little bit.

Greg

I used MSC v5.10 for DOS, but most anything would do.  There's currently
no assembly language, but that may change...

I'd like to see both an int 0x33 driver as well as one that works with mouse.com.

Greg

On Monday, May 10, 1999 12:29 PM, Louis P. Santillan ####@####.#### wrote:
> Thanks.  I think I can wait.  Keep up the good work.  I can write a
> driver for the mouse in DOS if you'd like (to grab the coordinates
> and stuff but not to do the draw/undraw stuff) or I could write one
> that use the standard INT 0x33 calls.  BTW, what compiler are you
> using for DOS?  Once I see the API, I should be able to write it
> fairly quickly.
> 
> Louis
> 
> On Mon, 10 May 1999, Greg Haerr wrote:
> 
> > It should be on http://www.linuxhacker.org/pub/nanogui/nano-X/ shortly.  
> > 
> > If you can't wait, ask and I'll mail it to you (200k)
> > 
> > Greg
> > 
> > 
> > 
> > On Monday, May 10, 1999 12:02 PM, Louis P. Santillan ####@####.#### wrote:
> > > COOL!!! Where can I find the source?  I checked LHO but it only has
> > > 0.2 for dl...
> > > 
> > > Thanks
> > > Louis
> > > 
> > > On Mon, 10 May 1999, Greg Haerr wrote:
> > > 
> > > > Fellow NanoX interested parties:
> > > > 
> > > > I have today finished work on nanoX version 0.3, which includes the following features:
> > > > 
> > > > 	o completely seperate driver api and drivers for screen, mouse and keyboard.
> > > > All drivers are in a drivers/ subdirectory.  It's really easy to write a driver set for some
> > > > strange box, providing you know how the strange box's low-level graphics code should
> > > > work.
> > > > 
> > > > 	o low level screen driver doesn't need to know anything about clipping, and
> > > > can run with as little as DrawPixel implemented.  All common code, such
> > > > as Bresenham line draws and circles, ellipses, etc and clipping is in the common
> > > > mid level nanoX code.
> > > > 
> > > > 	o Linux drivers include support for BOGL screen libraries, GPM mouse
> > > > and /dev/tty keyboard support. (we still can't use unmodified BOGL libraries, I'm working
> > > > with Ben on this)
> > > > 
> > > > 	o MSDOS driver support.  I wrote a 640x480x16 color driver in about 45 minutes.
> > > > NanoX now runs on DOS!  (OK, I did this only to see how portable nanoX is, and the 
> > > > mouse driver still isn't written)  This still uses MSC graphics library.  I'll have the bios
> > > > int10 version driver done shortly, which will allow nanoX to run on ELKS!  We should
> > > > have an ELKS version shortly...   BTW, the nanoX kernel is around 20k on DOS...
> > > > 
> > > > 	o Full cursor clipping is now working, which makes cursor
> > > > movement over graphical output work well.  (This version still doesn't quite
> > > > draw rectangles properly, more on coordinate systems in another email...)
> > > > 
> > > > 	o Many bug fixes
> > > > 
> > > > Greg
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: ####@####.####
> > > For additional commands, e-mail: ####@####.####
> > > 
> > 
> 

On Mon, 10 May 1999, Vidar Hokstad wrote:
> problems I had getting the framebuffer device up and running on my
> machine (I've got a S3 Trio card... One of those that _doesn't_ work with

I have the same problem on my PC (Diamond Stealth); I use my NetWinder
instead.

> Guess this means will almost certainly use nano-X for our Linux based
> set-top box/ webpad type machine.

Sounds cool.

> I've got a long list of features I'd like, and if nano-X keeps improving
> at this rate we'll be putting at least one full time developer on helping
> out with further development.

Great!

> And one of the requirements we have, is that we need to port Mozilla to
> whatever graphics library we use - we plan to allocate people to that
> too... :)

I'm not so convinced about Mozilla, personally. It seems such an ugly
mess. If only the QNX browser was Open Source... For a set top box though,
I suppose you would want a browser with all the latest features (CSS,
etc.). Using NanoGUI as well has the advantage that it should be much
easier to adapt to anything you want than X, due to it's simplicity, plus
the lower amount of flash it uses should save you quite a bit of money per
box ;)

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

On Mon, 10 May 1999, Alex Holden wrote:

> On Mon, 10 May 1999, Vidar Hokstad wrote:
> > problems I had getting the framebuffer device up and running on my
> > machine (I've got a S3 Trio card... One of those that _doesn't_ work with
> 
> I have the same problem on my PC (Diamond Stealth); I use my NetWinder
> instead.

Hmm :) I have a Netwinder sitting here, didn't think about checking out
nano-X on it. Guess I just have to do it :)
 
> I'm not so convinced about Mozilla, personally. It seems such an ugly
> mess. If only the QNX browser was Open Source... For a set top box though,
> I suppose you would want a browser with all the latest features (CSS,
> etc.). 

Mozilla is actually getting there. M5 is actually more stable for me than
Navigator 4.51 is, in most cases now. Or at least Gecko, the layout
engine is. We'll probably ignore XUL and lots of other of the "high end"
features. But getting gecko up and running in 1-2MB of flash should
certainly be possible.

The good thing about Mozilla, is that there is widget rendering code for
the HTML form widgets included that use the same graphics and event
abstraction layer that the rest of the layout engine uses, so there's a
fairly small set of primitive drawing functions that must be modified to
work with NanoX, and the GDK implementation should be a good starting
point - the API isn't _that_ different.

>Using NanoGUI as well has the advantage that it should be much
> easier to adapt to anything you want than X, due to it's simplicity, plus
> the lower amount of flash it uses should save you quite a bit of money per
> box ;)

I know :) X was rejected _very_ early. We actually did a prototype based
on GGI, but then we'd still have to handle most of what nano-X do
ourselves, and libggi isn't that small either.

Some of the code for the prototype could be useful for nano-X, though -
I'll take a look at it. For instance, I wrote some font handling code that
use font files that are a lot smaller than nano-X's (at least as of 0.2,
haven't had the time to check out 0.3 yet).

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

On Mon, 10 May 1999, Vidar Hokstad wrote:
> Hmm :) I have a Netwinder sitting here, didn't think about checking out
> nano-X on it. Guess I just have to do it :)

Make sure you run a 2.2 kernel on it (the 2.0 framebuffer Corel did was
incompatible with the general 2.2 design), and make sure it is in 8bpp
mode. Other than that, it should work just fine.

> Mozilla is actually getting there. M5 is actually more stable for me than
> Navigator 4.51 is, in most cases now. Or at least Gecko, the layout
> engine is. We'll probably ignore XUL and lots of other of the "high end"
> features. But getting gecko up and running in 1-2MB of flash should
> certainly be possible.

It'll be very nice if you manage that... They must have slimmed things
down a lot since last time I looked (tens of megabytes of libraries that
took a couple of minutes just to load into memory).

> The good thing about Mozilla, is that there is widget rendering code for
> the HTML form widgets included that use the same graphics and event
> abstraction layer that the rest of the layout engine uses, so there's a
> fairly small set of primitive drawing functions that must be modified to
> work with NanoX, and the GDK implementation should be a good starting
> point - the API isn't _that_ different.

We should be writing a GDK port for Nano-X eventually anyway. You may want
to help with that rather than grafting Mozilla directly onto Nano-X 
itself.

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

My comments follow

On Monday, May 10, 1999 3:28 PM, Alex Holden ####@####.#### wrote:
> On Mon, 10 May 1999, Vidar Hokstad wrote:
> > Hmm :) I have a Netwinder sitting here, didn't think about checking out
> > nano-X on it. Guess I just have to do it :)
> 
> Make sure you run a 2.2 kernel on it (the 2.0 framebuffer Corel did was
> incompatible with the general 2.2 design), and make sure it is in 8bpp
> mode. Other than that, it should work just fine.

As soon as Ben finishes the bogl library integration, we'll also support
24 and 32bpp modes...


> 
> > Mozilla is actually getting there. M5 is actually more stable for me than
> > Navigator 4.51 is, in most cases now. Or at least Gecko, the layout
> > engine is. We'll probably ignore XUL and lots of other of the "high end"
> > features. But getting gecko up and running in 1-2MB of flash should
> > certainly be possible.
> 
> It'll be very nice if you manage that... They must have slimmed things
> down a lot since last time I looked (tens of megabytes of libraries that
> took a couple of minutes just to load into memory).
> 
> > The good thing about Mozilla, is that there is widget rendering code for
> > the HTML form widgets included that use the same graphics and event
> > abstraction layer that the rest of the layout engine uses, so there's a
> > fairly small set of primitive drawing functions that must be modified to
> > work with NanoX, and the GDK implementation should be a good starting
> > point - the API isn't _that_ different.

	I know I'm being obtuse, but, what is GDK?



> 
> We should be writing a GDK port for Nano-X eventually anyway. You may want
> to help with that rather than grafting Mozilla directly onto Nano-X 
> itself.

	Nano-X is still very very primitive, and I haven't made it match the Xlib
standard yet.  We've got all sorts of driver work before we can get pretty applications
running on top of it, like supporting XOR drawing modes, text output without
background fill, etc.

I would be very interested in seeing now what the Mozilla requirement is for low-level
functionality. Do you have anything in writing?




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