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

[Marcel Moolenaar]

On Nov 16, 2004, at 5:17 PM, Philip Paeps wrote:

> One problem we're going to run into quickly are keymaps.  Currently, 
> the maps
> are being handled by syscons (and pcvt).  If we're going to let people 
> have
> multiple keyboards, there will be those who will want to have a 
> US-qwerty and
> a Belgian azerty side-by-side.  Mapping keys will probably need to be 
> handled
> by the driver (or the input system) on a per-device basis rather than 
> by the
> console driver.  That little headache has been fermenting at the back 
> of my
> head since I first started thinking about writing an input layer.  
> I've been
> ignoring it by sticking to the mice bits, but...
>
> Can any syscons gurus shed light on how we could go about convincing 
> syscons
> to go from a 'keypress'-oriented approach to a 'character'-oriented 
> approach?

I'm no guru in this regard, but it's probably best to take it one step 
at a time.
Add a mux and let syscons think there's just 1 keyboard. After that 
it's a good
idea to come up with the abstractions and the layering and move the 
keymap code
there. The same can and should probably done in the opposite direction. 
So that
you can have the output go to multiple displays with a choice of TE.

As for the abstractions and layering, think GEOM without the OO 
obfuscation.
A procedural (KOBJ based) interface for the most elementary functions 
would
probably do it. It's probably also a good idea to have the keymap layer 
send
off special keys to devd(8)...

-- 
  Marcel Moolenaar         USPA: A-39004          marcel at xcllnt.net