request for comments: kbdmux(4) (long)

Dear Hackers,

the next version of experimental keyboard multiplexer (kbdmux(4)) is 
available at http://www.geocities.com/m_evmenkin/kbdmux-3.tar.gz.

at this point i'm almost happy with the code. i have tested it with real 
usb keyboard and a couple of ps2 keyboards connected to the ps2 to usb 
adapter.

Jun 22 17:59:38 beetle kernel: ukbd1: CHESEN PS2 to USB Converter, rev 
1.10/0.10, addr 2, iclass 3/1
Jun 22 17:59:38 beetle kernel: kbd2 at ukbd1

console works, X works. i even dropped into the debugger with 
ctrl+alt+esc and all keyboards were still working.

the remaining issues are

- kbdmux model: kbdmux(4) is "super-keyboard" driver that consumes input 
(raw scancodes) from slave keyboards. the side effect is that _all_ 
keyboards attached to the kbdmux share the _same_ state. basically user 
can press ctrl on one keyboard and "C" on another keyboard and it still 
will work. is that good enough?

- locking: right now the code relies on Giant mutex (just like the rest 
keyboard drivers do);

- code duplication: there are a pieces of code that were stolen from 
atkbd.c. very similar pieces of code exist in ukbd.c, vkbd.c and now in 
kbdmux.c. imo that is three times too many. perhaps these pieces could 
be moved into some common shared place?

- need comments/input from "non-intel" folks;

so, providing the code is good, what is the best why to connect 
kbdmux(4) to the rest of the system?

- should kbdmux(4) be merged with kbd/syscons and used by default?

- kbdmux(4) switches all keyboards into K_RAW mode, so if kbdmux(4) is 
the default keyboard then perhaps all keyboard drivers could be 
simplified and just return K_RAW scancodes?

- if kbdmux(4) is not default keyboard then what syscons(4) should do? 
look for "kbdmux" keyboard first and the look for any ("*") keyboard?

- what kbdcontrol(8) behavior should be? should it be smart enough to 
recognize if current keyboard is kbdmux and behave differently?

- should kbdmux(4) go into 6.x?

thanks,
max