I’m french and with my french AZERTY keyboard I have some problems with keyboard input, ie:
I get SDLK_a when pushing the q key
I have to push the coma key to get a SDLK_m
the ‘<’ results in an unknown key code
…
It tends to be pretty annoying…
Use the SDL_* keysyms as gamepad keys… i.e. don’t rely on them to be in
a specific order or have a certain meaning. If you want text input, turn
on UNICODE translation using SDL_EnableUNICODE() and then use the unicode
member of the key event.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I’m french and with my french AZERTY keyboard I have some
problems with keyboard input, ie:
I get SDLK_a when pushing the q key
I have to push the coma key to get a SDLK_m
the ‘<’ results in an unknown key code
…
It tends to be pretty annoying…
Use the SDL_* keysyms as gamepad keys… i.e. don’t rely on them to be in
a specific order or have a certain meaning. If you want text input, turn
on UNICODE translation using SDL_EnableUNICODE() and then use the unicode
member of the key event.
Still, the impression I got from the docs is that I can relay on
SDL_A being generated by pressing the key with “A” on it. I still
never would use it for text ouput, however, we use it to output a
help page - e.g. in exult, something like
“Z - Open stats”
Only that on my mac with german keyboard, I had to press y. Of course
I know this, but new users are confused and complain about this. And
the recent fixes I sent to you for MacOS (X) address exactly this
problem (hopefully for french keyboards, too
Still, the impression I got from the docs is that I can relay on
SDL_A being generated by pressing the key with “A” on it.
That’s correct. Anything else and it’s a bug; either in SDL’s drivers or
in the setup of your machine (probably the former)
Mattias, that’s actually not correct. There are several situations in
which the OS localized keyboard layout doesn’t affect the keysyms that
are generated by the hardware. Max has added a hack to handle this on
MacOS by introducing an additional keytable, but it’s not necessarily
an elegant solution. I believe the same thing happens when using DirectInput
on Windows, and when using the framebuffer console on Linux.
Essentially the problem is that the keyboard scancodes map to a "standard"
set of keyboard keycodes which are completely separate from localized
keyboard text input translation.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
That’s correct. Anything else and it’s a bug; either in SDL’s drivers or
in the setup of your machine (probably the former)
Mattias, that’s actually not correct. There are several situations in
which the OS localized keyboard layout doesn’t affect the keysyms that
are generated by the hardware.
It does not change the fact that it’s completely bogus semantics.
SDLK_Y should not mean “the key that is located in roughly the same
position as the “Y” key on Sam’s own favourite keyboard that the user
has never seen in his life”; it’s not reasonable at all
Max has added a hack to handle this on
MacOS by introducing an additional keytable, but it’s not necessarily
an elegant solution. I believe the same thing happens when using DirectInput
on Windows, and when using the framebuffer console on Linux.
We should look into it solving it then (I haven’t seen Max’ hack)
Essentially the problem is that the keyboard scancodes map to a "standard"
set of keyboard keycodes which are completely separate from localized
keyboard text input translation.
It’s been discussed here before, and I believe the Right Solution
would be to de-couple keyboard codes (scancodes) from keysyms, a la X11,
so instead of
so the event structure would not contain a keysym at all (just a keycode),
keycodes would be “dense” enough to be useful as array or bitvector
indices (in the range 0…255, say), and we can have proper keysyms for
any keys. This also provides a mean to find out whether a key actually
exists on the keyboard — it solves a lot of problems
It does not change the fact that it’s completely bogus semantics.
SDLK_Y should not mean “the key that is located in roughly the same
position as the “Y” key on Sam’s own favourite keyboard that the user
has never seen in his life”; it’s not reasonable at all
I completely agree with this!
We should look into it solving it then (I haven’t seen Max’ hack)
Yep!
It’s been discussed here before, and I believe the Right Solution
would be to de-couple keyboard codes (scancodes) from keysyms, a la X11,
so instead of
so the event structure would not contain a keysym at all (just a keycode),
keycodes would be “dense” enough to be useful as array or bitvector
indices (in the range 0…255, say), and we can have proper keysyms for
any keys. This also provides a mean to find out whether a key actually
exists on the keyboard — it solves a lot of problems
In other words, I also have said this some time ago, there should be as
many SDLK_'s as there exist keys on all keyboards (e.g. SDLK_UNDO fo
AtariST, SDLK_MAIL for MS Ergo Keyboard, etc.). Than we could do the
SDL_KeysymToKeycode() translation (although I think this is not necessary
while the SDL_keycode can contail the correct SDLK_ for the key pressed).
I also think this is the way the docs tells it works like.
At 10:49 Uhr +0200 19.09.2001, Mattias Engdeg?rd wrote:
Sam Lantinga wrote:
That’s correct. Anything else and it’s a bug; either in SDL’s drivers or
in the setup of your machine (probably the former)
Mattias, that’s actually not correct. There are several situations in
which the OS localized keyboard layout doesn’t affect the keysyms that
are generated by the hardware.
It does not change the fact that it’s completely bogus semantics.
SDLK_Y should not mean “the key that is located in roughly the same
position as the “Y” key on Sam’s own favourite keyboard that the user
has never seen in his life”; it’s not reasonable at all
Max has added a hack to handle this on
MacOS by introducing an additional keytable, but it’s not necessarily
an elegant solution. I believe the same thing happens when using DirectInput
on Windows, and when using the framebuffer console on Linux.
We should look into it solving it then (I haven’t seen Max’ hack)
Just so that you get an idea what it does:
First the keymapping table is statically inited as it was before;
this corresponds to a typical US keyboard, qwerty etc.
Then, I add a dynamic loop that read the keymapping table from the
MacOS and adjusts SDL’S table accordingly. Sadly, this table can only
be used to map keys that gernerate an ASCII code; this is why I have
to mix it with the static table initialisation. Luckily, function
keys, return, escape etc. seem to have the same keycode on all the
keyboards I tested with, but this does not mean it will always be the
case Still this solution is much better from the results than the
old one, which had about 10 keys wrong on my keyboard, while the new
now gets them all right.
A last third step is that it does some more static init for the
keypad this is necessary, as the ascii mapping above cannot
distinguish between Keypad-keys and regular keys.
It does not change the fact that it’s completely bogus semantics.
SDLK_Y should not mean “the key that is located in roughly the
same position as the “Y” key on Sam’s own favourite keyboard that
the user has never seen in his life”; it’s not reasonable at all
SDL is primarily a game API, rite ? So, this actually makes sense,
although the names might not be perfect… If i fx. want my game to
use the keys W for up, S for down, A for left, and D for right, on a
QWERTY keyboard, i don’t want the controls to be messed up by default
on other keyboards. Of course the user should be able to change the
default, but the point here is that the default should work, not
require a change.
When you think about it this way, it sounds reasonable. If you want
the letter Q to show up when you press the Q key, use the unicode
translation thingie …
Maybe another solution to this would be to be able to pick a keymap
yourself. Fx, if you’re creating a game that uses the WASD keys like
above, tell it to use the positional (QWERTY) layout when in the game
so that the movement is correct. If this game has a console or
something, the keymap could be set to system default, so that the
keysyms now represent the actual letters in stead of location of keys.
It does not change the fact that it’s completely bogus semantics.
SDLK_Y should not mean “the key that is located in roughly the
same position as the “Y” key on Sam’s own favourite keyboard that
the user has never seen in his life”; it’s not reasonable at all
SDL is primarily a game API, rite ? So, this actually makes sense,
although the names might not be perfect… If i fx. want my game to
use the keys W for up, S for down, A for left, and D for right, on a
QWERTY keyboard, i don’t want the controls to be messed up by default
on other keyboards. Of course the user should be able to change the
default, but the point here is that the default should work, not
require a change.
Well, so on the AZERTY keyboard it would be Z for up, S fro donw etc…
Do I think the way you do?
When you think about it this way, it sounds reasonable. If you want
the letter Q to show up when you press the Q key, use the unicode
translation thingie …
This is usable for typewriters only. What about that user changes the
keyboard layout on the host OS. When I programm an emulator I need to map
scancode (plus SHIFTs etc.) to emulated scancode. And …(see below)
Maybe another solution to this would be to be able to pick a keymap
yourself. Fx, if you’re creating a game that uses the WASD keys like
above, tell it to use the positional (QWERTY) layout when in the game
so that the movement is correct. If this game has a console or
something, the keymap could be set to system default, so that the
keysyms now represent the actual letters in stead of location of keys.
…how do I know that the keyboard is AZERTY to remap it the right way?
Still this solution is much better from the results than the