The key you just pressed is not recognized by SDL

SDL Development
#1

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 (-8),
X11 KeySym 0x0 ((null)).

That shows up in any SDL2 program when I press the backtick/tilde key. My
keyboard layout is US International w/ dead keys.

Jethro Beekman

#2

This still happens with http://www.libsdl.org/release/SDL2-2.0.0.tar.gz
downloaded just now.

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 (-8),
X11 KeySym 0x0 ((null)).
INFO: Text (\x60): “`”

This line actually only shows up after pressing the key twice. Just checked in
an SDL1.3 game, works fine there.

Jethro BeekmanOn 04-05-13 16:42, Jethro Beekman wrote:

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 (-8),
X11 KeySym 0x0 ((null)).

That shows up in any SDL2 program when I press the backtick/tilde key. My
keyboard layout is US International w/ dead keys.

Jethro Beekman

#3

Interesting that the keycode and keysym are both 0. Can you debug into SDL
and see why?

Thanks!On Mon, Aug 12, 2013 at 7:20 PM, Jethro Beekman wrote:

This still happens with http://www.libsdl.org/release/SDL2-2.0.0.tar.gz
downloaded just now.

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
(-8),
X11 KeySym 0x0 ((null)).
INFO: Text (\x60): “`”

This line actually only shows up after pressing the key twice. Just
checked in
an SDL1.3 game, works fine there.

Jethro Beekman

On 04-05-13 16:42, Jethro Beekman wrote:

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 (-8),
X11 KeySym 0x0 ((null)).

That shows up in any SDL2 program when I press the backtick/tilde key. My
keyboard layout is US International w/ dead keys.

Jethro Beekman

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

#4

Hi,

I’ve got the same behavior here on Linux, German layout with SUN accents:
caedes at Mancubus:~ $ setxkbmap -query
rules: evdev
model: pc105
layout: de
variant: sundeadkeys

When I press ^ (without dead keys SDL_SCANCODE_GRAVE) twice, I get the
following message:
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 (-8), X11 KeySym 0x0 ((null)).

I’ll try to debug it a bit…

Cheers,

  • DanielAm 13.08.2013 06:57, schrieb Sam Lantinga:

Interesting that the keycode and keysym are both 0. Can you debug into
SDL and see why?

Thanks!

On Mon, Aug 12, 2013 at 7:20 PM, Jethro Beekman <jethro at jbeekman.nl <mailto:jethro at jbeekman.nl>> wrote:

This still happens with http://www.libsdl.org/release/SDL2-2.0.0.tar.gz
downloaded just now.

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
<mailto:sdl at libsdl.org>> X11 KeyCode 0 (-8),
X11 KeySym 0x0 ((null)).
INFO: Text (\x60): "`"

This line actually only shows up after pressing the key twice. Just
checked in
an SDL1.3 game, works fine there.

Jethro Beekman

On 04-05-13 16:42, Jethro Beekman wrote:
 > 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
<mailto:sdl at libsdl.org>> X11 KeyCode 0 (-8),
 > X11 KeySym 0x0 ((null)).
 >
 > That shows up in any SDL2 program when I press the backtick/tilde
key. My
 > keyboard layout is US International w/ dead keys.
 >
 > Jethro Beekman
 >
#5

I just noticed your commit 7638:783d1cff9b20 from 2013-08-12 which you
wrote after 2.0.0 tag, but before writing this message…
It hides this problem by checking keycode to be != 0 before printing
that “The key you just pressed is not recognized by SDL” message.

What is the expected behavior for dead keys anyway?

IMHO it would be nice to get keypress events for them anyway (on first
press - this “not recognized” message is after the second key press).

Cheers,
DanielAm 13.08.2013 06:57, schrieb Sam Lantinga:

Interesting that the keycode and keysym are both 0. Can you debug into
SDL and see why?

Thanks!

On Mon, Aug 12, 2013 at 7:20 PM, Jethro Beekman <jethro at jbeekman.nl <mailto:jethro at jbeekman.nl>> wrote:

