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

On Thu, Jun 23, 2005 at 11:23:51AM -0700, Maksim Yevmenkin wrote:
> 
> - 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?

I think one can argue both ways. Personally I think shift states should
be kept private to the keyboard. However, when processes are given
access to led- and shift states and are allowed to modify them, then
per-keyboard state doesn't pan out. Not unless the API has support for
multiple keyboards. So, go with what makes sense for this particular case.
Chances are that what you have now is already the most sensible, even
if it's not exactly "right".

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

Keep it that way. It's better to make locking changes in seperate
commits, especially when it affects multiple components.

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

I think it's best to look at the release schedule. If this is worthy
to get into 6.0, then don't worry about the duplication. Just make
sure it works and get it committed soon (without forcing it of course).
Then, when the 6 branch has been created, work on refactoring and
locking to get it perfect in 7.0. You can always MFC if such would be
beneficial.

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

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

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

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

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

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

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel_at_xcllnt.net