From: Steffen Seeger <seeger@physik.tu-chemnitz.de>
  To  : ggi-develop@eskimo.com
  Date: Mon, 6 Jul 1998 15:52:17 +0200 (MEST)

Re: Keyboard Change

> Hi folks,
> 
> Could we please decide the KT_LATIN/KT_LETTER keyboard issue ?  I have
> just "fixed" the X_common/events.c to put the Latin1 keys back where
> they previously were (0xF0xx) -- current programs expect this behaviour
> and AFAIK no decision has been made yet.
> 
> Here's the plan: abolish the KT_LATIN and KT_LETTER defines, and let
> keys like 'A' have their proper unicode value (0x0041).  Much nicer.
> How about it ?
> 
> Making this change also means we need to update the namespace -- we're
> gonna need translation from Linux keysyms -> GGI keysyms and to do that
> we're gonna have to #include both linux/keyboard.h and ggi/keyboard.h.
> 
> The namespace I have in mind is:
> 
>    keys: GGI_KEY_ENTER, GGI_KEY_F1, GGI_KEY_INSERT, ...
>    types: GGI_KT_SPEC, GGI_KT_FN, GGI_KT_SHIFT, ...
>    modifiers: GGI_KM_SHIFT, GGI_KM_CTRL, GGI_KM_ALT, ...

The new KII (Kernel Input Interface - mainly all the former kgi_input 
registration/keyboard handling and event generation stuff) input code 
I have worked on does handle CAPS as follows:

First normal translation (using the keymap table) takes place.
Then (if there are CAPITAL or SMALL in the UNICODE name) it's converted
into the other (SMALL or CAPITAL) case, if that exists.

This requires some ugly tables but with somoe tricks you can make
it fast for the common case. 

Haven't tested this yet, but it should work well, and it allows
you to use plain UNICODE, except for the numpad keys, function keys etc.
(All really special keys). And it works with non-US characters too.A

Great minds do think alike...

> Cheers,
> _____________________________________________  ____
>                                                \  /
>   Andrew Apted   <andrew@ggi-project.org>       \/


			Steffen

PS: KII just handles definition of event types, event generation and
central 'collection' of events. The console handling stuff is still 
left to a independent management code (e.g. EvStack, fbcon or 
mini-KGI-manager), so no need to start long policy discussions.

----------------- e-mail: seeger@physik.tu-chemnitz.de -----------------