Along the way to hunting down a bug I've inserted in the i386
build trying to to use Aviery's patch for a native #0 console, I made some
changes to the host build's console handling.  The summary is that I've
adapted the host build to use the ncurses library.  This allows
char-by-char input easily, and simplifies the work in
driver.KeyboardInterpreter.  Things left to do for this style of
build (from the text console i/o p.o.v.):

(a) handle escape sequences (eg F1) and/or activate keypad() in
ncurses() and adjust the handling in driver.KI to use its translations.
(b) rewrite driver.console to use ncurses so that when the Fx keys are
available, the Right Things will happen.  (On update() and when visible,
use native calls to addch(x,y,c) to draw.)
(c) recognize and handle return correctly.  (This might be something
ncurses will handle automagically with the right settings.)

        None of these should be particularly difficult, though (a) will be
time-consuming.  This will allow us to test shells (when we're ready*,
which should be soon) on the host build.  (consoleVGA on the host build
should be a simple re-write to pop up and use an X window.)

        I'll continue to hack away at figuring what I screwed up when
inserting Aviery's code.  (Which, btw, I did by hand so I could figure out
what he was doing.)

-_Quinn

* See my prior email for options on shells.  If you go with a shell that
isn't its own program and doesn't use too much of the java libraries, it
could start now.  My short-term attention will be divided between
processes and classpath; processes should be finished sooner.



_______________________________________________
Kernel maillist  -  [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel

Reply via email to