Hi,
here is a patch (against current CVS) for the test program ‘checkeys.c’ that
displays the unicode field in hex:
Index: checkkeys.c===================================================================
RCS file: /home/sdlweb/libsdl.org/cvs/SDL12/test/checkkeys.c,v
retrieving revision 1.5
diff -c -r1.5 checkkeys.c
*** checkkeys.c 19 Jan 2006 09:09:32 -0000 1.5
— checkkeys.c 1 Feb 2006 12:40:58 -0000
*** 10,15 ****
— 10,17 ----
#include “SDL.h”
- #define UNICODE
- /* Call this instead of exit(), so we can clean up SDL: atexit() is evil. */
static void quit(int rc)
{
*** 68,74 ****
printf(" (^%c)", sym->unicode+’@’);
} else {
#ifdef UNICODE
! printf(" (%c)", sym->unicode);
#else
/* This is a Latin-1 program, so only show 8-bits /
if ( !(sym->unicode & 0xFF00) )
— 70,76 ----
printf(" (^%c)", sym->unicode+’@’);
} else {
#ifdef UNICODE
! printf(" (0x%04X)", sym->unicode);
#else
/ This is a Latin-1 program, so only show 8-bits */
if ( !(sym->unicode & 0xFF00) )
Not very interesting, but helps demonstrate the problem I’m having with
SDL and X. The CVS version of SDL on Windows and the modified version
of checkkeys do this on XP with a ‘Spanish (Traditional Sort)’ keyboard
mapping:
Key pressed: 47-/ (0x00E7) modifiers: NUM
Key released: 47-/ modifiers: NUM
Key pressed: 303-right shift modifiers: RSHIFT NUM
Key pressed: 47-/ (0x00C7) modifiers: RSHIFT NUM
Key released: 47-/ modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
This is lower-c cedilla and upper-c cedilla (on my UK keyboard this is the
and ~ key, on my US laptop keyboard it is the \ and | key) which is fine.
Key pressed: 96-(0x00F1) modifiers: NUM Key released: 96- modifiers: NUM
Key pressed: 303-right shift modifiers: RSHIFT NUM
Key pressed: 96-(0x00D1) modifiers: RSHIFT NUM Key released: 96- modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
This is lower-n tilde and upper-n tilde (on my UK and US keyboard this
is the ; and : key) which is also fine.
The equivalent on X is similar and also fine:
Key pressed: 231-world 71 (0x00E7) modifiers: NUM
Key released: 231-world 71 (0x00E7) modifiers: NUM
Key pressed: 303-right shift modifiers: RSHIFT NUM
Key pressed: 231-world 71 (0x00C7) modifiers: RSHIFT NUM
Key released: 231-world 71 (0x00C7) modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
Key pressed: 241-world 81 (0x00F1) modifiers: NUM
Key released: 241-world 81 (0x00F1) modifiers: NUM
Key pressed: 303-right shift modifiers: RSHIFT NUM
Key pressed: 241-world 81 (0x00D1) modifiers: RSHIFT NUM
Key released: 241-world 81 (0x00D1) modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
The key names are different, but equivalent, and the unicode field is
valid when the key is released which isn’t portable.
The problem comes when trying to enter ‘composed’ characters. On Windows
I get this:
Key pressed: 39-’ modifiers: NUM
Key released: 39-’ modifiers: NUM
Key pressed: 97-a (0x00E1) modifiers: NUM
Key released: 97-a modifiers: NUM
The first press/release (on my UK keyboard this is the ’ and @ key, on
my US laptop keyboard this the ’ and " key) has an empty unicode field,
but it affects the following ‘a’ key which generates a lower-a acute. On
X I get this:
Unknown Key (scancode = 48) pressed modifiers: NUM
Unknown Key (scancode = 48) released (0x00B4) modifiers: NUM
Key pressed: 97-a (0x0061) modifiers: NUM
Key released: 97-a (0x0061) modifiers: NUM
which is not fine.
Another example on Windows:
Key pressed: 303-right shift modifiers: RSHIFT NUM
Key pressed: 39-’ modifiers: RSHIFT NUM
Key released: 39-’ modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
Key pressed: 97-a (0x00E4) modifiers: NUM
Key released: 97-a modifiers: NUM
which is the previous ‘dead’ key shifted, followed by a, resulting in
lower-a diaeresis (two dots). On X I get this:
Key pressed: 303-right shift modifiers: RSHIFT NUM
Unknown Key (scancode = 48) pressed modifiers: RSHIFT NUM
Unknown Key (scancode = 48) released (0x00A8) modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
Key pressed: 97-a (0x0061) modifiers: NUM
Key released: 97-a (0x0061) modifiers: NUM
which is also not fine.
The other ‘dead’ key on my UK (and US) keyboard when using the Spanish
mapping is the [ and { key, which can be used to produce this:
Key pressed: 59-; modifiers: NUM
Key released: 59-; modifiers: NUM
Key pressed: 97-a (0x00E0) modifiers: NUM
Key released: 97-a modifiers: NUM
which is lower-a grave, and this:
Key pressed: 303-right shift modifiers: RSHIFT NUM
Key pressed: 59-; modifiers: RSHIFT NUM
Key released: 59-; modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
Key pressed: 97-a (0x00E2) modifiers: NUM
Key released: 97-a modifiers: NUM
which is lower-a circumflex. On X, the equivalent is this:
Unknown Key (scancode = 34) pressed modifiers: NUM
Unknown Key (scancode = 34) released (0x0060) modifiers: NUM
Key pressed: 97-a (0x0061) modifiers: NUM
Key released: 97-a (0x0061) modifiers: NUM
Key pressed: 303-right shift modifiers: RSHIFT NUM
Unknown Key (scancode = 34) pressed modifiers: RSHIFT NUM
Unknown Key (scancode = 34) released (0x005E) modifiers: RSHIFT NUM
Key released: 303-right shift modifiers: NUM
Key pressed: 97-a (0x0061) modifiers: NUM
Key released: 97-a (0x0061) modifiers: NUM
which are not fine either.
Note that in an xterm (or konsole) these characters are correctly
generated.
I tested with Xorg 6.8.2 release, a 6.8.2 CVS version, and 6.9.0 release
(Gentoo) and also XFree86 4.3.0.1 (Debian).
Can anyone confirm this bug?
cheers,
John Popplewell.
PS or try the text-tool in a CVS version of Tux Paint: much more fun 