On Wed, May 08, 2002 at 21:18:34 -0000, eeh@netbsd.org wrote:

> | I had to rototill existing sun kbd/ms drivers to factor out the serial
> | (zs) "middle" layer.  Since this driver is used by all sun ports some
> | cross-port coordination will be needed before committing those changes
> | (I cannot easily test sparc64 and have no sun2 or sun3 around at all).
> 
> Why did you have to rototill the kbd/ms drivers? 

Well, "refactored" might be a better word.


> Could you provide a summary of the changes you made?

Existing kbd driver already has 3 layers, only its "upper" and
"middle" layers are somewhat interwined and assume serial keyboard.
So I just factored out the middle layer to a set of downcalls:

/* Downcalls to the middle layer. */
struct kbd_ops {
	int (*open)(struct kbd_softc *);
	int (*close)(struct kbd_softc *);
	int (*docmd)(struct kbd_softc *, int, int);	/* KIOCCMD */
	int (*setleds)(struct kbd_softc *, int, int);	/* KIOCSLED/setleds */
};

open/close are obvious.  docmd processes Sun keyboard commands.
"setleds" is used for KIOCSLED and internal kbd_update_leds() for
console input.

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

The sparc kd.c (console driver) didn't require any changes, since it
already has its input channel abstracted away.



Similar changes were done to the mouse driver, only we don't have to
care for console input, only for firm events, so that one was simple.


SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen