The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

SDL Forum Index
SDL
Simple Directmedia Layer Forums
The key you just pressed is not recognized by SDL
Jethro Beekman
Guest
Post Posted: Sat Nov 09, 2013 2:21 am
Quote:
Anyway, as long as we get an event for every keypress it's a huge
improvement.

Completely agreed.

Quote:
My little test program

This is on US International with dead keys:

SDL_KEYDOWN: Keycode: Right Shift Scancode: Right Shift
SDL_KEYDOWN: Keycode: 6 Scancode: 6
SDL_KEYUP: Keycode: 6 Scancode: 6
SDL_KEYUP: Keycode: Right Shift Scancode: Right Shift
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_KEYUP: Keycode: A Scancode: A
SDL_EventState(SDL_TEXTINPUT, SDL_ENABLE)
SDL_KEYDOWN: Keycode: Right Shift Scancode: Right Shift
SDL_KEYDOWN: Keycode: 6 Scancode: 6
SDL_KEYUP: Keycode: 6 Scancode: 6
SDL_KEYUP: Keycode: Right Shift Scancode: Right Shift
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_TEXTINPUT: â
SDL_KEYUP: Keycode: A Scancode: A

I think this is the way it should be. All dead keys on my keyboard generate the
correct Keycode/Scancode AFAICT.

I still get "The key you just pressed is not recognized by SDL." but I applied
your patch to 2.0.0 - I assume this is a non-issue.

Quote:
I'd be glad about feedback regarding the patch.

Looks good to me. Maintainers: please merge.

Jethro

On 24-08-13 18:15, Daniel Gibson wrote:> Hi,
Quote:

I think I have fixed the X11 backend now to produce SDL_KEYDOWN/UP
events for dead keys as well, just like SDL2 does on Windows.

