SDL and language dependent keys

Hello,

I have the following problem with the sdl. I miss the language dependent
keys (for german, french, …) in the SDLKey?definition. In my project I need
to react on this language dependent keys. How can I do this?

Must I use the hardware dependent scancode in the SDL_keysym structure? Or
ist there a way to get the language dependent keys over the unicode field in
the SDL_keysym structure?

E.g. I need to know when a german umlaut, like ? (<-german umlaut :slight_smile: ), is
pressed. In pure X this could be the code XK_odiaeresis. which is the
equivalent in the SDLKey definition? Or must I use the scancode or the
unicode field in the SDL_keysym structure to detect this character.

It would be nice someone can help me with my problem. Thank you in advance
for your help.

Regards

Bernd

E.g. I need to know when a german umlaut, like ? (<-german umlaut :slight_smile: ), is
pressed. In pure X this could be the code XK_odiaeresis. which is the
equivalent in the SDLKey definition? Or must I use the scancode or the
unicode field in the SDL_keysym structure to detect this character.

They should come up as SDL_WORLD_nn. Take a look at
SDL12/include/SDL_keysym.h … You’ll have to test and see which one it
is.

–ryan.

“Ryan C. Gordon” wrote:

They should come up as SDL_WORLD_nn. Take a look at
SDL12/include/SDL_keysym.h … You’ll have to test and see which one it
is.

The SDL_WORLD_nn definitions should go away since they serve no purpose at
all and are confusing at best. I suggest nobody should use them.

The current principle of keysym number assignment is:

  1. For keys whose printed symbols correspond directly to an ASCII code,
    use that ASCII code (8, 9, 13, 27, 32-127)
  2. For some of the other keys, fixed numbers > 255 are used,
    with corresponding definitions in SDL_keysym.h
  3. For the remaining keys, leftover numbers < 255 are used in an unspecified
    way.
  4. As an exception to 3., sometimes key numbers are added to the list in
    SDL_keysym.h in an ad hoc way.

No, this is not a great solution, but it’s how it works right now.

It’s not as bad as it sounds since the SDLK_ constants are rarely needed
except for a) special function keys and modifiers (which mostly are defined),
and b) for the initial values of keyboard bindings. But since most
games that use the keyboard at all support user-controlled key rebinding,
the programmer can conservatively use keys that appear in the list and
let the user bind to his more exotic keys

…
No, this is not a great solution, but it’s how it works right now.

It’s not as bad as it sounds since the SDLK_ constants are rarely needed
except for a) special function keys and modifiers (which mostly are
defined),
and b) for the initial values of keyboard bindings. But since most
games that use the keyboard at all support user-controlled key rebinding,
the programmer can conservatively use keys that appear in the list and
let the user bind to his more exotic keys.

Thank you for your answers.

My project is a SDL driver for a ex?sting emulator. Graphic output now works
very well and in my opinien :slight_smile: better as with the X driver for the
emulator. Espacelly full screen works good in the sdl version.

But for this emulator I need to transform all (O.K. the most) keys to the
keys of the emulatetd system. This is also necessary for the german umlauts or
special french keys…

When I understand right there are undocumented definitions for speciel keys
in SDL_keysym.h. I will later have a look on this. Maybe it works with this,
but are this undocumented definitions supported in future sdl versions too?

But isn’t there a way to do this host to emulator keybinding over the
unicode field in the SDL_keysym structure? I think all keys (characters) of the
european languages must be defined there (In the lowest 256 Byte?).

Maybe I use hardware dependent scancode in the SDL_keysym structure. Are
this hardware dependent scancodes for all Linux drivers (X, framebuffer, …)
the same? Are this scancodes the X scancodes?

O.K. a hardware independent way would be better because the emulator existe
in versions for windows, beos and other os. Maybe the SDL driver is useful
there too.

Best regards

Bernd–
@Bernd_Lachner

Aufgepasst - jetzt viele 1&1 New WebHosting Pakete ohne
Einrichtungsgebuehr + 1 Monat Grundgebuehrbefreiung!
http://puretec.de/index.html?ac=OM.PU.PU003K00736T0492a

