From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 17 Aug 1998 14:04:04 +1000

Re: keyboard.h changes

Marcus writes:

>  > Seriously though, the _API_ deserves special treatment since changing
>  > that breaks all the programs using that API, which are not under our
>  > control.
>  
>  Well, we've been continously breaking things in the libggi API for
>  eight months now, so it really doesn't matter if we break one 
>  more thing NOW.

Yes, but breaking the API needs some consensus.  I could have just went
ahead and changed the ggiSetOrigin() behaviour to use pixels instead of
dots, but someone said "no way" so I didn't.

>  > Personally I'd like to move away from the Linux keysyms and the crap
>  > they contain (like the big gap between K_F20 and K_F21 -- just crazy, or
>  > the KT_CUR type with only four keys in it), but this depends heavily on
>  > whether GGI Console will be using them...
>  
>  Well, the only reason it should matter which system GGI Console uses
>  if it wishes to be compatible with Linux, and with 2.1 kernels
>  that's not possible if we wan't unicode, because 2.1.114
>  linux/keyboard.h contains:
>  #define KT_LOCK		10
>  #define KT_LETTER	11	/* symbol that can be acted upon by CapsLock */
>  #define KT_SLOCK	12

Maybe you're forgetting that U() macro, which xor'd things with 0xF000.
The actual keytables store those as 0xFAxx, 0xFBxx, 0xFCxx.  The U() was
some reference to Unicode AFAIK, but IMHO the whole way Linux handles
all this is pretty dodgy. 

>  (KT_LOCK and KT_SLOCK looks very similiar in purpose
>  to our GGI_KM_LOCKED and GGI_KM_STICKY btw)

Yeah same thing, different implementation.  Will need a bit of extra
conversion in GGI Console and LibGGI, but things won't die horribly if
it isn't done.

>  >    if (GGI_KTYP(sym) == GGI_KT_LATIN1) {
>  >       printf("Hey, a Latin1 character '%c' !\n", GGI_KVAL(sym));
>  >   }
>  
>  Ok, GGI_KTYP might be useful in this case, but GGI_KVAL is never:
>  for latin1 keys GGI_KVAL(sym) == sym, and for unicode keys that
>  are not latin1, GGI_KVAL will mask off the 8 highest bits.

It's like GGI_KV_A which most people would know is just 'A' :-).
You're right though, GGI_KVAL() is rather useless under normal
circumstances, and probably should only be mentioned in passing in
the docs.

>  >    #define GGI_UNICODE(x)  ((x) < 0xE000 || (x) >= 0xF900)
>  > 
>  > (Just checked, the private zone really is 0xE000..0xF8FF).
>  
>  Ok fine, it'll let us keep GGI_KT_META == 0xf8 too (is that used
>  for anything? :)

ALT+<letter>  

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