nanogui: Thread: Re: nanoGui development

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

Following getting the nanogui project working, I propose and am working on the
following developments:

	o complete separation of screen driver interface from the nanogui server proper.
	o integration with separately produced bogl and other graphics libraries
	o operation standalone and on non-linux systems

This is complicated, but here's the idea.  Currently the nanogui project uses a custom
modifed version of the bogl graphics libraries developed initially  by Ben Pfaffer over at
debian.  These libraries only work with 8 bit color framebuffers, and require v2.2 linux.
In addition nanogui clipping support is contained in the graphics libraries.  Since nanogui
v0.1, Ben and others have come out with quite a few more versions of bogl, ones that support
truecolor, pseudocolor, etc.  These libraries work on linux systems setup  for truecolor
display consoles.  The console and framebuffer now have to be reset to 8 bit mode for nanogui
to run.

I propose that nanogui be rewritten to allow unmodified bogl libraries from debian to be
linked in w/o modification.  This will allow nanogui to run on many more systems, as 
well as someone volunteering a svgalib driver that will allow nanogui to run on linux 2.0,
and ELKS, if someone writes a int 10h realmode driver.

This requires that an explict screen driver interface be designed, and the clipping code,
along with a host of other line-segment reordering code stuff be moved up into the
nanogui kernel.  In addition, the v0.2 kernel still doesn't support mouse cursor
clipping during graphics draw code.  This needs a redesign, since it's unlikely
to be handled by the low level graphics drivers, without a lot of work for each one.

I have completed all this work late last night, and should have this ready shortly.  (I'm
still asking for design input though).  This will become v0.3.

In v0.4, I should have completed the driver interfaces for the keyboard and mouse
as well, which would allow nanogui to run *totally* standalone on anything that
supports a C compiler.  (yes, this is my real inspiration for the project, we don't need
another X server, we need small projects that can run standalone and on top of existing
operating systems without too much work)

Greg

> In addition nanogui clipping support is contained in the graphics libraries.  Since nanogui

I wanted to avoid that but it has to be that low level for performance. 

> supports a C compiler.  (yes, this is my real inspiration for the project, we don't need
> another X server, we need small projects that can run standalone and on top of existing
> operating systems without too much work)

Yep

Alan,
	I studied your mods heavily for performance considerations, and
the clipping work that you added is basically the same, but placed one procedure
higher, and removed from the lowest level line draw code.  Thus, the extra
overhead is only one extra procedure call.  Don't you agree?

	Also, there needs to be a mid-level procedure anyway, as the nanogui
stuff won't work with out some routines that swap x1/x2 if the line segment is 
right-to-left, rather than left-to-right, etc.  I had to add this to get nanogui to run
with the sample programs.

Greg

On Wednesday, May 05, 1999 1:33 PM, Alan Cox ####@####.#### wrote:
> > In addition nanogui clipping support is contained in the graphics libraries.  Since nanogui
> 
> I wanted to avoid that but it has to be that low level for performance. 
> 
> > supports a C compiler.  (yes, this is my real inspiration for the project, we don't need
> > another X server, we need small projects that can run standalone and on top of existing
> > operating systems without too much work)
> 
> Yep
> 
> 

> the clipping work that you added is basically the same, but placed one procedure
> higher, and removed from the lowest level line draw code.  Thus, the extra
> overhead is only one extra procedure call.  Don't you agree?

Maybe I missed some obvious approaches. You could be right thinking about this.
I was obviously asleep last time

> 
> 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.
> > 

	Sounds good.  If the kernel switched modes, then printk() and other things
could be stopped from trashing the screen.  I also like the screen refresh being kernel's
responsibility.


> > 	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.

	Absolutely.  With the new mouse driver api, a quick stub could be written
for just what ELKS supports.  I haven't decided who should decode the mouse
stuff though.  Currently, nanogui uses GPM repeater mode that allows nanogui
to decode logitech style mouse codes only...


> 
> > 
> > 	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.


	The only issue with ctrl-C is to get the SIGINT signal from the kernel.  Do signals
work now in ELKS?  If so, of course the tty drivers just ksignals SIGINT.


> 
> > 
> > 	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?

	You would ask the hard question.  No, my bcc mod doesn't yet support
prototype checking, but it will compile ansi, which in certain cases, like the following
code, bcc -ansi won't work:

#define feof(fp)	(fp->feof)
	int (feof)(int fd) { }


The above is a obscure ansi feature that allows function names and defines to 
have the same name....  bcc now compiles this (which the minix libc source uses...)
> 
> 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

	Having spent alot of time looking at and compiling ELKS, I think
I can produce a nanogui that will run without much modification.

Greg




> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

> could be stopped from trashing the screen.  I also like the screen refresh being kernel's
> responsibility.

On x86 the refresh is the user space programs job. It should save/restore the
text maps

Why is that?  to keep the kernel smaller?  My initial idea matched with
yours in that user mode should do everything.  It certainly would be simpler.
However, Alistair suggested the kernel should refresh...

On Wednesday, May 05, 1999 1:55 PM, Alan Cox ####@####.#### wrote:
> > could be stopped from trashing the screen.  I also like the screen refresh being kernel's
> > responsibility.
> 
> On x86 the refresh is the user space programs job. It should save/restore the
> text maps
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

> Why is that?  to keep the kernel smaller?  My initial idea matched with

Yes. And also because you may be restoring to another graphical app..

On Tue, 4 May 1999, Greg Haerr wrote:
> I thought that the GPM repeater mode took any mouse and rewrote it to Logitech
> style commands, so that nanoGui has only one set of commands to parse...

That's right, well mouse-systems protocol anyway. I was just saying that
you could write a cut down mouse driver which did the same thing as GPM 
repeater mode but in much less memory.

> I think there's alot of work getting a small xterm together, do you know
> of any really small xterm's anywhere?

No, but I was hoping it wouldn't be too difficult to do something very
simple with a PTY and text output...

> The window manager will have to be linked into nanoGui, and needs to draw the window
> borders.  I have some ideas on this.

I'd like to hear them.

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