In message <200111272226.fARMQ4k39260@mrynet.com>, you write: 

-> I've just discovered that INDY (TEAL) kernel will work with the graphics
-> console on my R4400 (Haven't tried the R5K yet).  It defeinately has
-> issues, but it seems 95% there for a text-graphics console.  The kernel
-> I'm using is from my mid-November snapshot cdimage.

A small correction (the importance of which will become apparent in a 
minute): the graphics console code doesn't actually do any graphics
ops; it merely uses the ARCS console routines to write to the display.

-> Issues I see are:
-> 
-> o	Booting via "auto" in the command monitor menu (or via the
-> 	Start System icon) doesn't work.  Hangs after reporting the CPU
-> 	Timer Calibration then resets.

Hmm, interesting.  Haven't seen this, but it's been a while since I
played with graphics console.  Maybe I need to borrow that KVM box
from work (too many machine, too few heads).

-> o	Booting via "boot" in the command monitor menu boots all the
-> 	way into multi-user.  However, some control-key sequences
-> 	(namely CTRL-C) do Bad Things.  CTRL-C puts you back at 
-> 	the Command Monitor ">>" prompt.  Additionally, ESC will
-> 	reset the machine.

I haven't seen the ESC thing, but Control-C (and Control-D as well, 
IIRC) are indeed interpreted by the PROM because the PROM is being
used for all console I/O!

-> With the odd CTRL-C capturing when booting via "boot," it appears that
-> the PROM is still intercepting some keystrokes and interpreting them.
-> Seems that it must be instructed to release the keyboard completely
-> to the running program.  I'll check out the PROM code to see what might
-> be effective.

Catch-22.  See above 8-/

I meant to go see if there's a way to stop ARCS from interpreting any
keyboard input and passing it down raw to the kernel, but I never got
the time and then forgot about it until now.

--rafal

----
Rafal Boni                                                  rafal@mediaone.net