| Then there are two middle layers.  One is for Sun serial keyboard and
| it's used by two lower layers - kbd at zs and by (sparc64) kbd at

Somebody should get rid of kbd_zs for sparc and switch to kbd@zstty.  
Hint.  Hint.  Then we can garbage-collect kbd_zs.

| ldisc.  Another is for PS/2 keyboard with one lower layer for kbd at
| pckbc.  The serial middle layer is just existing kbd code moved around
| and reshaped slightly to conform to the new interface.
|
| I've verified that the serial layer works with zs lower layer (my
| SS1+).  I cannot test sparc64, but at least it compiles ok, and
| changes to the lower layer are pretty minimal nad mechanical.
|
|
| > Where are the keycodes being decoded?  Where are the firmevents
| > being generated?
|
| Upper layer has two callback methods for middle layers:
| kbd_input_keysym() - for console input and kbd_input_event() for firm
| events.  Serial layer just passes what it gets from (a real sun)
| keyboard.  PS/2 layer converts PC keyboard scancodes into Sun keyboard
| scancodes.  So upper layer always looks like a Sun keyboard.  That was
| a design goal, since Xsun already knows about Type5 layout US101A
| keyboard - a PC keyboard in Sun disguise.

So you're converting pc->Sun scancodes in the pckbd driver.  Is there
some reason you didn't just attach to the sunkbd line discipline and 
feed the scancodes in as a serial stream?

Eduardo