FS#1272 FS#4039 FS#3865 FS#3016 FS#2686 FS#2729 FS#4056 There are ~20 more tickets for this bug, meaning this is about the hottest issue in the Bugtracker. Example when pressing Ü, Ö, Ä on QWERTZ layout: Code: [23:03:36.703] INFO no keycode mapping for SDL_Keycode 246 [23:03:38.812] INFO no keycode mapping for SDL_Keycode 252 [23:03:38.375] INFO no keycode mapping for SDL_Keycode 228 Example when pressing mousebuttons 4 and 5 on a standard mouse with back/forth buttons: Code: [23:02:27.062] ERROR Unknown mouse button: 4 [23:02:28.812] ERROR Unknown mouse button: 5 You might not know what these keycodes mean. But that doesn't mean you shouldn't map them anyway! Given the number of bug reports (above were only the ones which were NOT already been closed as duplicates), and the fact that about 100% of the European userbase is NOT using QWERTY layout (leave alone Mac or DVORAK users), should be motivation enough to allow mapping of ALL keycodes. But that's not all. Part of the keycode mapping is just plain wrong, even for keys which are being mapped. E.g. pressing "#" on a QWERTZ keyboard is recorded as "end", "^" is recorded as "`". Surprisingly "z" is recorded as "z". This, however, is unrelated from not mapping the key codes at all, using SDL_GetKeyName should solve that. EDIT: Oh great... You are relying on Mousetrap to resolve key codes into key names. That library has no support for alternate keyboard layouts, as key codes are hard mapped to layout specific names! You are not going to get around using SDL_GetKeyName which is aware of the keyboard layout. Sidenote: Please get rid of _SHIFT_MAP immediately, that one is actually causing ERRORS! E.g. like remapping "+" to "=", whereby "+" is actually a different key which does exist physically, even on QWERTY. And on QWERTZ layout, "+" and "=" are never even on the same key. That list ONLY ever works for pure QWERTY layouts. _KEYCODE_MAP is the one which is broken as it is unwarare of the keys true names. Static list can not bet used in this use case, since almost none of these codes work on anything except for QWERTY. And these are not the only issues with this library, it also makes a lot of other assumptions which are VERY specific towards the default 105 keys QWERTY layout. It even does really nasty stuff, like hard mapping NUMPAD to digits 0-9, making it impossible to use the numpad for separate shortcuts. So much for the issues with the unnatural mappings. PS: Have fun. Handling of keyboard events for layouts which have keys for non-ASCII letters is utterly broken in Chromium and possible also in Coherent Prepare to encounter double mapped KeyCodes (e.g. "_" and "-" both produce KeyCode 189 with Azerty but are physically different keys), key events which entirely lack KeyCode (like the ones on QWERTZ causing the SDL info), and more fun stuff.
Tried to tackle the issue on my own: No success. Javascript handling of keyboard event is even more broken than I could have imagined. No cross-browser consistent handling of ANYTHING except for alphanumeric keys in the main section of an 105 keys US QWERTY keyboard. 4 different API versions out there, and not a single browser implements only a SINGLE one completely. Even with the latest API draft, you still can't identify which key was actually pressed. At least you could map the key pressed to a printable representation - but no browser supports that API draft yet. This article sums it up rather well: http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/ Handling of input sequences with Mousetrap is "nice". But it can't help that keyboards events as "standardized" by W3 consortium are a bloody mess, and that Coherent doesn't offer a working solution of its own, either.
I suppose keyboard input won't be handled by Coherent, but SDL2 instead. It's likely should catch keyboard input, convert it to something game can understand and only then pass to Coherent.
Just my thoughts. Using the standard UI events as defined by W3C will just not work. Either have the Coherent team extend these events so they contain at least a working set of attributes (screw W3C conformity, the specified APIs are not suitable) , or just bypass this system entirely.
Any dev feedback on this? Some smart idea how the additional keys of an QWERTZ (or different) layout keyboard could be made accessible? Or at least an idea how to fix that broken shift remapping which causes keys, which are unrelated on other layouts, to get mapped together?
Before they changed the options to be "press the button you want to use now" from "write the char that should trigger it here" keys like öäü worked fine, even with mousetrap. So I'd say the only issue is the options screen that is too stupid to detect non qwerty keys. Make it have a textfield again where you just enter a string that is then bound using mousetrap.
Don't think so. That SDL_Keycode error indicates that these keys don't cause keyboard events in Javascript at all. Even before, Mousetrap couldn't capture them as keydown events, only as regular keypress events by charcode rather than keycode, which also has some other issues like the effect of modifier keys. (e.g. these keys would never have worked when shift or altgr was pressed!)
Yes, it worked partly. But it didn't worked with modifier keys, e.g. "shift+a" worked (and still does, since this always fired a keydown event which had keycode set), but "shift+ä" was impossible (keycode on keydown is constant 0 for all unknown keys, only charcode is set on keypress events, which then results in "Ä". Fallback to charcode if keycode isn't set is default Mousetrap behavior), only pure "ä" worked and only if capslock wasn't active. And now that probably some SDL update broke the mapping entirely, it's no longer producing any keyboard event at all.
