Okay, after extensive discussion on IRC, here's what we came up with:
* The SDL scancodes are formalized and taken from the USB standard, with a
few additions for non-standard input devices. There is a new header
SDL_scancode.h with constants for these, SDL_SCANCODE_X (where X comes
from the USB name for the code)
* The SDL keysym is based on the keyboard layout, as it is in SDL 1.2,
expanded to include the USB keys, and to include Unicode values. The
enumerated values are in the form: SDL_scancode | (1 << 30)
* Unicode keysyms are based on the typed character (i.e. lowercase, usually),
not on the key cap label (uppercase for Latin letters, usually).
The uppercasing will happen in SDL_GetKeyName() if necessary.
* SDL_GetScancodeName() is added to return names for the scancodes
* SDL_GetKeyName() has a driver-specific hook to rename certain keys on
various platforms (e.g. left windows vs command). It may also call
SDL_GetScancodeName() for keysyms in the form of USB code | (1 << 30)
* The name for the keypad keys are renamed to "keypad X", e.g.
the keysym for keypad number 5 is SDLK_KEYPAD_5 (and the name "keypad 5"),
not a Unicode value
* Any keysym names from SDL 1.2 that don't fit the standard go into SDL_compat.h
WASD type control systems can look at the scancodes, and flight control
systems (based on key labels) can look at the keysyms.
I'll be massaging the headers pretty soon so we can see what this looks like.
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
SDL mailing list