Re: keyboard mux driver (straw man proposal & code)

Alexandre,

thanks for trying the code. please read my answers below.

>> next version of experimental keyboard mux can be downloaded from
>> 
>> http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz (~8K)
>> 
>> also on freefall in my home directory
>> (freefall:~emax/kbdmux-2.tar.gz).
>> 
>> i gave up idea of using slave keyboards in K_XLATE mode. for
>> whatever reason i could not get it to work in console (it did work
>> just fine in X).
>> 
>> so, i re-shaped the code and now kbdmux treats slave keyboards just
>> as suppliers of raw at scan codes. when keyboard is added to the
>> mux it will set be switched into K_RAW mode.
>> 
>> i also decided to not add auxiliary device interface. i think its
>> better to pass keyboard mux ioctl's through /dev/console.
>> 
>> i tried the code with one ps/2 keyboard connected to the mux 
>> (pass-through) and it worked for me in both X and console.
>> 
>> any feedback is welcome!
> 
> I did jump up and down couple of times ;) and set out to add separate
> USB numeric keypad to my laptop's keyboard. Here are some observations
> from that undertaking:
> 
> I was not able to disconnect original keyboard from the console to add
> it to the multiplexer:
> 
> kbdcontrol -K < /dev/console
> kbdcontrol: unable to obtain keyboard information: Inappropriate ioctl
> for device

hmm... this is strange. i usually get this when my console does not have 
any keyboard attached.


> I have managed to work around this by using yet another USB keyboard and
> attaching it to the console using 'kbdcontrol -k /dev/kbd1
> < /dev/ttyv0'.

yes. this is awkward right now. basically kbdmux needs ioctl to 
add/remove keyboard to/from mux. however it is not possible to open 
/dev/kbdX (or /dev/atkbdX for example) once keyboard was 
"kbd_allocate"ed. this part needs more work on mux/syscons/kbd side, but 
because its still experimental it is not done yet.

> After that I was able to add both original keyboard and USB keypad to
> the multiplexer and attached that to the console. At this point both
> keyboards provided input to console and X with following side effects:

excellent!

> -- keyboard lights (caps lock and num lock) on the main keyboard would
> not turn on. 

yes. i think i know why this might be. kbdmux does not do anything on 
SETLED ioctl (except updating its internal state). because there might 
be more then one keyboard in the mux i was not sure which keyboard (or 
all of them?) should get lights turned on.

> -- keypad would work in the "arrows" ("up"/"down"/"left"/"right") mode
> on startup.

ok

> -- "Caps lock" would capitalize main keyboard (there are no letters on
> the keypad). 

"caps lock" on keypad or main keyboard? i'm not sure i understand the 
problem.

> -- "Num lock" would switch keypad into numeric mode, but leave main
> keyboard alone (as it is the case with laptop keyboards it has
> sprinkling of numerals on the right side overlapping letters).

again "num lock" on keypad or main keyboard?

> -- Key "5" on the keypad will not produce number "5" in any mode, the
> rest of the keys ('-', '+', '*', '/', <backspace> and <enter>) seem to
> work properly.

ok, probably scancode translation problem.


> I am running -CURRENT as of May 14th with console high resolution patch.
> Machine is Averatec 3150H, keypad is manufactured by iConcepts, but
> represents itself as CHESEN USB keyboard.
> 
> If there is any additional information that I can provide or there is
> something you want me to experiment with, please, let me know. 

thanks again for trying this and reporting the problems. i will try to 
get myself a couple of usb keyboards and reproduce/fix the problems.

thanks,
max