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 2834 - Patch to support dead keys on Windows
Summary: Patch to support dead keys on Windows
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.1
Hardware: x86_64 Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.4
: 2747 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-06 00:32 UTC by Elisée Maurer
Modified: 2015-06-25 18:58 UTC (History)
4 users (show)

See Also:

Attachments
SDL_windowevents.c patch to fix dead keys (1.43 KB, patch)
2015-01-06 00:32 UTC, Elisée Maurer 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Elisée Maurer 2015-01-06 00:32:50 UTC 
Created attachment 1984 [details]
SDL_windowevents.c patch to fix dead keys

When inputting text, dead-keys are currently not handled correctly on Windows with the latest SDL2 tip as well as the 2.0.3 release.

Using a French AZERTY keyboard, when I type the `^` key followed by `e` key to compose the `ê` character, I erroneously get two SDL_TEXTINPUT events, one with the `^` character and one with the `e` character.

I've looked at the history for SDL_windowsevents.c and there's been some back-and-forth with several methods for handling text input:

  * r8142 removed any handling of WM_CHAR because keyboard input was being handled through WM_KEYDOWN along with ToUnicode since r7645.

  * But using ToUnicode actually breaks dead-keys (googling for "ToUnicode dead keys" reports many horror stories of people trying to work around that and failing).

  * It seems like r7645 introduced a double-fix: it fixed WM_CHAR to properly handle Unicode, and also (unnecessarily?) added text input handling to WM_KEYDOWN. Later, r8142 removed the WM_CHAR stuff instead of the WM_KEYDOWN stuff.

The attached patch restores handling of text input through WM_CHAR and removes it from WM_KEYDOWN. I've tested it with French, English and Russian layouts and it seems to do its job. Obviously, with such matters, it's still a risky change.
Comment 1 yrizoud 2015-02-10 09:50:10 UTC 
*** Bug 2747 has been marked as a duplicate of this bug. ***
Comment 2 ensiform 2015-02-17 22:55:59 UTC 
Comment on attachment 1984 [details]
SDL_windowevents.c patch to fix dead keys

Shouldn't the conversion of the wParam in WM_CHAR be optional?
Comment 3 Elisée Maurer 2015-02-19 11:44:37 UTC 
Optional? Based on what?
Comment 4 ensiform 2015-02-19 14:13:13 UTC 
Well, for example the original jedi knight games pre-SDL used the raw wParam directly so that it could support other languages (Not full unicode) down the line.  And I'm not sure if translating them to utf8 here will break that or not.

https://github.com/JACoders/OpenJK/blob/master/codemp/win32/win_wndproc.cpp#L470
Comment 5 Elisée Maurer 2015-02-21 13:59:23 UTC 
Would any games developed with SDL2 still want to do anything other than Unicode these days? Maybe I didn't understand what you're suggesting.
Comment 6 ensiform 2015-02-21 14:32:55 UTC 
Of course there are, think of the many old games or source ports that use SDL.  They would still be using char not wchar_t for compatibility.
Comment 7 ensiform 2015-02-21 16:43:44 UTC 
Maybe it will still work, I'm not sure.  Just trying to keep the old compat with languages that the original JKA does support when this does get fixed in SDL2.
Comment 8 Elisée Maurer 2015-02-21 18:45:09 UTC 
Can you build SDL2 with the patch and try it with one of the games you think might break and report?

Or are you concerned about possible future SDL2 ports? If that's the case, then IMHO it's best to worry about that when those ports do happen. The porter can ship their own build of the library (like I'm doing until this patch lands) and submit another patch to make the conversion optional if it is indeed required, right? It'd be premature to add some kind of way to switch now if there's no confirmed use case.
Comment 9 ensiform 2015-02-22 03:26:35 UTC 
Unfortunately I will not be able to do so, going to be on vacation for next couple of weeks.  (I imagine this might be resolved by then?)  Even so, I don't actually have hg, so unless there's a git mirror of the most up to date main repo I probably wouldn't even be able to do so anyway.


Also, I am a US Keyboard user so I wouldn't be able to exactly test the Russian layouts etc other than windows-1252 alt codes.
Comment 10 ensiform 2015-03-11 14:45:40 UTC 
This does work in terms of fixing alt codes on Windows.

Needs slight modification with recent patch to check return value of the convert function.

I had someone say they still cannot input russian with it though. (We convert back to utf32 same as ioquake3)
Comment 11 Ryan C. Gordon 2015-04-07 04:57:58 UTC 
(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.
Comment 12 Sam Lantinga 2015-05-28 16:04:33 UTC 
Unicode text support has been fixed/broken so many times... This patch is how the code used to work, but there were bugs that caused us to change it to the current code.

After 2.0.4 is released, let's hammer this out once and for all.  We'll reopen all the Unicode text entry bugs, get everyone involved who can test it, and let them duke it out. :)
Comment 13 Sam Lantinga 2015-06-25 18:58:48 UTC 
Fixed, thanks!
http://hg.libsdl.org/SDL/rev/02273530b7bf

We tested Russian on Windows 7 and it worked here.

We'll have to come back to bug 1876 with Khmer in the future.