Key codes on MAC OS X

Hi,

I am not very happy with the key codes returned by SDL on
Mac OS X for the national characters. The first non-ASCII key
gets mapped to SDLK_WORLD_0, the next to SDLK_WORLD_1 and so on.

So the returned key code just tells one, that it is a national
key. Even the same key gets different key codes on different key
layouts. Only a look to the unicode value gives more information.

I would prefer to have a latin1 value as a key code. As far as I know
most other platforms are working like this.

I found Xserver/hw/darwin/quartz/quartzKeyboard.c from the X11 guys,
who solved this with a conversion table from MacRoman to Unicode
(see http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/darwin/quartz/quartzKeyboard.c?rev=1.3&view=log)

The main drawback is that now “real” unicode chars (>= 256) can’t
be mapped to something reasonable.

Best regards

Bernhard Ehlers

— src/video/quartz/SDL_QuartzEvents.m.orig Mon Dec 13 08:54:36 2004
+++ src/video/quartz/SDL_QuartzEvents.m Sat Jan 29 15:52:19 2005
@@ -68,7 +68,30 @@
UInt32 state;
UInt32 value;
int i;

  • int world = SDLK_WORLD_0;+
  • /* Precalculated table mapping MacRoman-128 to Unicode. Generated

  •   by creating single element CFStringRefs then extracting the
    
  •   first character. */
    
  • /* Table stolen from X11 - Xserver/hw/darwin/quartz/quartzKeyboard.c */

  • static const UInt16 macroman2ucs[128] = {

  •    0xc4, 0xc5, 0xc7, 0xc9, 0xd1, 0xd6, 0xdc, 0xe1,
    
  •    0xe0, 0xe2, 0xe4, 0xe3, 0xe5, 0xe7, 0xe9, 0xe8,
    
  •    0xea, 0xeb, 0xed, 0xec, 0xee, 0xef, 0xf1, 0xf3,
    
  •    0xf2, 0xf4, 0xf6, 0xf5, 0xfa, 0xf9, 0xfb, 0xfc,
    
  •    0x2020, 0xb0, 0xa2, 0xa3, 0xa7, 0x2022, 0xb6, 0xdf,
    
  •    0xae, 0xa9, 0x2122, 0xb4, 0xa8, 0x2260, 0xc6, 0xd8,
    
  •    0x221e, 0xb1, 0x2264, 0x2265, 0xa5, 0xb5, 0x2202, 0x2211,
    
  •    0x220f, 0x3c0, 0x222b, 0xaa, 0xba, 0x3a9, 0xe6, 0xf8,
    
  •    0xbf, 0xa1, 0xac, 0x221a, 0x192, 0x2248, 0x2206, 0xab,
    
  •    0xbb, 0x2026, 0xa0, 0xc0, 0xc3, 0xd5, 0x152, 0x153,
    
  •    0x2013, 0x2014, 0x201c, 0x201d, 0x2018, 0x2019, 0xf7, 0x25ca,
    
  •    0xff, 0x178, 0x2044, 0x20ac, 0x2039, 0x203a, 0xfb01, 0xfb02,
    
  •    0x2021, 0xb7, 0x201a, 0x201e, 0x2030, 0xc2, 0xca, 0xc1,
    
  •    0xcb, 0xc8, 0xcd, 0xce, 0xcf, 0xcc, 0xd3, 0xd4,
    
  •    0xf8ff, 0xd2, 0xda, 0xdb, 0xd9, 0x131, 0x2c6, 0x2dc,
    
  •    0xaf, 0x2d8, 0x2d9, 0x2da, 0xb8, 0x2dd, 0x2db, 0x2c7,
    
  • };

    for ( i=0; i<SDL_TABLESIZE(keymap); ++i )
    keymap[i] = SDLK_UNKNOWN;
    @@ -211,10 +234,10 @@
    if (state != 0)
    value = KeyTranslate(KCHRPtr, i, &state) & 0xff;

  •        /* Now we should have an ascii value, or 0. Try to figure out to which SDL symbol it maps */
    
  •        if (value >= 128)     /* Some non-ASCII char, map it to SDLK_WORLD_* */
    
  •            keymap[i] = world++;
    
  •        else if (value >= 32)     /* non-control ASCII char */
    
  •        /* Now we should have an MacRoman value, or 0. Try to figure out to which SDL symbol it maps */
    
  •        if (value >= 128)     /* Some non-ASCII char, map it to Unicode */
    
  •            value = macroman2ucs[value-128];
    
  •        if (value >= 32 && value <= 255)    /* non-control Latin1 char */
               keymap[i] = value;
       }
    
    }

I am not very happy with the key codes returned by SDL on
Mac OS X for the national characters. The first non-ASCII key
gets mapped to SDLK_WORLD_0, the next to SDLK_WORLD_1 and so on.

I would prefer to have a latin1 value as a key code. As far as I know
most other platforms are working like this.

Yeah, this is something I want to implement more generally in SDL 1.3

See ya!
-Sam Lantinga, Software Engineer, Blizzard Entertainment