From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Fri, 3 Jul 1998 17:09:35 +1000

Re: ggiGetc or ggiGetkey?

Steve writes:

>  in display/fbdev/kbd.c: 
>  
>          kbd_event.key.effect = kbd_event.key.normal = buf[0];
>          kbd_event.key.locked = kbd_event.key.sticky = 0;
>  
>  So this is still wrong (refering to original problem with capslock/shift),
>  isn't it?  It says the locked modifiers are always 0.

Well, I would like to see those four fields of MODIFIER_DATA simplified
to juse one: effect.  IMHO applications only care about the "current
modifiers in effect", and not whether modifier N is sticky or locked or
whatever.  So... can we remove the other three ?

>  And the code still does that U(x) stuff:
>  
>          kbd_event.key.sym = 0xF000 ^ entry.kb_value;
>  
>  When will we finally fix this?

This is correct !  It is really a conversion from the Linux keysym to
the GGI keysym (I'll replace it with a translate_keysym() function).

Linux keysyms are confused, the value you get back from the KDGKBENT
ioctl is xored with 0xF000, so the above code just undoes this
braindamage.  This is the relevent bit from linux/drivers/char/vt:

        case KDGKBENT:
                key_map = key_maps[s];
                if (key_map) {
-->                 val = U(key_map[i]);
                    if (kbd->kbdmode != VC_UNICODE && KTYP(val) >= NR_TYPES)
                        val = K_HOLE;
                } else
                    val = (i ? K_HOLE : K_NOSUCHMAP);
                return __put_user(val, &user_kbe->kb_value);

>  Oh, and the flying_ggis demo key handling breaks when the syms are
>  not U(x) kludged, because it tries to do:
>  
>                                  if ((KTYP(key) == KT_LATIN) ||
>                                      (KTYP(key) == KT_LETTER))

In the "new and improved" world of GGI keysyms this would be something
like :

	if (GGI_KEY_NORMAL(key)) ...

but we haven't reached that brave new world yet... :-))

>  Last important issue, the TIOCLINUX ioctl does not work here: it always
>  returns 0

That's weird.

>  so it doesn't fix the original problem, just makes the code more
>  clean.  Maybe svgalib just told the kernel to not keep shift states or
>  something... could somebody with more knowledge help here?

What kernel are you using ?  Keeping shift state when in RAW/MEDIUMRAW
isn't done in 2.0.27, at least, but it *is* done in 2.1.xx.

Anyway, I just used TIOCLINUX(6) to be lazy and avoid keeping track of
shift-state myself.  If running on oldish kernels is important, then
it will be no sweat to replace that with some shift-keeping code.

>  I'll see what I can do with the X target's key handling -- at least that
>  won't keep bringing down my console like svgalib did :(

Been bitten by the "program crashed with keyboard in raw mode and
there's nothing you can about it" thing myself.  Nowadays there is SAK,
but what I do is add KT_CONS to the TYPES_ALLOWED_IN_RAW_MODE define in
drivers/char/keyboard.c which means at least you can switch out of that
console.

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