From: Marcus Sundberg <e94_msu@elixir.e.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Sun, 16 Aug 1998 12:29:26 +0200

Re: keyboard.h changes

> >  I've gone over the keyboard.h and changed some things that were
> >  too Linux/PC-specific or just too weird, and added in missing lots
> >  of missing keys.
>  
> I hope Jason is not using this header file for GGI Console, because if
> he is then you just broke it.  That's the reason that some of the crap
> in there had not been cleaned up before, because there needs to be a
> 1-to-1 correspondence between the values in keyboard.h and the
> keymapping tables in drivers/char/default/*.
>
> I'm a bit pissed off.  Changes to the API, especially when they break
> things (such as removing NORMAL out of the modifier names) should be
> discussed first, implemented second.

Please don't be. I didn't mean to just change things without
discussion. It's just that sometimes you get more done if you
change things first and then change back the things that
makes people want to strangle you. ;-)

And breaking things shouldn't be an issue now... This is the
time when we're suppoed to break things that are bad.
And the _NORMAL_ stuff has always confused me. It seemed to 
imply that for example GGI_KEY_F1 was a non-normal key. ;)

> >  I've also made it Unicode compatible by shifting the "typ" 16 bits 
> 
> It was already Unicode compatible.  The range U+E000 - U+F800 is the
> "application private zone".  Admittedly we had overstepped the mark, but
> that was easily fixed (e.g. starting at 0xE000 instead).

Ok, I didn't know that.
Then there's no problem to change it back (it's just three
lines of code in the entire CVS tree)
I'll also change
#define GGI_KT_META     0xf8
#define GGI_KT_ASCII    0xf9
#define GGI_KT_BUTTON   0xfc
to 0xe0, 0xe1, 0xe2 respectively, and
#define GGI_NORMALKEY(x)        (GGI_KTYP(x) < 0xf0)
to (GGI_KTYP(x) < 0xe0 || GGI_KTYP(x) > 0xf8)
That should as far as I see be enough to keep compatible with
Linux and be able to use full unicode at the same time.
Agreed?

Also we must document that GGI_KTYP and GGI_KVAL is only
useful when GGI_NORMALKEY is false (and btw, shouldn't we
change GGI_NORMALKEY to GGI_UNICODE? Makes sense to me at least)

>   The bigger
> range may also break things (e.g. that use uni_char or uint16 for
> keysyms).  I know it breaks Xmame (there's this dirty big 64K table in
> there -- yes it needs cleaning up but that's not the point).

THAT on the other hand I'm not worried about. label and sym in the
ggi_key_event has always been defined as uint32, so any application
assuming they are limited to 16 bits are just plain stupid.

> >  Btw, isn't there a way to tell left/right shift and eachother on the
> >  Linux console?
> 
> There's the K_SHIFTL, K_SHIFTR keysyms, but AFAIK keymapping tables
> just use K_SHIFT, so the answer is no.

Hmm, that seems correct. I wonder if existing Linux-apps are smart
enough to work if I change my keytable. ;)

//Marcus