This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.2
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2017-06-20 13:04:57 +0000, stef wrote:

When a dead key is pressed before SDL_StartTextInput() is called to enable text input, the first pressed key tries to complete the composition - which is unwanted, since the composition started when text input was not enabled.

I've noticed this on 2.0.2 on linux. Switching to 2.0.5 did not fix it.

Delaying SDL_StartTextInput() until some time after the dead key went up again didn't solve it. I'm not sure, if a composition even has a time limit. Also, toggling text input a few times (SDL_StopTextInput(), SDL_StartTextInput(), repeat) did not clear this up. I can filter the result of the composition, but that still loses the second keystroke.

Since our application doesn't actually need key composition, a provided-by-sdl way to disable composition would be a good enough solution for us.

Still, SDL_StartTextInput() should reset any compositions in progress, IMO. After all, other keypresses from before SDL_StartTextInput() /are/ cleared from the buffer.

(some more keywords: SDL_TEXTINPUT, IME, Input Methode Editor)

On 2017-06-24 22:50:57 +0000, Eric Wasylishen wrote:

This sounds like the same bug I submitted a patch for, which appears to have been applied before 2.0.5: https://bugzilla.libsdl.org/show_bug.cgi?id=3332

I'm not sure why it's still happening. It might be stepping into a debug build and ensure that X11_ResetXIM is being called.

On 2017-06-24 22:52:50 +0000, Eric Wasylishen wrote:

Sorry, wrong link in my last comment, here is the correct one:
https://bugzilla.libsdl.org/show_bug.cgi?id=3458

Changeset:
https://hg.libsdl.org/SDL/rev/aea47b61c640

On 2017-06-25 12:32:55 +0000, stef wrote:

First, I have to admit, that I stumbled upon the problem last december - and then benched the SDL2-port of our game. The SDL2 libs on my linux distribution (Mint 17.3) are still 2.0.2, so to check with 2.0.5, I installed some deb packages that I found back then - which did not fix the problem. After benching the SDL2-port, I restored 2.0.2 from the distribution package sources.

So, after your comment, I fetched https://www.libsdl.org/release/SDL2-2.0.5.tar.gz and installed that one. The results are not the ones that I remember from last december:

Using the default (german) keyboard layout with dead keys and 2.0.5, the dead keys are just that: dead. Everyting works fine with the "nodeadkeys" keyboard layout - but that's nothing new.

I did some more debugging and noticed, that the keys are not really dead: they properly issue SDL_KEYDOWN and SDL_KEYUP events, with keysym.sym returning 0x40000000 for both keys - which translates to scancode 0, which our game ignored. Further investigation revealed, that keysym.scancode (which we ignored, so far) contained the proper codes 46 and 53.

So, in short. 2.0.5 does fix the issue (resetting the composition) but introduces a new bug by returning the unassigned scancode "0" for both keys in the keysym.sym field. But that one is easy to work around, since keysym.scancode contains the proper values for both keys.

I can't find the 2.0.5 package, that I used for testing in last december - I guess, it was a bad or mislabeled one. For now, I'll stick with the manually compiled 2.0.5 until a 2.0.5 or higher comes up in the package sources for mint. I'm sorry, I filed a bug report for a bug, that is apparently already fixed in the latest version...

Should I file a new bug report for the scancode zero issue?

On 2017-06-25 15:33:12 +0000, stef wrote:

One more (not completely unrelated) question:

If capslock is pressed while text input is off, it is still recognised and toggles the setting. Is that intentional?

IMO it would make more sense, if it would only return keypress events while text input is off - and not change the capslock state.

On 2017-06-25 21:34:29 +0000, Eric Wasylishen wrote:

Using the default (german) keyboard layout with dead keys and 2.0.5, the dead
keys are just that: dead.

So just to confirm, they are working correctly? i.e. with text input mode active, and the German keyboard layout, typing the "^" deadkey, then "e", gives you a text input event for ê? And typing the "^" before calling SDL_StartTextInput then typing "e" gives you an ordinary "e", as expected?

Also - I just submitted a patch to make testing this easier with the "checkkeys" sample app included with SDL. It makes it so clicking the mouse toggles SDL_StartTextInput. https://bugzilla.libsdl.org/show_bug.cgi?id=3682

Regarding the invalid keycode, filing a bug sounds good.

If capslock is pressed while text input is off, it is still recognised and
toggles the setting. Is that intentional?

I'm not sure really. Could file another bug for that.

On 2017-06-25 22:29:30 +0000, stef wrote:

So just to confirm, they are working correctly? i.e. with text input mode
active, and the German keyboard layout, typing the "^" deadkey, then "e",
gives you a text input event for ê?

Our game doesn't render anything but ASCII, but I checked: pressing ^ then e produces an SDL_TEXTINPUT event with 195, 170, 0 as the first three bytes at text.text. If that somehow translates to ê, you're good :)

And typing the "^" before calling
SDL_StartTextInput then typing "e" gives you an ordinary "e", as expected?

yes

On 2017-08-11 17:35:03 +0000, Sam Lantinga wrote:

It looks like this bug is now fixed. Thanks!