Why is this marked as “resolved”? It certainly is not. I can still reproduce this with Minecraft 1.4.7, Java 1.7.0_10 and lwjgl 2.9.0 (nightly build). Once I press shift, the game acts as if shift is permanently held down. F11 cures it, but that's hardly a solution.
This may be relevant: Using xev I see this when pressing the left shift key:
KeyPress event, serial 41, synthetic NO, window 0x4600001,
root 0x266, subw 0x0, time 517573511, (18,-15), root:(1391,37),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
And this is the event upon release of the same key:
KeyRelease event, serial 41, synthetic NO, window 0x4600001,
root 0x266, subw 0x0, time 517573823, (18,-15), root:(1391,37),
state 0x1, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Note how the keysym value differs. I suspect that somewhere in LWJGL and/or Minecraft there's the assumption that releasing a key will send the same keysym as pressing it. That's why the game never sees the shift key released.
I’ve been through all recent versions of lwjgl, no difference.
As for the issue being “resolved”, I don’t agree. Minecraft is the one big game using lwjgl, and the library comes bundled with the game. So, in effect any bug in lwjgl is a bug in Minecraft and it needs to be tracked down and resolved properly for the good of both projects.
… and the people over at LWJGL will tell you it's a problem with Minecraft, not LWJGL.
As I said before, it does not matter where the problem is located. As long as LWJGL comes bundled with Minecraft, it's a problem with Minecraft. Marking the issue as "resolved" (which is an outrage, really) will not make it go away.
So, the newest version of LWJGL is supposed to fix our problem? Well, today I thought I'd give it a try.
First stop, LWJGL’s repository for nightly builds. Got the most recent packet, put it in place, started Minecraft … got a crash. On closer inspection I found the Linux native library to be only a few hundred bytes in size. So, that’s a “successful build”?
Oh, well. I guess I can do this myself. So, I pulled the most recent version of LWJGL from GitHub and after some fiddling and installing of X header files got the whole thing to compile. In the process, I got this little tidbit:
[apply] /home/zarquod/misc/minecraft/lwjgl-git/src/native/linux/org_lwjgl_opengl_LinuxKeyboard.c: In function 'Java_org_lwjgl_opengl_LinuxKeyboard_keycodeToKeySym': [apply] /home/zarquod/misc/minecraft/lwjgl-git/src/native/linux/org_lwjgl_opengl_LinuxKeyboard.c:81:2: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations]
Could this be related? I don’t know.
Anyway, I installed my newly compiled LWJGL, started Minecraft and … no change. The Sticky Shift On Linux Bug is still there.
Looks like I’ve found … well, not a solution, but a pretty good workaround for the specific flavor of this issue that I am experiencing.
Reminder: Pressing and releasing the left shift key gave me this output from xev:
KeyPress event, serial 41, synthetic NO, window 0x4800001,
root 0x266, subw 0x0, time 7862258, (20,-11), root:(1124,41),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 41, synthetic NO, window 0x4800001,
root 0x266, subw 0x0, time 7862370, (20,-11), root:(1124,41),
state 0x1, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
So, the KeyPress event and the KeyRelease event come with different symbolic key names. I guess that’s where Minecraft and/or LWJGL messes up, games and similar realtime applications SHOULD NOT use symbolic key names, but the raw keycodes.
Anyway, this is where we can swing our pickaxe. Looking at the output from xmodmap -pke we find this:
As I read it, the KeyPress event occurs without any modifier, so the symbolic name is Shift_L. But releasing the key obviously happens while holding Shift (d’oh!), which is why it gets associated with Caps_Lock.
Now, this looks like it might be easy enough to fix. Just make a file modmap-fix with this content:
There’s nothing wrong with my setup, I’m using Neo2 layout, which does not have an explicit caps lock key but uses the shift keys (pressed simultaneously) to activate caps lock.
Why is this marked as “resolved”? It certainly is not. I can still reproduce this with Minecraft 1.4.7, Java 1.7.0_10 and lwjgl 2.9.0 (nightly build). Once I press shift, the game acts as if shift is permanently held down. F11 cures it, but that's hardly a solution.
This may be relevant: Using xev I see this when pressing the left shift key:
KeyPress event, serial 41, synthetic NO, window 0x4600001,
root 0x266, subw 0x0, time 517573511, (18,-15), root:(1391,37),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
And this is the event upon release of the same key:
KeyRelease event, serial 41, synthetic NO, window 0x4600001,
root 0x266, subw 0x0, time 517573823, (18,-15), root:(1391,37),
state 0x1, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
Note how the keysym value differs. I suspect that somewhere in LWJGL and/or Minecraft there's the assumption that releasing a key will send the same keysym as pressing it. That's why the game never sees the shift key released.
I’ve been through all recent versions of lwjgl, no difference.
As for the issue being “resolved”, I don’t agree. Minecraft is the one big game using lwjgl, and the library comes bundled with the game. So, in effect any bug in lwjgl is a bug in Minecraft and it needs to be tracked down and resolved properly for the good of both projects.
… and the people over at LWJGL will tell you it's a problem with Minecraft, not LWJGL.
As I said before, it does not matter where the problem is located. As long as LWJGL comes bundled with Minecraft, it's a problem with Minecraft. Marking the issue as "resolved" (which is an outrage, really) will not make it go away.
So, the newest version of LWJGL is supposed to fix our problem? Well, today I thought I'd give it a try.
First stop, LWJGL’s repository for nightly builds. Got the most recent packet, put it in place, started Minecraft … got a crash. On closer inspection I found the Linux native library to be only a few hundred bytes in size. So, that’s a “successful build”?
Oh, well. I guess I can do this myself. So, I pulled the most recent version of LWJGL from GitHub and after some fiddling and installing of X header files got the whole thing to compile. In the process, I got this little tidbit:
[apply] /home/zarquod/misc/minecraft/lwjgl-git/src/native/linux/org_lwjgl_opengl_LinuxKeyboard.c: In function 'Java_org_lwjgl_opengl_LinuxKeyboard_keycodeToKeySym':
[apply] /home/zarquod/misc/minecraft/lwjgl-git/src/native/linux/org_lwjgl_opengl_LinuxKeyboard.c:81:2: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations]
Could this be related? I don’t know.
Anyway, I installed my newly compiled LWJGL, started Minecraft and … no change. The Sticky Shift On Linux Bug is still there.
NOT RESOLVED
@Greg Fitzgerald: When I wrote “I’ve been through all recent versions of lwjgl, no difference.” that included the latest stable version, of course.
@Rolf Campbell: What link are you referring to?
@Rolf Campbell: So, you were effectively referring to http://www.newdawnsoftware.com/jenkins/view/LWJGL-git/job/LWJGL-git/label=winxp642/ and http://www.newdawnsoftware.com/jenkins/view/LWJGL-git/job/LWJGL-git/label=apollo/ ?
Those builds don’t even contain liblwjgl.so/liblwjgl64.so. None whatsoever, not even broken ones like the recent nightly builds.
Just for clarification, I’m talking about Sticky Shift on Linux, not Sticky Movement on Windows.
The JRE does not make a difference for me. I’m currently using Oracle’s implementation:
$ java -version
java version "1.7.0_17"
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
Source: https://launchpad.net/~webupd8team/+archive/java
Looks like I’ve found … well, not a solution, but a pretty good workaround for the specific flavor of this issue that I am experiencing.
Reminder: Pressing and releasing the left shift key gave me this output from xev:
KeyPress event, serial 41, synthetic NO, window 0x4800001, root 0x266, subw 0x0, time 7862258, (20,-11), root:(1124,41), state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 41, synthetic NO, window 0x4800001, root 0x266, subw 0x0, time 7862370, (20,-11), root:(1124,41), state 0x1, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: FalseSo, the KeyPress event and the KeyRelease event come with different symbolic key names. I guess that’s where Minecraft and/or LWJGL messes up, games and similar realtime applications SHOULD NOT use symbolic key names, but the raw keycodes.
Anyway, this is where we can swing our pickaxe. Looking at the output from xmodmap -pke we find this:
As I read it, the KeyPress event occurs without any modifier, so the symbolic name is Shift_L. But releasing the key obviously happens while holding Shift (d’oh!), which is why it gets associated with Caps_Lock.
Now, this looks like it might be easy enough to fix. Just make a file modmap-fix with this content:
Load it with xmodmap modmap-fix and the Sticky Shift problem in Minecraft is gone.
There’s nothing wrong with my setup, I’m using Neo2 layout, which does not have an explicit caps lock key but uses the shift keys (pressed simultaneously) to activate caps lock.