We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3676

Summary: SDL_StartTextInput does not reset compositing
Product: SDL Reporter: stef <dfdfdafsjhdgfjhgddhgj>
Component: mainAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: ewasylishen
Version: 2.0.2   
Hardware: x86_64   
OS: Linux   

Description stef 2017-06-20 13:04:57 UTC 
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)
Comment 1 Eric Wasylishen 2017-06-24 22:50:57 UTC 
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.
Comment 2 Eric Wasylishen 2017-06-24 22:52:50 UTC 
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
Comment 3 stef 2017-06-25 12:32:55 UTC 
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?
Comment 4 stef 2017-06-25 15:33:12 UTC 
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.
Comment 5 Eric Wasylishen 2017-06-25 21:34:29 UTC 
> 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.
Comment 6 stef 2017-06-25 22:29:30 UTC 
> 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
Comment 7 Sam Lantinga 2017-08-11 17:35:03 UTC 
It looks like this bug is now fixed. Thanks!