This still happens with http://www.libsdl.org/release/SDL2-2.0.0.tar.gz
downloaded just now.

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
<mailto:sdl at libsdl.org>> X11 KeyCode 0 (-8),
X11 KeySym 0x0 ((null)).
INFO: Text (\x60): "`"

This line actually only shows up after pressing the key twice. Just
checked in
an SDL1.3 game, works fine there.

Jethro Beekman

On 04-05-13 16:42, Jethro Beekman wrote:
 > 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
<mailto:sdl at libsdl.org>> X11 KeyCode 0 (-8),
 > X11 KeySym 0x0 ((null)).
 >
 > That shows up in any SDL2 program when I press the backtick/tilde
key. My
 > keyboard layout is US International w/ dead keys.
 >
 > Jethro Beekman
 >
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

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

#6

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! :)On Fri, Aug 16, 2013 at 4:10 PM, Daniel Gibson wrote:

I just noticed your commit 7638:783d1cff9b20 from 2013-08-12 which you
wrote after 2.0.0 tag, but before writing this message…
It hides this problem by checking keycode to be != 0 before printing that
"The key you just pressed is not recognized by SDL" message.

What is the expected behavior for dead keys anyway?

IMHO it would be nice to get keypress events for them anyway (on first
press - this “not recognized” message is after the second key press).

Cheers,

Daniel

Am 13.08.2013 06:57, schrieb Sam Lantinga:

Interesting that the keycode and keysym are both 0. Can you debug into

SDL and see why?

Thanks!

On Mon, Aug 12, 2013 at 7:20 PM, Jethro Beekman <jethro at jbeekman.nl <mailto:jethro at jbeekman.nl>> wrote:

This still happens with http://www.libsdl.org/release/**

SDL2-2.0.0.tar.gz http://www.libsdl.org/release/SDL2-2.0.0.tar.gz
downloaded just now.

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
<mailto:sdl at libsdl.org>> X11 KeyCode 0 (-8),

X11 KeySym 0x0 ((null)).
INFO: Text (\x60): "`"

This line actually only shows up after pressing the key twice. Just
checked in
an SDL1.3 game, works fine there.

Jethro Beekman

On 04-05-13 16:42, Jethro Beekman wrote:
 > 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
<mailto:sdl at libsdl.org>> X11 KeyCode 0 (-8),

 > X11 KeySym 0x0 ((null)).
 >
 > That shows up in any SDL2 program when I press the backtick/tilde
key. My
 > keyboard layout is US International w/ dead keys.
 >
 > Jethro Beekman
 >
______________________________**_________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#7

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,
DanielAm 17.08.2013 02:53, schrieb Sam Lantinga:

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! :slight_smile:

#8

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,
DanielAm 17.08.2013 03:47, schrieb Daniel Gibson:

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:

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! :slight_smile:

-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl2_dk_test.c
Type: text/x-csrc
Size: 1461 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130819/7bda0be1/attachment.c
-------------- next part --------------
A non-text attachment was scrubbed…
Name: sdl2_x11_no_deadkeys_wo_textinput.patch
Type: text/x-patch
Size: 1035 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130819/7bda0be1/attachment.bin

#9

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 :> 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:

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:

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! :slight_smile:

#10

I agree in general, but in the end you have to see what technical
limitations the target platforms have and find a common denominator.

@Sam: Do you have any opinion about my patch?

Cheers,
DanielAm 19.08.2013 00:49, schrieb Sik the hedgehog:

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 <@Daniel_Gibson>:

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:

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:

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! :slight_smile:

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

#11

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 (-8), 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 (-8), 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/6VWH3m6sAm 19.08.2013 00:49, schrieb Sik the hedgehog:

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 <@Daniel_Gibson>:

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:

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:

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! :slight_smile:

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

#12

Anyway, as long as we get an event for every keypress it’s a huge
improvement.

Completely agreed.

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.

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,>

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 (-8), 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 (-8), 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:

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 :

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:

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:

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! :slight_smile:

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

#13

This looks good. I wrote a patch using this approach here:

Thanks!On Sat, Aug 24, 2013 at 6:15 PM, Daniel Gibson wrote:

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
    (-8), 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
    (-8), 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:

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 :

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:

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:

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! :slight_smile:

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

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