My little test program[1] yields the following output on my machine
(german layout with sundeadkeys), when pressing ^ and a, then clicking
into the window and pressing ^ and a again:
* Unpatched SDL2 release version:
The key you just pressed is not recognized by SDL. To help get this
fixed, please report this to the SDL mailing list <sdl at libsdl.org> X11
KeyCode 0 (-Cool, X11 KeySym 0x0 ((null)).
SDL_TEXTINPUT: â
SDL_EventState(SDL_TEXTINPUT, SDL_DISABLE)
The key you just pressed is not recognized by SDL. To help get this
fixed, please report this to the SDL mailing list <sdl at libsdl.org> X11
KeyCode 0 (-Cool, X11 KeySym 0x0 ((null)).
^CReceived SDL_QUIT - bye!

* SDL2 latest hg with my patch[2]:
SDL_KEYDOWN: Keycode: ` Scancode: `
SDL_KEYUP: Keycode: ` Scancode: `
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_TEXTINPUT: â
SDL_KEYUP: Keycode: A Scancode: A
SDL_EventState(SDL_TEXTINPUT, SDL_DISABLE)
SDL_KEYDOWN: Keycode: ` Scancode: `
SDL_KEYUP: Keycode: ` Scancode: `
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_KEYUP: Keycode: A Scancode: A
^CReceived SDL_QUIT - bye!

OK, it's still strange that the Keycode is ` there instead of ^ (some
fuckup in X11KeyCodeToUcs4()?). With the same keyboard layout but
without dead keys (de nodeadkeys instead of de sundeadkeys) I get
Keycode ^ Scancode `...
Anyway, as long as we get an event for every keypress it's a huge
improvement.
Otherwise this is equivalent to the output Boolsheet from IRC got on
Windows with a swiss german layout:
SDL_KEYDOWN: Keycode: ^ Scancode: =
SDL_KEYUP: Keycode: ^ Scancode: =
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_TEXTINPUT: â
SDL_KEYUP: Keycode: A Scancode: A
SDL_EventState(SDL_TEXTINPUT, SDL_DISABLE)
SDL_KEYDOWN: Keycode: ^ Scancode: =
SDL_KEYUP: Keycode: ^ Scancode: =
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_KEYUP: Keycode: A Scancode: A
Received SDL_QUIT - bye!

So the problem was, that dead keys are filtered out with XFilterEvent()
(in X11_DispatchEvent in SDL_x11events.c). Furthermore XFilterEvent()
modifies the event (sets keycode to 0 for the key combined with the dead
key).
My fix[2] is to save the keycode and the type (KeyPress/KeyRelease)
before calling XFilterEvent() for KeyPress/KeyRelease() events and to
call SDL_SendKeyboardKey() accordingly if XFilterEvent() returned True.

I'd be glad about feedback regarding the patch.

Cheers,
Daniel

[1] Test program: http://pastebin.com/sqxtTNzS
[2] The patch: http://pastebin.com/6VWH3m6s

Am 19.08.2013 00:49, schrieb Sik the hedgehog:
Quote:
Personally, I'd consider any key not producing SDL_KEYUP/DOWN to be a
bug, since they're supposed to represent the key and not the
character. The only two exceptions I can think are Pause (keyboard
sends release as soon as it sends press) and stuff like macro keys
(intercepted by the keyboard and never sent to the computer).

2013/8/18, Daniel Gibson <metalcaedes at gmail.com>:
Quote:
I have thought a bit more about it and IMHO it would be nice if dead
keys at least produced SDL_KEYUP/DOWN events when SDL_TEXTINPUT is
disabled.

Attached are a patch which implements that for X11 and a small
test-program that prints current SDL_KEYUP/DOWN and SDL_TEXTINPUT events
and toggles SDL_TEXTINPUT when clicking into the window.

What's the behavior for dead keys on other platforms (Windows, OSX, ..)
(with SDL_TEXTINPUT enabled/disabled?)?
Do they produce SDL_KEY* events or not?

BTW, I find it strange that SDL_TEXTINPUT is enabled by default on some
platforms (those without a screen keyboard?) and not on others, that
feels inconsistent (code in SDL_VideoInit()). There's even a comment
which questions this behavior: "Actually, come to think of it, you
needed to call SDL_EnableUNICODE(1) in SDL 1.2 before you got text input
events." ...

Cheers,
Daniel

Am 17.08.2013 03:47, schrieb Daniel Gibson:
Quote:
Hi,

I found out some things.. basically XFilterEvent() returns True if the
event is the first keypress of a dead key, thus X11_DispatchEvent()
returns (about line 276 and following).

When calling XFilterEvent() on new events:
The first KeyPress event then contains:
- X11 KeyCode 49 (which seems to belong to my ^ key, => ok).
- X11 KeySym 0xFE52 (dead_circumflex)
The second KeyPress event (after ^ pressing again) contains:
- X11 KeyCode 0
- X11 KeySym 0
- Text "^"
- the keysym returned from Xutf8LookupString() is 0x5E (asciicircum)
- the keysym is also asciicircum when typing ^ a for ā btw
- and here you also get this "The key you just pressed is not
recognized..." message

The KeyRelease event is "X11 KeyCode 49, X11 KeySym 0xFE52
(dead_circumflex)" both times.

When *not* calling XFilterEvent() on new KeyPress/Release events and
pressing ^ twice:
Both KeyPress and KeyRelease events contain:
- X11 KeyCode 49
- X11 KeySym 0xFE52 (dead_circumflex).
Both KeyPress events contain:
- Text: "^"
- the keysym returned from Xutf8LookupString() is 0x5E
(dead_circumflex)


So it first looks like not calling XFilterEvent() on KeyPress/Release
events could do the trick.. however that would certainly screw up dead
keys in textinput (e.g. ^+a for ā) and I don't know what other
implications it may have.

I'm not very familiar with the SDL2 textediting stuff, in the
documentation it kinda looks like one should call SDL_StartTextInput()
before expecting SDL_TEXTINPUT events, but it looks like those events
are fired all the time (when a keypress event has a non-empty text from
Xutf8LookupString).
If one is really expected to call SDL_StartTextInput() then that (and
SDL_StopTextInput()) could be used to disable/re-enable calling
XFilterEvent().
If SDL_TEXTINPUT events should be coming in without calling
SDL_StartTextInput() first this probably is no option.

Maybe there are other clever tricks, maybe with XPeekEvent() or
something?

Cheers,
Daniel


Am 17.08.2013 02:53, schrieb Sam Lantinga:
Quote:
It looks like the X server eats the first keypress for composition and
then outputs a 0 keysym for the second press. We can never do anything
useful with that, so I disabled the message. If you find out more
information and/or a smarter way to deal with that, then by all means,
let me know! :)



_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
The key you just pressed is not recognized by SDL
Sam Lantinga


Joined: 10 Sep 2009
Posts: 1765
Post Posted: Sun Nov 10, 2013 10:49 pm
This looks good.  I wrote a patch using this approach here:https://hg.libsdl.org/SDL/rev/713c6a333c33



Thanks!



On Sat, Aug 24, 2013 at 6:15 PM, Daniel Gibson wrote:
Quote:
Hi,

I think I have fixed the X11 backend now to produce SDL_KEYDOWN/UP events for dead keys as well, just like SDL2 does on Windows.

My little test program[1] yields the following output on my machine (german layout with sundeadkeys), when pressing ^ and a, then clicking into the window and pressing ^ and a again:
* Unpatched SDL2 release version:
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list X11 KeyCode 0 (-Cool, X11 KeySym 0x0 ((null)).
SDL_TEXTINPUT: â
SDL_EventState(SDL_TEXTINPUT, SDL_DISABLE)
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list X11 KeyCode 0 (-Cool, X11 KeySym 0x0 ((null)).
^CReceived SDL_QUIT - bye!

* SDL2 latest hg with my patch[2]:
SDL_KEYDOWN: Keycode: ` Scancode: `
SDL_KEYUP: Keycode: ` Scancode: `
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_TEXTINPUT: â
SDL_KEYUP: Keycode: A Scancode: A
SDL_EventState(SDL_TEXTINPUT, SDL_DISABLE)
SDL_KEYDOWN: Keycode: ` Scancode: `
SDL_KEYUP: Keycode: ` Scancode: `
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_KEYUP: Keycode: A Scancode: A
^CReceived SDL_QUIT - bye!

OK, it's still strange that the Keycode is ` there instead of ^ (some fuckup in X11KeyCodeToUcs4()?). With the same keyboard layout but without dead keys (de nodeadkeys instead of de sundeadkeys) I get Keycode ^ Scancode `...
Anyway, as long as we get an event for every keypress it's a huge improvement.
Otherwise this is equivalent to the output Boolsheet from IRC got on Windows with a swiss german layout:
SDL_KEYDOWN: Keycode: ^ Scancode: =
SDL_KEYUP: Keycode: ^ Scancode: =
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_TEXTINPUT: â
SDL_KEYUP: Keycode: A Scancode: A
SDL_EventState(SDL_TEXTINPUT, SDL_DISABLE)
SDL_KEYDOWN: Keycode: ^ Scancode: =
SDL_KEYUP: Keycode: ^ Scancode: =
SDL_KEYDOWN: Keycode: A Scancode: A
SDL_KEYUP: Keycode: A Scancode: A
Received SDL_QUIT - bye!

So the problem was, that dead keys are filtered out with XFilterEvent() (in X11_DispatchEvent in SDL_x11events.c). Furthermore XFilterEvent() modifies the event (sets keycode to 0 for the key combined with the dead key).
My fix[2] is to save the keycode and the type (KeyPress/KeyRelease) before calling XFilterEvent() for KeyPress/KeyRelease() events and to call SDL_SendKeyboardKey() accordingly if XFilterEvent() returned True.

I'd be glad about feedback regarding the patch.

Cheers,
Daniel

[1] Test program: http://pastebin.com/sqxtTNzS
[2] The patch: http://pastebin.com/6VWH3m6s

Am 19.08.2013 00:49, schrieb Sik the hedgehog:

Quote:
Personally, I'd consider any key not producing SDL_KEYUP/DOWN to be a
bug, since they're supposed to represent the key and not the
character. The only two exceptions I can think are Pause (keyboard
sends release as soon as it sends press) and stuff like macro keys
(intercepted by the keyboard and never sent to the computer).

2013/8/18, Daniel Gibson:
Quote:
I have thought a bit more about it and IMHO it would be nice if dead
keys at least produced SDL_KEYUP/DOWN events when SDL_TEXTINPUT is
disabled.

Attached are a patch which implements that for X11 and a small
test-program that prints current SDL_KEYUP/DOWN and SDL_TEXTINPUT events
and toggles SDL_TEXTINPUT when clicking into the window.

What's the behavior for dead keys on other platforms (Windows, OSX, ..)
(with SDL_TEXTINPUT enabled/disabled?)?
Do they produce SDL_KEY* events or not?

BTW, I find it strange that SDL_TEXTINPUT is enabled by default on some
platforms (those without a screen keyboard?) and not on others, that
feels inconsistent (code in SDL_VideoInit()). There's even a comment
which questions this behavior: "Actually, come to think of it, you
needed to call SDL_EnableUNICODE(1) in SDL 1.2 before you got text input
events." ...

Cheers,
Daniel

Am 17.08.2013 03:47, schrieb Daniel Gibson:
Quote:
Hi,

I found out some things.. basically XFilterEvent() returns True if the
event is the first keypress of a dead key, thus X11_DispatchEvent()
returns (about line 276 and following).

When calling XFilterEvent() on new events:
   The first KeyPress event then contains:
   - X11 KeyCode 49 (which seems to belong to my ^ key, => ok).
   - X11 KeySym 0xFE52 (dead_circumflex)
   The second KeyPress event (after ^ pressing again) contains:
   - X11 KeyCode 0
   - X11 KeySym 0
   - Text "^"
     - the keysym returned from Xutf8LookupString() is 0x5E (asciicircum)
       - the keysym is also asciicircum when typing ^ a for ā btw
   - and here you also get this "The key you just pressed is not
     recognized..." message

The KeyRelease event is "X11 KeyCode 49, X11 KeySym 0xFE52
(dead_circumflex)" both times.

When *not* calling XFilterEvent() on new KeyPress/Release events and
pressing ^ twice:
   Both KeyPress and KeyRelease events contain:
   - X11 KeyCode 49
   - X11 KeySym 0xFE52 (dead_circumflex).
   Both KeyPress events contain:
   - Text: "^"
     - the keysym returned from Xutf8LookupString() is 0x5E
       (dead_circumflex)


So it first looks like not calling XFilterEvent() on KeyPress/Release
events could do the trick.. however that would certainly screw up dead
keys in textinput (e.g. ^+a for ā) and I don't know what other
implications it may have.

I'm not very familiar with the SDL2 textediting stuff, in the
documentation it kinda looks like one should call SDL_StartTextInput()
before expecting SDL_TEXTINPUT events, but it looks like those events
are fired all the time (when a keypress event has a non-empty text from
Xutf8LookupString).
If one is really expected to call SDL_StartTextInput() then that (and
SDL_StopTextInput()) could be used to disable/re-enable calling
XFilterEvent().
If SDL_TEXTINPUT events should be coming in without calling
SDL_StartTextInput() first this probably is no option.

Maybe there are other clever tricks, maybe with XPeekEvent() or
something?

Cheers,
Daniel


Am 17.08.2013 02:53, schrieb Sam Lantinga:
Quote:
It looks like the X server eats the first keypress for composition and
then outputs a 0 keysym for the second press.  We can never do anything
useful with that, so I disabled the message.  If you find out more
information and/or a smarter way to deal with that, then by all means,
let me know! Smile




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org