cvs commit: src/sys/dev/vkbd vkbd.c vkbd_var.h
marcel at xcllnt.net
Tue Nov 16 18:02:27 PST 2004
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
> 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
> 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
> to go from a 'keypress'-oriented approach to a 'character'-oriented
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
there. The same can and should probably done in the opposite direction.
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
A procedural (KOBJ based) interface for the most elementary functions
probably do it. It's probably also a good idea to have the keymap layer
off special keys to devd(8)...
Marcel Moolenaar USPA: A-39004 marcel at xcllnt.net
More information about the cvs-all