Subject:
RE: nanoGui development
From:
Greg Haerr ####@####.####
Date:
4 May 1999 17:29:06 -0000
Message-Id: <01BE9621.74B15B20.greg@censoft.com>
Alistair -
I've got the nanoGui project moved up quite a bit. It now runs the sample
programs pretty well. As Alan mentioned, I'll be checking all this stuff in shortly.
I've also made a makefile option that allows the graphics application to be linked
directly with the nanoX server. This means that you won't have to implement any sockets
in the ELKS kernel for initial testing. Following are the things that someone will have
to worry about (I'm planning on getting to these, but I still can't develop on ELKS,
and cross-development is a pain... BTW I have the bcc tools source hacked to
self-host now, for instance it will compile the ANSI C Minix libc source on Minix...)
Anyway, the following needs to be addressed for nanoGui on ELKS:
o A real mode VGA driver (we can use int 10h for this, pretty easy, then
hack bogl for 16-bit ints) BTW this driver also needs to switch between text
and graphics modes, rather than using consoles. I recommend that all the graphics/text
stuff remain in nanoGui for ELKS for the time being, we don't need a bigger kernel for this.
Taking this approach means that ELKS can leave out all graphics stuff from the kernel
for the time being.
o A mouse driver (this is more of a pain, we could still leave it out of the kernel)
o Kernel select() support for mouse and keyboard fd's (note that we require
tty ~ICANON raw mode. (^C signal handling would be nice to abort the server on bad errors)
o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone
wants my ansi modifications, I'm thinking of releasing it myself.
Currently, NanoGui implements a decent subset of low-level X primitives, although
they're renamed. Window creation, GC manipulation and text routines work. We still
need some better low-level drawcode support. For instance, XOR drawing isn't done yet.
My plan is to take nanoGui and abstract the mouse, keyboard and screen
interfaces into fully defined interfaces within structures, that would allow nanoGui to become
completely portable with anyone able to roll their own drivers. I should have this work done
in a couple of days. I've got to hook up my linux box to the net to use the CVS checkin,
hopefully that'l get done tonight or tomorrow.
Greg
On Tuesday, May 04, 1999 4:13 AM, Alistair Riddoch ####@####.#### wrote:
> Greg Haerr writes:
> >
> > I got into this because I've been watching the ELKS development work,
> > and they were wondering whether this work could used for their project. The answer
> > is absolutely yes, although some direct real-mode linked in frame-buffer support would
> > be necessary. To get ready for that, and the associated possible 16-bit compiles, this
> > project should use typedefs for the internal types, like colors, and x,y,w,h stuff. I would
> > like to typedef all that stuff. All-in-all, this would allow for nanoGui to become quite
> > portable.
> >
>
> I have been lurking on this list for the very same reason, and as soon as
> I can get nano-gui to work I will have a look at getting it to work under
> ELKS in ernest. It will probably initially only work on UNIX sockets as we
> are a long way from having a TCP/IP stack, and UNIX sockets are going to be
> much simpler to implement. I also suspect that getting hold of a flat
> framebuffer in 8086 real mode is a bit unlikely so more porting work is
> going to be required there. Unfortunatly getting things to work on ELKS
> often involved feature stripping them, which often does not add to
> portability.
>
> If you could make the code you have available I would be very interested in
> looking at it and testing it out, finding bugs etc.
>
> Al
> --
> Alistair Riddoch
> ELKS kernel developer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