But for this emulator I need to transform all (O.K. the most) keys to the
keys of the emulatetd system. This is also necessary for the german umlauts or
special french keys…

That is a problem. Unfortunately the keys that don’t have explicit SDLK_
constants have no fixed value (they may vary between drivers).

When I understand right there are undocumented definitions for speciel keys
in SDL_keysym.h. I will later have a look on this. Maybe it works with this,
but are this undocumented definitions supported in future sdl versions too?

What undocumented definitions are you talking about?

But isn’t there a way to do this host to emulator keybinding over the
unicode field in the SDL_keysym structure? I think all keys (characters) of the
european languages must be defined there (In the lowest 256 Byte?).

Please distinguish keys from characters. Unicode, ASCII and ISO-8859-n
are character encodings, but they are not very useful for encoding keys.

Maybe I use hardware dependent scancode in the SDL_keysym structure. Are
this hardware dependent scancodes for all Linux drivers (X, framebuffer, …)
the same? Are this scancodes the X scancodes?

No, they are not (necessarily) the same. For instance, the X11 driver uses
X keycodes for “scancode”, and these depend on keyboard hardware and X server.

One solution for this mess would be to give each possible key a different
keysym number (like X11 keysyms), with a different SDLK_ define for each.
Then we add API functions to map between scancodes and keysyms, and use
scancodes in SDL keyboard events. This gives us a compact and nice
set of scancodes for internal use, and a wide range of keysyms.

So, instead of writing

if(event->keysym == SDLK_aleph) infinite_lives_cheat();

you would do

SDL_keycode kc_aleph = SDL_KeysymToKeycode(SDLK_aleph);
...
if(event->keycode == kc_aleph) infinite_lives_cheat();

This way, you can in your emulator find the presence of each key when
you start, like this:

SDL_keycode key = SDL_KeysymToKeycode(SDLK_OE_ligature);
if(!key)
    error("You heartless machine, you won't be able to type coeur!\n");
else
    my_keycodes[OE_LIGATURE] = key;

etc. I think this is what we will have to do in SDL 1.3.

But for this emulator I need to transform all (O.K. the most) keys to the
keys of the emulatetd system. This is also necessary for the german umlauts or
special french keys…

That is a problem. Unfortunately the keys that don’t have explicit SDLK_
constants have no fixed value (they may vary between drivers).

You’ve got the point!

Maybe I use hardware dependent scancode in the SDL_keysym structure. Are
this hardware dependent scancodes for all Linux drivers (X, framebuffer, …)
the same? Are this scancodes the X scancodes?

No, they are not (necessarily) the same. For instance, the X11 driver uses
X keycodes for “scancode”, and these depend on keyboard hardware and X server.

One solution for this mess would be to give each possible key a different
keysym number (like X11 keysyms), with a different SDLK_ define for each.
Then we add API functions to map between scancodes and keysyms, and use
scancodes in SDL keyboard events. This gives us a compact and nice
set of scancodes for internal use, and a wide range of keysyms.

Well, my understanding of SDLK_ constants is that they should be
equivalent to SCANCODE_ ones with the thing that they must not be
HW/OS/Driver dependent.
In my opinion we should have as many SDLK_ constants as many real keyboard
keys exists over all keyboards on all computer types in the world.

I’m also writting an emulator that needs this kind of thing.

BTW: I can help with the development if someone allows me to do so.

best regards

STan

What undocumented definitions are you talking about?
This was a little missunderstnding by me. There are only the SDL_WORLD_nn
definitions. Undocumented, because I didn’t find something about thie
definitions in the sdl docs. You say its not a good idea to use SDL_WORLD_nn
definitions and at the moment I think also ist not a good idea.

I think at the moment the best solution is to write hardware/driver :frowning:
dependent functions to decode this special keys. Hopefully this will change in
SDL 1.3. Maybe I can help to implement, or at lest to test this feature in SDL
1.3.

Best regards

Bernd Lachner–
@Bernd_Lachner

Aufgepasst - jetzt viele 1&1 New WebHosting Pakete ohne
Einrichtungsgebuehr + 1 Monat Grundgebuehrbefreiung!
http://puretec.de/index.html?ac=OM.PU.PU003K00736T0492a