nanogui: Re: nanoGui development
Subject:
Re: nanoGui development
From:
Alistair Riddoch ####@####.####
Date:
5 May 1999 15:33:21 -0000
Message-Id: <199905051532.QAA20408@penelope.ecs.soton.ac.uk>
Greg Haerr writes:
>
> 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 look forward to looking at the code.
> 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.
I have had some thoughts on the best way to support graphics. I think it
would be cleanest to implement an ioctl in the dircon driver telling that
an application requires graphics so it has to save the contents of the VCs,
and disable VC switching, and writes to VCs. This then leaves a user space
vga library to do what it wants with the hardware until it has finished,
whereupon it call the driver again letting it know that the VCs should now
be restores. Putting the display hardware back into the right mode should
be the responsability of the library code.
>
> o A mouse driver (this is more of a pain, we could still leave it out of the kernel)
Could we restrict support to serial mice initially? The serial driver works
so far.
>
> 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)
We cave non-canonical mode (try running vi), but some other term features
are still not possible. I have thought about ctrl-C (and ctrl-Z) but have
not yet come up with a way of implementing them.
>
> o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone
> wants my ansi modifications, I'm thinking of releasing it myself.
Most ANSI code will compile under bcc if you use the -ansi flag. How much
do your ansi modifications do? DO they check prototypes, or just allow ANSI
code to be compiled?
>
>
> 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.
>
My previous experiences with ELKS have shown that portable code does not
always make it very ELKS friendly. I have often had to take code which is
easily portable, and make it very unportable to make it small enough to run
under ELKS. In an ideal world we could run nano-GUI from the standard code
base under ELKS, but it may end up being the case that a heavily modified
version of nana-gui gives much better performance under ELKS.
Al
