From: Steve Cheng <elmert@ipoline.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 2 Jul 1998 15:32:15 -0400 (EDT)

Re: ggiGetc or ggiGetkey?

On Thu, 2 Jul 1998, Andrew Apted wrote:

> I reckon ggiGetc() should ignore modifier keys -- seems more in line
> with the idea of a simple "wait until keypress" function like ggiGetc is.
> 
> The new code would be :
> 
>     static inline int ggiKeyRead(ggi_visual_t vis)
>     {
>             ggi_event ev;
>     
> 	    do {
>                 /* Block until we get a key */
>                 ggiEventRead(vis,&ev,emKeyPress | emKeyRepeat);

(You forgot the closing brace. :-)

>     
> 	    while ((KTYP(ev.key.sym) != KT_SHIFT) && 
>                    (ev.key.sym != K_VOID));
> 
>             return ev.key.sym;
>     }

O Lords of libggi, should we include this?

> I assume SVGAlib gives back MEDIUMRAW keycodes, yeah ?  In that case we
> can simply use the KDGKBENT & TIOCLINUX(10) ioctls to convert the
> keycodes to keysyms.  Look at display/fbdev/kbd.c which already does
> this.

Yes, I've checked the SVGAlib source.  Thanks for all the info!  I have
fixed the SVGAlib target somewhat and committed.  I still have some
questions though:

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.

And the code still does that U(x) stuff:

        kbd_event.key.sym = 0xF000 ^ entry.kb_value;

When will we finally fix this?  In this respect the X target does it
correctly.  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))

and /usr/include/ggi/keyboard.h says:

  #define KT_LATIN        0xf0
  #define KT_LETTER       0xfb    /* symbol that can be acted upon by CapsLock */

Last important issue, the TIOCLINUX ioctl does not work here: it always
returns 0, 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?

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 :(

--
Steve Cheng               

email: steve@ggi-project.org   
www: <http://shell.ipoline.com/~elmert/>;