John Popplewell wrote:
What is an SDLK_ code supposed to be representing?
Currently, it seems to be the key-label of the equivalent physical key
location on a US keyboard, with a few extra keys thrown in for
international keyboards.
Unfortunately not. That’s what it is with the DirectX backend, but not
with most other backends I’ve tried. See
http://thread.gmane.org/gmane.comp.lib.sdl/24697 .
-Christian
Christian,
Thanks for that, I’ve made a note of it here:
opened 08:49PM - 10 Feb 21 UTC
closed 08:49PM - 10 Feb 21 UTC
# This bug report was migrated from our old Bugzilla tracker.
These attachments… are available in the static archive:
* ~~[Always uses US keymap to create VK_ virtual key codes (us-kb-map.txt, text/plain, 2006-03-14 15:49:25 +0000, 1413 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=80)~~
* ~~[Proposed patch for windib keyboard handling (windib-fixes.txt, text/plain, 2006-03-15 22:34:37 +0000, 5267 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=83)~~
* [Revised patch with scancodes mostly removed (windib-fixes-02.txt, text/plain, 2006-03-16 08:22:39 +0000, 4855 bytes)](https://bugzilla.libsdl.org/attachment.cgi?id=84)
**Reported in version:** HG 1.2
**Reported for operating system, platform:** Windows (All), x86
# Comments on the original bug report:
On 2006-03-14 13:37:19 +0000, John Popplewell wrote:
> Running checkkeys.c with a Swedish keyboard layout produces inconsistent results when using the windib and directx backends. The key at the top-left of the keyboard, SDLK_BACKQUOTE is reported as being SDLK_BACKSLASH. This is caused by Windows returning a different VK_ code for this key when a Swedish keyboard layout is in use. This VK_ code clashes with the VK_ code returned for a different (physical) key on a UK keyboard.
>
> So far, only reported on WinXP SP2.
>
> Orignally reported by Tomas Jakobsson. In the referenced posting I use the term scancode, when I should have said SDLK_ code.
On 2006-03-14 15:49:25 +0000, John Popplewell wrote:
> Created attachment 80
> 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.
On 2006-03-15 06:17:02 +0000, John Popplewell wrote:
> Comment on attachment 80
> Always uses US keymap to create VK_ virtual key codes
>
> Demonstrates the concept, but is badly broken.
On 2006-03-15 06:29:41 +0000, John Popplewell wrote:
> 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
> ...
>
On 2006-03-15 22:34:37 +0000, John Popplewell wrote:
> Created attachment 83
> 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.
On 2006-03-16 05:25:31 +0000, John Popplewell wrote:
> 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.
>
On 2006-03-16 08:22:39 +0000, John Popplewell wrote:
> Created attachment 84
> 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.
On 2006-05-17 23:24:17 +0000, Ryan C. Gordon wrote:
>
> This patch is now in Subversion (revision # 2477). Thanks!
>
> --ryan.
>
>
On 2006-06-24 00:39:33 +0000, Sam Lantinga wrote:
> 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.
I’d vote for 1 also.
I’m working on a patch for windib that loads the US keyboard layout
whatever the system settings, and uses that to make consistent SDLK_
codes.
Is this the kind of ‘trick’ you were thinking of for X11? Or is it more
along the lines of having look-up tables for the raw keyboard scancodes?
John.On Wed, Mar 15, 2006 at 09:47:51AM +0100, Christian Walther wrote:
John Popplewell wrote:
What is an SDLK_ code supposed to be representing?
Currently, it seems to be the key-label of the equivalent physical key
location on a US keyboard, with a few extra keys thrown in for
international keyboards.
Unfortunately not. That’s what it is with the DirectX backend, but not
with most other backends I’ve tried. See
http://thread.gmane.org/gmane.comp.lib.sdl/24697 .
John Popplewell wrote:
I’d vote for 1 also.
Nice to hear
I’m working on a patch for windib that loads the US keyboard layout
whatever the system settings, and uses that to make consistent SDLK_
codes.
Is this the kind of ‘trick’ you were thinking of for X11? Or is it more
along the lines of having look-up tables for the raw keyboard scancodes?
Yes, it involves look-up tables. But I’m no X11 expert (so I don’t know
if a solution similar to yours would be possible), and since a) initial
feedback to my idea didn’t seem very positive and b) Sam has announced
that the keyboard handling will be revamped for 1.3, I haven’t even
started doodling around to see whether it could work.
Maybe I should, so that I have something to show before the 1.3 API gets
finalized.
Thanks anyway for showing that it can be done on the one backend among
the most important four (Quartz, X11, windx, windib) of which I have no
idea.
-Christian