Further to the keyboard discussion today - SDL2/SDL_Keycode

[Nick Briggs]

This is the table of scan codes and key codes that SDL can present the program with:

https://wiki.libsdl.org/SDL2/SDL_Keycode

but there are some oddities — such as the SDL_SCANCODE_GRAVE / SDLK_BACKQUOTE where it notes:

"`" (Located in the top left corner (on both ANSI and ISO keyboards). Produces GRAVE ACCENT and TILDE in a US Windows layout and in US and UK Mac layouts on ANSI keyboards, GRAVE ACCENT and NOT SIGN in a UK Windows layout, SECTION SIGN and PLUS-MINUS SIGN in US and UK Mac layouts on ISO keyboards, SECTION SIGN and DEGREE SIGN in a Swiss German layout (Mac: only on ISO keyboards), CIRCUMFLEX ACCENT and DEGREE SIGN in a German layout (Mac: only on ISO keyboards), SUPERSCRIPT TWO and TILDE in a French Windows layout, COMMERCIAL AT and NUMBER SIGN in a French Mac layout on ISO keyboards, and LESS-THAN SIGN and GREATER-THAN SIGN in a Swiss German, German, or French Mac layout on ANSI keyboards.)

… yeah, *that* makes it easy to figure out what one ought to do with that key!

Indeed, if you’re using the US English keyboard on a Mac laptop it produces

scancode 53 (`) keycode 96 (`) mod 0

and if you switch to German layout on a US English keyboard it produces

scancode 53 (`) keycode 60 (<) mod 0

which is consistent with what it says in the last clause above (I think my US mac has an ANSI physical keyboard layout), except that SDL isn’t going to resolve the shift modifier, so you have to guess - the SDL people don’t think you should know the layout.  See https://github.com/libsdl-org/SDL/issues/5977  - for *some* things you can look at the “textinput” event instead of the “key” event, but if the control key is pressed you don’t get the “textinput” event (which in the non-control case gives you the UTF-8 encoded string for the shift-resolved character)

The other thing to consider is that *if* SDL is talking to an X11 server as its display backend… it looks at the X11 modmap settings (the same one that is NOT completely correct when you’re talking to XQuartz) and tries to figure out what the physical keyboard layout is based on the map it found… essentially the same kind of opaque code that we have in the lde X11 keyboard mapping.  And it can get confused if you remap to many of the “wrong” keys.  I’m not sure what it does when it is deal with native Cocoa windows/input.

Sigh.

— Nick

[John Cowan]

On Mon, Nov 20, 2023 at 10:57 PM Nick Briggs <nicholas...@gmail.com> wrote:

the SDL people don’t think you should know the layout.

And rightly so.  To pick a language at random, there are 8 different keyboard layouts for Bulgarian, none of which are shared with any other language.  Replicating that knowledge into the idiosyncratic code of every GUI program horribly doesn't scale.  The Control-oddball cases do have to be handled separately, and some things won't work, but you can eliminate *most* of the problem by using textinput,

[Nick Briggs]

Of note is the picture of the assignments of the Sun type3 and type4 keyboard keys to Lisp key codes (bit number), see (pdf page numbering) pg 33 ff. 

https://interlisp.org/documentation/SunUserGuide.pdf

which *does* include the cursor keys, but as they appear on the number pad keys 2, 4, 6, 8 and End/Home/PgUp/PgDown on 1, 7, 9, 3

We have bit assignments in key numbers for these, but I suspect neither the assignments from X nor SDL key codes are complete and correct.

— Nick

[Nick Briggs]

But the Sun type 3/4 keyboards didn’t have a separate cursor block - which the Sun type 5 does, and it sends the Left/Right etc, for the cursor keys, while the keypad ones always send the KP_nn codes.

I think we need to know at least some aspects of the physical configuration of the keyboard, independent of the language, to make sensible assignments.