nanogui: Re: nanoGui development
Subject:
RE: nanoGui development
From:
Greg Haerr ####@####.####
Date:
5 May 1999 19:01:08 -0000
Message-Id: <01BE96F7.7D42A240.greg@censoft.com>
>
> 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: ####@####.####
>
>
