Unicode key and AltGr support

SDL Development
1

The thread about the AltGr got me to test the feature with the uncommon keys
in the French keyboard I’m using. I’ve tried the AltGr + a few keys
combinations to see the result and I found that a lot of times, SDL didn’t
give me back a correct unicode value. Here’s the results for the AltGr +
azertyuiop keys :

$ ./sdlkeytest-1.2.9
Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
Keyname, ®, Scancode (27), keysym (114), mod (20480), unicode (182)
Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
Keyname, §, Scancode (33), keysym (112), mod (20480), unicode (254)

Here’s the expected result :

s = u"???"
[ord© for c in s]
[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]

I hope the utf8 message will display correctly for all of you. In the list
there’s the corresponding expected unicode values. You can see that no
keypoint above 254 got through the system.

The systems is a Mandrive 2005 with a custom built SDL version 1.2.9.

On a side note, you can see than I get the correct event for the altgr key
so that one isn’t an issue for Unix users I guess :wink:

2

So I wasn’t wrong in my assumption that AltGr is interpereted as two
actual key events…even though it’s somewhat silly to do things that way.
I think the best way to do this would be (programming using sdl, not sdl
dev itself) to check for the control key event press, then check the
next event to see if it is the Alt keypress, then upon the Control keys
release event, check if the alt key is still in the pressed state. It’s
somewhat of a hack, but seems like it SHOULD work on any platform…but
who knows? It’s worth a shot at least.

-Elden

Christophe Cavalaria wrote:>The thread about the AltGr got me to test the feature with the uncommon keys

in the French keyboard I’m using. I’ve tried the AltGr + a few keys
combinations to see the result and I found that a lot of times, SDL didn’t
give me back a correct unicode value. Here’s the results for the AltGr +
azertyuiop keys :

$ ./sdlkeytest-1.2.9
Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
Keyname, ®, Scancode (27), keysym (114), mod (20480), unicode (182)
Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
Keyname, §, Scancode (33), keysym (112), mod (20480), unicode (254)

Here’s the expected result :

s = u"???"
[ord© for c in s]

[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]

I hope the utf8 message will display correctly for all of you. In the list
there’s the corresponding expected unicode values. You can see that no
keypoint above 254 got through the system.

The systems is a Mandrive 2005 with a custom built SDL version 1.2.9.

On a side note, you can see than I get the correct event for the altgr key
so that one isn’t an issue for Unix users I guess :wink:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

3

[…]

$ ./sdlkeytest-1.2.9
Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
Keyname, ®, Scancode (27), keysym (114), mod (20480), unicode (182)
Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
Keyname, §, Scancode (33), keysym (112), mod (20480), unicode (254)

Here’s the expected result :

s = u"???"
[ord© for c in s]

[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]

I hope the utf8 message will display correctly for all of you. In the list
there’s the corresponding expected unicode values. You can see that no
keypoint above 254 got through the system.

On X11, SDL uses XLookupString, which returns a character string
as key translation.
SDL copies only the first character into its unicode field.

Perhaps someone wants to fix the “FIXME” at
src/video/x11/SDL_x11events.c, line 716 :slight_smile:

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI ToolkitOn Saturday 01 October 2005 02:00, Christophe Cavalaria wrote:

4

Johannes Schmidt wrote:> On Saturday 01 October 2005 02:00, Christophe Cavalaria wrote:

[…]

$ ./sdlkeytest-1.2.9
Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
Keyname, ®, Scancode (27), keysym (114), mod (20480), unicode (182)
Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
Keyname, §, Scancode (33), keysym (112), mod (20480), unicode (254)

Here’s the expected result :

s = u"???"
[ord© for c in s]

[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]

I hope the utf8 message will display correctly for all of you. In the
list there’s the corresponding expected unicode values. You can see that
no keypoint above 254 got through the system.

On X11, SDL uses XLookupString, which returns a character string
as key translation.
SDL copies only the first character into its unicode field.

Perhaps someone wants to fix the “FIXME” at
src/video/x11/SDL_x11events.c, line 716 :slight_smile:

Regards,
Johannes

< http://libufo.sourceforge.net > The OpenGL GUI Toolkit

It’s not like some didn’t do that already. I did a google search for
XLookupString unicode and the first hit I found was a message on that same
mailing list with a patch for that same issue.

http://lists.arabeyes.org/archives/developer/2004/June/msg00160.html

5

It’s not like some didn’t do that already. I did a google search for
XLookupString unicode and the first hit I found was a message on that same
mailing list with a patch for that same issue.

http://lists.arabeyes.org/archives/developer/2004/June/msg00160.html

Argh, there’s probably a ton of patches like this that were just flat
out missed. If you have a patch that you think should be in SDL but
never got a response, or (as in this case) you just know of one, please
repost it.

As for the unicode patch, I want to clean it up a little (rfc3629 made 5
and 6 octet UTF-8 sequences illegal, etc), so I’ve put it on my TODO.

–ryan.

6

This would be really, really nice to have in. Our application supports
17 complete translations at present (including Russian and Japanese), and
we need support for wide character user input for our non-ASCII user base.

– Andras Salamon @Andras_SalamonOn Sat, Oct 01, 2005 at 02:43:40PM -0400, Ryan C. Gordon wrote:

http://lists.arabeyes.org/archives/developer/2004/June/msg00160.html

As for the unicode patch, I want to clean it up a little (rfc3629 made 5
and 6 octet UTF-8 sequences illegal, etc), so I’ve put it on my TODO.

7

The thread about the AltGr got me to test the feature with the uncommon keys
in the French keyboard I’m using. I’ve tried the AltGr + a few keys
combinations to see the result and I found that a lot of times, SDL didn’t
give me back a correct unicode value. Here’s the results for the AltGr +
azertyuiop keys :

$ ./sdlkeytest-1.2.9
Keyname, (alt gr), Scancode (113), keysym (313), mod (4096), unicode (0)
Keyname, (a), Scancode (24), keysym (97), mod (20480), unicode (230)
Keyname, (z), Scancode (25), keysym (122), mod (20480), unicode (171)
Keyname, (e), Scancode (26), keysym (101), mod (20480), unicode (0)
Keyname, ®, Scancode (27), keysym (114), mod (20480), unicode (182)
Keyname, (t), Scancode (28), keysym (116), mod (20480), unicode (0)
Keyname, (y), Scancode (29), keysym (121), mod (20480), unicode (0)
Keyname, (u), Scancode (30), keysym (117), mod (20480), unicode (0)
Keyname, (i), Scancode (31), keysym (105), mod (20480), unicode (0)
Keyname, (o), Scancode (32), keysym (111), mod (20480), unicode (0)
Keyname, §, Scancode (33), keysym (112), mod (20480), unicode (254)

Here’s the expected result :

s = u"???"
[ord© for c in s]
[230, 171, 8364, 182, 359, 8592, 8595, 8594, 339, 254]

By the way, this is fixed on Windows in CVS as of today.

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