Non US keymapping problems with DirectInput (solution?)

Ok, it’s a well known problem that SDL using DirectInput doesn’t always
give the correct key codes for the actual keys being pressed when using a
non US keyboard.

After examining the problem, I have to ask why can’t MapVirtualKey() be
used to convert the scancode from DirectInput for the key pressed into a
Virtual Key code that is correct for the keyboard being used.

In the a fairly limited test, using MapVirtualKey to translate the scancode
to a virtual key worked fine.

Just as a note, MapVirtualKey() is already being used by the DirectInput
code when TranslateUNICODE is set, so I don’t see that there would be a
problem always using it.

-Colourless Dragon
aka Ryan Nunn

Exult: http://exult.sourceforge.net/
Pentagram: http://pentagram.sourceforge.net/

Ok, it’s a well known problem that SDL using DirectInput doesn’t always
give the correct key codes for the actual keys being pressed when using a
non US keyboard.

After examining the problem, I have to ask why can’t MapVirtualKey() be
used to convert the scancode from DirectInput for the key pressed into a
Virtual Key code that is correct for the keyboard being used.

In the a fairly limited test, using MapVirtualKey to translate the scancode
to a virtual key worked fine.

The virtual key is used for filling in the unicode member of the keysym
when unicode translation is enabled. What were you proposing it be used
for?

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

If I understand what Ryan meant correctly (I talked about this on IRC
with him a while ago), MapVirtualKey(scancode, 1) maps the scancode to a
virtual key. This virtual key can then be converted into an SDL key sym
by using the VK_keymap array from the DIB event handling code.

The result would be “keysym->sym = VK_KeyMap[MapVirtualKey(scancode,
1)];” in TranslateKey. (Or, precompute it in DX5_initOSKeymap, of
course.)

The advantage to this approach is that the current keyboard map is taken
into account, so (for example) on German keyboards the y/z are swapped
properly. (Currently you get SDLK_z when you press ‘z’ with windib, but
SDLK_y when you press ‘z’ with windx5.)

-Willem JanOn Sat, 2003-07-26 at 21:45, Sam Lantinga wrote:

Ok, it’s a well known problem that SDL using DirectInput doesn’t always
give the correct key codes for the actual keys being pressed when using a
non US keyboard.

After examining the problem, I have to ask why can’t MapVirtualKey() be
used to convert the scancode from DirectInput for the key pressed into a
Virtual Key code that is correct for the keyboard being used.

In the a fairly limited test, using MapVirtualKey to translate the scancode
to a virtual key worked fine.

The virtual key is used for filling in the unicode member of the keysym
when unicode translation is enabled. What were you proposing it be used
for?

Note that some applications want one or the other behavior. Games often
offer eg. default “rdfg”/“wasd” mappings, which would break if those
keys were in different places, such as on a dvorak keyboard. However,
when doing text entry, mapped input is almost always wanted.

However, changing this won’t break things that aren’t already broken:
applications depending on the current dx5 behavior would break if the
windib driver is used for some reason, and would probably work
differently on other platforms.

On the other hand, if you explicitly want mapped input for text entry,
you should probably be using Unicode entry anyway.On Sat, Jul 26, 2003 at 10:13:42PM +0200, Willem Jan Palenstijn wrote:

The advantage to this approach is that the current keyboard map is taken
into account, so (for example) on German keyboards the y/z are swapped
properly. (Currently you get SDLK_z when you press ‘z’ with windib, but
SDLK_y when you press ‘z’ with windx5.)


Glenn Maynard

The advantage to this approach is that the current keyboard map is taken
into account, so (for example) on German keyboards the y/z are swapped
properly. (Currently you get SDLK_z when you press ‘z’ with windib, but
SDLK_y when you press ‘z’ with windx5.)

Note that some applications want one or the other behavior. Games often
offer eg. default “rdfg”/“wasd” mappings, which would break if those
keys were in different places, such as on a dvorak keyboard. However,
when doing text entry, mapped input is almost always wanted.

The problem is of course that you can’t have both positional and mapped
input in a single field.

However, changing this won’t break things that aren’t already broken:
applications depending on the current dx5 behavior would break if the
windib driver is used for some reason, and would probably work
differently on other platforms.

On the other hand, if you explicitly want mapped input for text entry,
you should probably be using Unicode entry anyway.

Of course, but for keyboard hotkeys/shortcuts you want mapped input too,
without using unicode, since you can’t really use the unicode field when
modifiers (ctrl, alt, …) are used. (Things like “Press ‘alt-z’ for the
status window”; it’s very confusing for that to be alt-y on a german
keyboard.)

-Willem JanOn Sat, 2003-07-26 at 23:48, Glenn Maynard wrote:

On Sat, Jul 26, 2003 at 10:13:42PM +0200, Willem Jan Palenstijn wrote:

Why not? “Press alt-?” makes perfect sense if you have a ? key.On Sun, Jul 27, 2003 at 12:12:09AM +0200, Willem Jan Palenstijn wrote:

Of course, but for keyboard hotkeys/shortcuts you want mapped input too,
without using unicode, since you can’t really use the unicode field when
modifiers (ctrl, alt, …) are used.


Glenn Maynard

If I understand what Ryan meant correctly (I talked about this on IRC
with him a while ago), MapVirtualKey(scancode, 1) maps the scancode to a
virtual key. This virtual key can then be converted into an SDL key sym
by using the VK_keymap array from the DIB event handling code.

The result would be “keysym->sym = VK_KeyMap[MapVirtualKey(scancode,
1)];” in TranslateKey. (Or, precompute it in DX5_initOSKeymap, of
course.)

The advantage to this approach is that the current keyboard map is taken
into account, so (for example) on German keyboards the y/z are swapped
properly. (Currently you get SDLK_z when you press ‘z’ with windib, but
SDLK_y when you press ‘z’ with windx5.)

Ah, I understand. Yes, this is probably a good idea. Can you send me a
patch, after you’ve tested it? I don’t have any international keyboards
here to work with.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment