keyboard handling in Maiko

[Larry Masinter]

There is a lot of patching in maiko to handle new keyboards as they became available.

Sometimes by introducing yet another layer

Just to get an “order of magnitude” handle on how much code to read and understand:

 

cd maiko

grep -ri keyboard src inc

 

 

--

https://LarryMasinter.net https://interlisp.org

 

[Nick Briggs]

Add to that the include files (grep -r keyboard maiko/inc/) ... of particular interest (in an X11 based system) is the XKeymap.h and associated uses in the x<mumble>.c code.  A lot of the rest is just the mechanics of handling the keys not the interpretation of them.

inc/devif.h:/* Definition of the keyboard. Note that the keyboard is also */

inc/devif.h:    PFV device_event; /* Event handler for the keyboard. */

inc/devif.h:   get from the keyboard as an index. The value

inc/devif.h:    unsigned char lastbyte; /* Last byte that we got from the keyboard. */

inc/devif.h:    PFV prev_handler; /* The previous keyboard handler.

inc/initkbddefs.h:void keyboardtype(int fd);

inc/initkbddefs.h:void init_keyboard(int flg);

inc/initkbddefs.h:void keyboardtype(int fd);

inc/keyboard.h:/* $Id: keyboard.h,v 1.2 1999/01/03 02:06:06 sybalsky Exp $ (C) Copyright Venue, All Rights Reserved  */

inc/miscstat.h:    int keyboardwaittime;

inc/mnxdefs.h:  /* This uses the same ring-buffer scheme as keyboard codes do       */

inc/XKeymap.h:/* Generic X-keyboard map for Medley.  This table is used at */

inc/XKeymap.h:/* for non-ASCII characters isn't standard among keyboards.  To */

inc/XKeymap.h:/* not every keyboard has every key (e.g., Alt vs Meta), there */

inc/XKeymap.h: *  reusable, (Lisp keyboard) code, (X keysym) symbol

inc/xwinmandefs.h:void enable_Xkeyboard(DspInterface dsp);

inc/xwinmandefs.h:void disable_Xkeyboard(DspInterface dsp);

inc/xwinmandefs.h:void beep_Xkeyboard(DspInterface dsp);

On Feb 21, 2022, at 2:49 PM, Larry Masinter <L...@acm.org> wrote:

There is a lot of patching in maiko to handle new keyboards as they became available.

Sometimes by introducing yet another layer

Just to get an “order of magnitude” handle on how much code to read and understand:

 

cd maiko

grep -ri keyboard src inc

<image001.png>

 

 

--

https://LarryMasinter.net https://interlisp.org

 

-- 
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lispcore/002a01d82775%244b1628f0%24e1427ad0%24%40acm.org.

[Nick Briggs]

So we're all on the same page:

Maiko traffics in X11 *key codes* not *key syms* -- see https://tronche.com/gui/x/xlib/input/keyboard-encoding.html but the code gets the key syms associated with each key code to guide the construction of its own X11 key code to Lisp key number (i.e., bit number in the 112 bit (= 7x16) key bits).

If you compile initkbd.c (and only initkbd.c) with -DDEBUG then you'll see the tables it gets from X11 and the table it constructs for the mapping.

I suggest doing a "./makeright x" then "touch ../src/initkbd.c" then another "./makeright x", then copy the compilation line for initkbd.c and paste it with the addition of "-DDEBUG", and then another "./makeright x" -- all so you can easily pick out the correct compiler invocation line with the correct options...

I compared the results of XGetKeyboardMapping() when I started with the US keyboard setup (in macOS) to the German one.   Turns out they're identical -- it does NOT reflect the German mappings... and yet,

From "xev" with US keyboard:

KeyRelease event, serial 34, synthetic NO, window 0x600001,

    root 0x1a1, subw 0x0, time 516050454, (142,86), root:(142,109),

    state 0x0, keycode 58 (keysym 0x60, grave), same_screen YES,

    XLookupString gives 1 bytes: (60) "`"

    XFilterEvent returns: False

and with the German keyboard:

KeyRelease event, serial 34, synthetic NO, window 0x600001,

    root 0x1a1, subw 0x0, time 516123922, (114,136), root:(114,159),

    state 0x0, keycode 58 (keysym 0x3c, less), same_screen YES,

    XLookupString gives 1 bytes: (3c) "<"

    XFilterEvent returns: False

so I need to look more closely...

[John Cowan]

On Mon, Feb 21, 2022 at 7:13 PM Nick Briggs <nicholas...@gmail.com> wrote:

 

Maiko traffics in X11 *key codes* not *key syms* -- see https://tronche.com/gui/x/xlib/input/keyboard-encoding.html but the code gets the key syms associated with each key code to guide the construction of its own X11 key code to Lisp key number (i.e., bit number in the 112 bit (= 7x16) key bits)

 

Got it: keycodes encode the actual key pressed or released, whereas a sequence of keysyms indicates the characters being sent in the X11 encoding.

From "xev" with US keyboard:

KeyRelease event, serial 34, synthetic NO, window 0x600001,

    root 0x1a1, subw 0x0, time 516050454, (142,86), root:(142,109),

    state 0x0, keycode 58 (keysym 0x60, grave), same_screen YES,

    XLookupString gives 1 bytes: (60) "`"

    XFilterEvent returns: False

Exactly, meaning that keycode 58 on the US keyboard is translated to the keysym 0x0060, which is the ASCII grave accent.

and with the German keyboard:

KeyRelease event, serial 34, synthetic NO, window 0x600001,

    root 0x1a1, subw 0x0, time 516123922, (114,136), root:(114,159),

    state 0x0, keycode 58 (keysym 0x3c, less), same_screen YES,

    XLookupString gives 1 bytes: (3c) "<"

    XFilterEvent returns: False

And in this case, the same keycode is translated to the keysym 0x3c, less than.   Some keys return more than one keysym.

Now if we switch from translating the keycodes to Lisp to translating the keysyms, then we don't need to add support for every possible keyboard, because X is translating the keycodes so we don't have to..  Admittedly, there are more keysyms (1591) than there are keycodes (256), and the codes are not contiguous, so the bit vector would be about 6 times larger.  In addition, a constant hash table would be needed to translate the full range of keysyms (2^32, I think) to the index into the bit vector.  But if this conversion is done, it's done once and for all and supports all keyboards.