Unsupported keys with foreign keyboard on Linux
I'm using a french keyboard (azerty layout). Now that the hotbar can finally be used thanks to the new keybinding menu, I changed controls to fit my keyboard. But some keys are displayed as "NONE" in the menu and do not work correctly in game.
&, é,", (, è, ç are reported as "NONE"
', -, _ work fine
When pressing one of the NONE key, the game switch to the last slot (bound to ç). I guess the game consider all these keys to be the same and use the last action bound to this key.
Some other keys have the same issue but I cannot be exhaustive :
), $, *, ^, ù, !, <
^ is a dead key and must be typed twice.
Environment
Fedora 19 64bits
java version "1.7.0_60"
OpenJDK Runtime Environment (fedora-2.4.2.0.fc19-x86_64)
OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode)
Linked Issues
relates to4
MC-6436Incomplete support of dead keys on non U.S. QWERTY Keyboard on OS XFixedMC-72856Control settings uses partwise US keyboard layout (on German keyboard layout)FixedMC-109376Unsupported keys in inventory with foreign keyboard on LinuxFixedMC-2781Chinese, Japanese and Korean (and probably other IME entered languages) characters not working (fixed for Windows)Fixed
Created Issue:
Unsupported keys with foreign keyboard on Linux
I'm using a french keyboard (azerty layout). Now that the hotbar can finally be used thanks to the new keybinding menu, I changed controls to fit my keyboard. But some keys are displayed as "NONE" in the menu and do not work correctly in game.
&, é,", (, è, ç are reported as "NONE"
', -, _ work fineWhen pressing one of the NONE key, the game switch to the last slot (bound to ç). I guess the game consider all these keys to be the same and use the last action bound to this key.
Some other keys have the same issue but I cannot be exhaustive :
), $, *, ^, ù, !, <
^ is a dead key and must be typed twice.Environment
Fedora 19 64bits
java version "1.7.0_60"
OpenJDK Runtime Environment (fedora-2.4.2.0.fc19-x86_64)
OpenJDK 64-Bit Server VM (build 24.0-b56, mixed mode)
relates to
![[Mod] Torabi](../../../data/assets/gravatar/torabi.png){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
relates to
An in-game composition window would be preferable, but if external floating windows are what foreign language users are used to, in Minecraft or other software, then it may not be as much of a problem as [Mojang] Grum (Erik Broes) believes it to be.
There's an interesting comment here about the use of getEventKey(), specifically that the LWJGL documentation recommends this instead:
(Keyboard.getEventKey()==Keyboard.KEY_NULL) ? Keyboard.getEventCharacter() : Keyboard.getEventKey()
The same information is present on issue 59 at the LWJGL bug tracker. This may also fix the issue of Minecraft ignoring keyboard input when an IME is enabled.
The comments in MC-30704 contain some more information and code to fix the problem for other non-English keys, and may also fix this issue as well.
In MCP 1.8 it seems to be a LWJGL issue. It returns for example for "ß" an event key value which is greater than 0.
See also:
I am really sorry if this is a duplicate 
How to reproduce (I think you have to use a German keyboard layout):
- Open the control settings
- Change a key for a action (example: Left) to for example "ä"
Affected keys:
- ^
- AltGr
- ß
- ´
- #
- +
- ä
- ü
- ö
Even some of the keys works later, for example AltGr doesn't:
It sets the used key to LeftControl, but later no matter if I press LeftControl or AltGr the action assigned to AltGr will be performed
Why this is only partwise maybe the US layout:
- Using Z or Y works correct, even they are switched on the US layout
- Pressing Strg (=Left Control) works, but AltGr gets also to LeftControl
Note:
- "Open Command" is default assigned to "Slash" however "Slash" is with the same layout "#" on the German keyboard. This means pressing "#" opens the chat and lets you enter a command
In older versions of the game, some keys were not usable in controls on certain layouts. MC-30704 addressed this issue, and now those keys can be selected as desired. However, in the inventory screen, those keys that were unselectable before still cannot be used to shift items directly into a hotbar slot.
Example: in my layout, the following keys occur where 1-9 appear on Qwerty: &[{(+=*)}. Despite mapping these keys to hotbar 1-9 in controls, and these keys working correctly to select the hotbar slot ingame, most cannot be used to quickly move items in the inventory screen.
I'm using a French Keyboard (azerty). On an Azerty layout, we have to press shift and the key to type the numbers. That's annoying so I changed the keybinding in the control settings to fit my keyboard.
It's working great in-game but when you want to use those shortcuts in the inventory, only the 4( ' ), 6( - ) and 8( _ ) are working.
This bug is probably related to MC-30704. I supposed they thought they fixed it but their fix doesn't work in the inventory
I have the same problem with a Belgian (azerty) keyboard on Linux Ubuntu (not tested on Windows).
When we use the number keys above the letters, by default, symbols are printed instead of numbers (it's a normal behaviour for azerty keyboards).
To actually print a number, we have to press SHIFT (it works in Minecraft, but also triggers the action assigned to SHIFT).
The symbols for these keys on a Belgian keyboard are (from 1 to 0) : &, é, ", ', (, §, è, !, ç, à
Except for the apostrophe, trying to use these keys in the configuration menu returns "NONE".
Except for the §, all these keys work in the chat.
This seems related with this issue from LWJGL : http://lwjgl.org/forum/index.php?topic=3950.0
Is this still a concern in the current Minecraft version 1.7.2 / Launcher version 1.3.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
I can confirm this problem using Minecraft 1.7.4 / Launcher version 1.3.7 but not with the french/belgian keyboard, instead I've got this problem on a german keyboard with the keys:
ö, ä, ü, #, +, ß, ', ^ and <.
I tested this manually, for these keys LWJGL doesn't output any KeyCode, and I even investigated LWJGL's java source:
The problem is neither in Minecraft nor in the Java-part of LWJGL, instead it has to be anywhere between the Kernel and LWJGL's C parts.
This is IMHO a bug in minecraft that also affects the windows version.
The lwjgl bugtracker tells why: https://github.com/LWJGL/lwjgl/issues/59
Edit: Bug still present in Minecraft 1.7.4 with launcher 1.3.7.
I've created a fix for everyone using forge in 1.6.4, the same changes could be applied to vanilla minecraft.
This should be enough to fix the problem for forge users.
Mojang, please implement this!
Still a concern in 14w08a.
Also note that the characters cited here correspond to only three keyboard layouts, from only three language, and only for the numeric keys of the keyboard. It can almost be anything depending on that layout, and there is at least a dozen of layouts for every language, and the player is actually free to bind keys which aren't even amongst the numeric ones.
To put it simply, the game needs to support any possible character, not only ASCII ones.
I use QWERTY, Swedish keyboard layout. Is this related to the actual keyboard layout? I thought it was just binding "special keys" on GNU/Linux.
Is there, on GNU/Linux, keyboard layouts that works correctly?
Oh, you're right, the game doesn't actually bind char codes but key codes to the control, therefore not changing depending on your layout (which is also a problem, in my opinion. If I have a qwerty layout on my azerty keyboard, I expect the game, as any other software, to recognise the qwerty layout. But it's a problem that many game engines share so I'm pretty sure it's way harder to fix than it seems, and since Minecraft allows us to rebind the keys, it's not even needed. But I digress.) So, my bad, that's not a layout problem.
However, those layouts are based on real keyboard configurations, so it's pretty much the same. There has to be other keyboards than the three cited here.
OK, so I tested something. I use "setxkbmap se", which makes the key bind to NONE when I try to bind "special keys". If I run "setxkbmap us", to change to US keyboard layout, the keymapping works as intended. It works. The problem is certain keyboard layouts, like Swedish or Danish which also tried.. Not sure how to solve that... :/
I also have this problem on 1.7.9.
Linux as on Windows, when I press an "eccentric" key (é, è, ê, etc.), The key is recognized as NONE.
On Linux, the key does not then simply works.
Windows and all the "eccentric" keys are considered by the game as identical (eg é and è are the same).
I've played around with this today, the snapshot might have a 'fix' for the miss behavior. It will still name some keys wrongly though.
14w34c looks good here on Linux with german umlauts. It is now possible to bind those keys and the displayed name is correct.
Thanks! (Fun fact: there is another minecraft linux bug where LWJGL has been blamed initially:
MC-55045)14w34c fixes it for my french keyboard. Key names are correct (it is better than Windows on that point, now).
There is still a problem with the dead key ^: I have to press it twice, both in the option menu and in game.
I have no idea what you mean with 'dead key ^:'.
Right now if there was no eventKey given by LWJGL we use the character code generated. These are absolutely not unique (in other words, they might change when you hold modifier keys) but it's about the best that can be done.
A dead key is a key that does not write a character, but it modifies the next character. For example typing ^, then e, writes ê.
I don't really know lwjgl works, but I think it should be handled with a key code rather than a character code. Like the modifier keys (ctrl, alt, shift, ...) do not have associated characters but work fine.
Also, while in game, pressing ^ change the behaviour of the next non-modifier key :
– for actions that last for the time the key is pressed (like moving), the action starts with a delay (waiting for a repeat event ?).
– for other actions (quick slot, inventory, ...), the action is completely ignored.
It may come from a limitation of lwjgl as I have seen a lot of software having issues with this key.
It looks like a lwjgl bug. I wrote a short test program :
Pressing ^ twice, gives the output:
Edit: This method outputs NONE key for the key I reported in the first message. Now, I understand what you mean by "no eventKey given by LWJGL".
Edit2: I posted a bug report on the LWJGL forum : http://lwjgl.org/forum/index.php/topic,5477.msg28937.html