Created attachment 80 [details]
Always uses US keymap to create VK_ virtual key codes

To get your imaginations fired up, here's a hack that makes all keyboards look like a US keyboard so that it can return a language independent SDLK_ code.
Only tested on XP so far. Please tell me there is a better solution than this.

Comment on attachment 80 [details]
Always uses US keymap to create VK_ virtual key codes

Demonstrates the concept, but is badly broken.

Christian Walth has pointed this out to me: http://thread.gmane.org/gmane.comp.lib.sdl/24697

So I guess I'm exploring the possibility of making windib consistant with directx and into option 1.

Interestingly, whilst testing, I noticed that with the directx backend I get the same SDLK_ code for the #~ key (SDLK_BACKSLASH) and the \| key on my UK keyboard, but this could be fixed by changing:

...
DIK_keymap[DIK_BACKSLASH] = SDLK_BACKSLASH;
DIK_keymap[DIK_OEM_102] = SDLK_BACKSLASH;  <-- SDLK_LESS
...

Created attachment 83 [details]
Proposed patch for windib keyboard handling

Current bugs with windib keyboard support (testing with checkkeys.c):
 1. SDLK_ codes change with the keyboard mapping (dx doesn't)
 2. keypad SDLK_ codes change based on num lock (dx doesn't)
 3. return and keypad enter give the same SDLK_RETURN code (dx doesn't)
 4. on Win9x shift keys ignored in cvs, but used to give 'unknown scancode'

The behaviour of caps-lock and num-lock is documented, the behaviour of print-screen and pause (press/release sent once on keydown, nothing on keyup) is, I think, documented, and I haven't been able to do better this.

I've attached a patch for the numbered problems, but it has issues with the use of keyboard scancodes for the keypad and shift-keys (2&4).

It also fixes a cock-up (mine, I think) in the directx driver that causes two of the keys to have the same SDLK_ code.

Notes:
1. is resolved by always using a US keyboard map to generate the SDLK_ code, but the MS function MapVirtualKeyEx() seems to be reliable only for 'printable' keys, so it's a bit messy.

2. Uses scancodes, but could use VK_ codes instead, would still produce SDLK_ codes dependent on num-lock though. Required because MapVirtualKeyEx() doesn't handle the keypad properly.

3. Should work fine everywhere.

4. Uses scancodes, but would be reliable with a list of scancodes for each shift-key, as the VK_SHIFT code *is* reliable. Defaults to making both shift keys appear to be VK_LSHIFT.

Couple of other windib keyboard handling bugs:
 5. shift keys don't roll-over, if you hold one down the other is ignored.
 6. right-alt generates left-ctrl down, right-alt down/right-alt up, left-ctrl up. 

I don't know how to fix these. Number 6 seems to be something to do with right-alt being used as a shift key on e.g. French keyboard.

Created attachment 84 [details]
Revised patch with scancodes mostly removed

Removed need for the majority of the scancodes. Just the ones for left/right shift on Win9x remain. Defaults to VK_LSHIFT if no match, and anyway, the left-right shift and ctrl keys aren't properly independent.

The code hurts the eyes less :) Tested on WinXP, Win2K, Win98SE.

This patch is now in Subversion (revision #2477). Thanks!

--ryan.

By the way, this behavior will change in SDL 1.3 - the intended behavior is that the SDL keysyms reflect the key printed on the keyboard.  This allows the end user to know what the 'z' key is, for example, without having to consult a picture of a US keyboard.  Games which are indended to have the same layout in multiple locales should have different key maps for each keyboard layout.