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

[Scott Long]

Maksim Yevmenkin wrote:
> On Tue, 16 Nov 2004 10:09:05 -0800, Brooks Davis
> <brooks at one-eyed-alien.net> wrote:
> 
>>On Tue, Nov 16, 2004 at 10:00:24AM -0800, Maksim Yevmenkin wrote:
>>
>>
>>
>>>On Tue, 16 Nov 2004 18:43:58 +0100, Poul-Henning Kamp
>>><phk at phk.freebsd.dk> wrote:
>>>
>>>>In message <bb4a86c7041116093262758595 at mail.gmail.com>, Maksim Yevmenkin writes
>>>>:
>>>>
>>>>
>>>>
>>>>>On Tue, 16 Nov 2004 18:04:56 +0100, Poul-Henning Kamp
>>>>><phk at phk.freebsd.dk> wrote:
>>>>>
>>>>>>In message <200411161659.iAGGxNiX087329 at repoman.freebsd.org>, Maksim Yevmenkin
>>>>>>writes:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>emax        2004-11-16 16:59:23 UTC
>>>>>>>
>>>>>>> FreeBSD src repository
>>>>>>>
>>>>>>> Added files:
>>>>>>>   sys/dev/vkbd         vkbd.c vkbd_var.h
>>>>>>>   sys/modules/vkbd     Makefile
>>>>>>> Log:
>>>>>>> Add virtual AT keyboard driver vkbd(4).
>>>>>>> Not yet connected to the build.
>>>>>>
>>>>>>I thought we had one of those already ?
>>>>>
>>>>>when? where? did i miss it?
>>>>
>>>>sys/dev/kbd (and various MD stuff all over the place) ?
>>>
>>>perhaps i'm missing something here. the idea behind vkdb(4) is to
>>>create a keyboard without a keyboard. that is to create a keyboard
>>>that accepts scan codes from userspace and not from real hardware.
>>>that is what vkbd(4) does. it creates a new keyboard (just like
>>>ukbd(4) etc) and register it with kbd(4). basically what i want to do
>>>is to obtain scan codes from bluetooth keyboard and then feed them
>>>into the kernel. the idea is that bluetooth hid daemon looks for the
>>>bluetooth keyboard, connects to it, switches active keyboard to
>>>vkbd(4) , reads scan codes and feeds them into vkbd(4). when bluetooth
>>>keyboard is gone the bluetooth hid daemon switches back to wired
>>>keyboard. i do not think i can do it with kdb(4), can i?
>>
>>Have you considered making the virtual keyboard an in kernel client of
>>it's child keyboard(s)?  If you don't do this, you can't use the virtual
>>keyboard in single user mode or in the debugger.
> 
> 
> vkbd(4) man page says that it will not work with ddb(4) :) and (at
> this point) i'm not sure whether this is required. in case of
> bluetooth hid all scan codes have to passed through bluetooth stack. i
> definitely do not want to use bluetooth keyboard in ddb(4) or in
> single user mode :)
> 
> i think i see where you are going. you are probably thinking about
> some sort of lights-out management where you use only network
> connection to control box remotely, a-la pc-weasel and eric cards. am
> i close?
> 
> max

I appreciate the work here, but we are starting to grow too many 
independent keyboard abstractions that don't seem to work together and
don't seem to solve the primary problem that we have right now.  What
we really need is a single unified keyboard and mouse virtualization
layer that allows bluetooth, usb, and at/ps2 devices to plug in at the
bottom and talk to the one or more console interfaces at the top.  It
should allow devices to be plugged in at runtime and should insulate
the real console interface from caring which keyboard is plugged in at
boot, if any are at all.  And yt _does_ need to work in single user mode
and in DDB.

I know I'm saying a lot of 'shoulds' right now, but the rise of these
non-at/ps2 keyboards is causing us lots of problems and we need to fix
it.  Brooks had talked about working on something similar to what I've
described above, so please work with him to mold your vkbd work into
that model.

Scott