cvs commit: src/sys/dev/vkbd vkbd.c vkbd_var.h src/sys/modules/vkbd Makefile

[Maksim Yevmenkin]

On Tue, 16 Nov 2004 11:41:56 -0700 (MST), M. Warner Losh <imp at bsdimp.com> wrote:
> In message: <20041116183549.GB11906 at odin.ac.hmc.edu>
>             Brooks Davis <brooks at one-eyed-alien.net> writes:
> : I'm primairly intrested in solving the problem of machines with a AT
> : keyboard controller (which currently attached non-existant keyboards to
> : allow hot-pluging) and a USB keyboard.  The second case I'm intrested
> : in is a LOM card.  In one case I've seen one present the keyboard as a
> : USB keyboard which means you need to support two USB keyboards.
> 
> I think emax's vkbd isn't the same as the 'many to one' keyboard mux
> driver that's been talked about to solve #1 of your two desires.  It

that is true, but... you *could* obtain scan codes from two or more
sources and write them into the *same* vkbd. so, you could call it a
keyboard mux to some extend. the only problem is the vkbd state
(shifts controls etc). the state problem have to be addressed by user
right now. there might be a way to solve it. basically create one
virtual keyboard and then attach few cdev's to it. each cdev will
maintain its own state. the "final" scancodes from each cdev will go
into the same virtual keyboard.

> is designed to allow other sources of key events that come from
> outside the kernel.  I don't think he's implementing the moral
> equivalent of moused.

again true

max