Christophe Cavalaria | 1 Oct 02:00 2005
Picon

Unicode key and AltGr support

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, (r), 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, (p), Scancode (33), keysym (112), mod (20480), unicode (254)

Here's the expected result :

>>> s = u"æ«€¶ŧ←↓→œþ"
>>> [ord(c) 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.
(Continue reading)

Elden Armbrust | 1 Oct 04:58 2005

Re: Unicode key and AltGr support

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, (r), 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)
(Continue reading)

Johannes Schmidt | 1 Oct 11:50 2005
Picon

Re: Unicode key and AltGr support

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, (r), 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, (p), Scancode (33), keysym (112), mod (20480), unicode (254)
>
> Here's the expected result :
> >>> s = u"æ«€¶ŧ←↓→œþ"
> >>> [ord(c) 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
(Continue reading)

Christophe Cavalaria | 1 Oct 19:18 2005
Picon

Re: Unicode key and AltGr support

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, (r), 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, (p), Scancode (33), keysym (112), mod (20480), unicode (254)
>>
>> Here's the expected result :
>> >>> s = u"æ«€¶ŧ←↓→œþ"
>> >>> [ord(c) 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.
(Continue reading)

Ryan C. Gordon | 1 Oct 20:43 2005

Re: Re: Unicode key and AltGr support


> 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.
Andras Salamon | 1 Oct 23:13 2005
Picon

Re: Re: Unicode key and AltGr support

On 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.

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 <at> dns.net

Gmane