Re: request for comments: kbdmux(4) (long)

Marcel,

>>- need comments/input from "non-intel" folks;
> 
> make that non-i386...
> 
> This won't be useful on ia64 because syscons doesn't work there and
> I don't plan to try to makee it work there ever. I'm working on a
> replacement where the multiplexing of the keyboard (as well as the
> graphics adapter) is inherently part of the framework. In particular,
> the user will be able to control how input and output devices get
> multiplexed and/or untied into seperate consoles. This all goes beyond
> what you're doing, so don't worry about it.

great. would this eventually replace syscons(4)/pcvt(4)/etc. on all 
supported platforms? or will it always be non-i386 console code?

>>- should kbdmux(4) be merged with kbd/syscons and used by default?
> 
> I think that would make sense, given that syscons is pretty much
> single-head.

ok

>>- 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?
> 
> Yes, if kbdmux(4) becomes default and non-optional, then it makes sense
> to simplify and refactor. This would also be beneficial for the syscons
> replacement I'm writing.

ok

>>- if kbdmux(4) is not default keyboard then what syscons(4) should do? 
>>look for "kbdmux" keyboard first and the look for any ("*") keyboard?
> 
> This quickly gets complex. I would say that if kbdmux(4) is configured
> into the kernel, it will always be used. The question is whether kbdmux
> should be optional or not.

as a transition plan i was thinking about changing syscons(4), so it would

1) (a) have a hint to which keyboard (or keyboards) it should to use by 
default or (b) always try "kbdmux" first then any "*" keyboard

2) if syscons(4) found "kbdmux" keyboard (because kbdmux.ko was loaded 
from the loader.conf or compiled into kernel) then it would scan all 
available non "kbdmux" keyboards and add them to the kbdmux.

the above two steps should be performed on boot and/or when syscons(4) 
detects no active keyboard.

>>- what kbdcontrol(8) behavior should be? should it be smart enough to 
>>recognize if current keyboard is kbdmux and behave differently?
> 
> That depends on whether there's anything special or different it needs
> to do. Since your question seems to imply it does, could you explain
> how, where and why?

right now when usb keyboard is attached devd(8) calls kbdcontrol(1) and 
tries to switch active keyboard. if kbdmux(4) is active the usb keyboard 
should be added to the mux - not switched. in the same time, it is still 
might be desirable to really switch keyboards, i.e. between kbdmux and 
say wired ps2 keyboard that is not in the mux.

so, i was thinking to change kbdcontrol(1) so it would

1) when -k (add/switch keyboard) option is given check if the current 
keyboard is kbdmux the add keyboard to the mux, otherwise switch keyboard.

2) provide a new option to kbdcontrol(1) that would _really_ switch 
keyboard (no matter if current keyboard is kbdmux or not)

3) -K (disconnect keyboard) with kbdmux should either be (a) noop or (b) 
delete keyboard from the mux. i kinda like (a) because user must specify 
keyboard index to disconnect in (b) and this is yet another api change. 
on the other hand it might be desirable to disconnect keyboard from the 
must without detaching it (another new option?)

now, another case is when keyboard is disconnected. in this case devd(8) 
calls kbdcontrol(1) and tries to switch keyboard to kbd0 
unconditionally. in theory this could work (if kbd0 is kbdmux), but may 
be its better to have default keyboard syscons(4) hint and then use 
kenv(1) to fetch it and have kbdcontrol(1) use it.

does this make any sense?

>>- should kbdmux(4) go into 6.x?
> 
> I would say: yes. It's an open issue for a while and it's good to
> get it closed. It's one of those topics that hardcore developers may
> not care too much about, but which is highly valued by the average
> user.
> 
> Note: I don't speak for re_at_, so don't take my yes as an approval to
> do so.

great. thanks for your comments!

max