mojira.dev

Zarquod

Assigned

No issues.

Reported

No issues.

Comments

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.

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:

keycode  50 = Shift_L Caps_Lock Shift_L Caps_Lock
keycode  62 = Shift_R Caps_Lock Shift_R Caps_Lock

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:

keycode  50 = Shift_L Shift_L
keycode  62 = Shift_R Shift_R

Load it with xmodmap modmap-fix and the Sticky Shift problem in Minecraft is gone.

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

@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.

@Rolf Campbell: What link are you referring to?

@Greg Fitzgerald: When I wrote “I’ve been through all recent versions of lwjgl, no difference.” that included the latest stable version, of course.

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

… 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.

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.

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.