First some words on the background. The wscons input stream is as follows:

  MD keyboard -A-> MI keyboard -B-> MI display -C-> tty

where -A- is `wskbd_input(struct device *dev, u_int type, int value)':

  type:		One of WSCONS_EVENT_{KEY_UP,KEY_DOWN,ALL_KEYS_UP}
  value:	Numerical id of a key aka scancode.

where MI keyboard `wskbd_translate()' takes a translation map to
  convert the input events to symbols (characters and function /
  command symbols). This function handles key repeat, modifiers
  (Shift, Caps .. Numlock), command processing and composing.

where -B- is `wsdisplay_kbdinput(struct device *dev, keysym_t ks)':

  ks:
    KS_GROUP_Ascii:	A real character (a subset of unicode-16)
    KS_GROUP_Keypad:	A keypad symbol (function only)
    KS_GROUP_Function:	A function key f1.. F1.. Up, Down ...

where -C- is:

  Emulator (VT100, SUN or DUMB) processes function and keypad symbols
  and sends corresponding strings.

  KS_GROUP_Ascii gets sent as is (masked to lower 8 bits).


And now the limitations of this approach. To support the world
outside of Latin-1 we have to deal with more than 256 possible
characters (not at the same time of course).
So we need some form of kernel codeset. This could be done either
implicit (1) as for example Valeriy E. Ushakov <uwe@ptc.spbu.ru>
proposed or it could be done explicit (2).

1) Put it into the translation map `wskbd_softc.sc_map':
  Pro:
    KS_GROUP_Ascii consists of symbols 0x00 .. 0xff, possibly many
    symbols for one value (KS_Agrave == KS_Cyrillic_yu == 0xc0).
  Cons:
    Only one codeset per display, every screen has the same codeset.
    Possibly multiple translation maps per keyboard (one for
    every supported codeset).
    Impossible to get a translation map in readable form back from
    kernel (0xc0 ?=> KS_Agrave or 0xc0 ?=> KS_Cyrillic_yu).

2) Put it into `wsdisplay_kbdinput':
  Pro:
    Locales may be set to individual screens aka vt's.
    Cleaner by design (e.g. in an ideal world the fonts should be
    updated to this codeset).
    Possible to get a translation map in readable form back from
    kernel (because the symbol-value mapping is unique).
  Cons:
    Memory. Every codeset map needs ~200bytes of static memory and
    every screen needs ~1k of dynamic memory for the translation map.

While I still prefer the the explicit solution, I'm looking for more
opinions and comments before this code gets committed.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)