On a MacBook without a two-button mouse connected, Control-click was my preferred option to enact a right-click in Minecraft. The latest version of LWJGL apparently interprets Control-click as literally Control-click rather than right-click, and Minecraft's developers say this is a problem caused by LWJGL rather than Minecraft itself (they're only willing to detect the press of a single key, such as Control, rather than the modifier+click combination).

Please don't abandon Control-click as right-click yet; even if many people now use two-button mice, there are still a number of us who still use Control for this purpose. I've given up playing Minecraft since this change was implemented.

Upon quitting the LWJGL application, desktop refresh rate is forced to 60Hz. I can confirm this as a LWJGL issue because it occurs in both Minecraft and LibGDX desktop builds. I have only tested this with an NVIDIA card, but it occurs in both Windows 7 64bit and Linux based 64bit OSes using proprietary NVIDIA drivers.

A bug report was filed with mojang here: https://bugs.mojang.com/browse/MC-36746

On my Linux 3.7.0 (ant 1.8.2, gcc 4.7.2, openjdk 1.7.0_09) I'm getting a few compiling errors. On the first try a directory was missing:

sworddragon@ubuntu:~/.git/lwjgl$ ant compile_native Buildfile: /home/sworddragon/.git/lwjgl/build.xml

-initialize: [initialiazing bin folder] Created dir: /home/sworddragon/.git/lwjgl/bin [initialiazing native bin folder] Created dir: /home/sworddragon/.git/lwjgl/bin/lwjgl [initialiazing native OpenGL ES bin folder] Created dir: /home/sworddragon/.git/lwjgl/bin/lwjgles [initialiazing dist folder] Created dir: /home/sworddragon/.git/lwjgl/dist [initialiazing docs folder] Created dir: /home/sworddragon/.git/lwjgl/doc/javadoc [initialiazing temp folder] Created dir: /home/sworddragon/.git/lwjgl/temp [initialiazing temp/jar folder] Created dir: /home/sworddragon/.git/lwjgl/temp/jar [initialiazing temp/doc folder] Created dir: /home/sworddragon/.git/lwjgl/temp/doc [initialiazing temp/res folder] Created dir: /home/sworddragon/.git/lwjgl/temp/res [initialiazing temp/native folder] Created dir: /home/sworddragon/.git/lwjgl/temp/native [initialiazing temp/windows folder] Created dir: /home/sworddragon/.git/lwjgl/temp/native/windows [initialiazing temp/linux folder] Created dir: /home/sworddragon/.git/lwjgl/temp/native/linux [initialiazing temp/freebsd folder] Created dir: /home/sworddragon/.git/lwjgl/temp/native/freebsd [initialiazing temp/macosx folder] Created dir: /home/sworddragon/.git/lwjgl/temp/native/macosx [initialiazing temp/solaris folder] Created dir: /home/sworddragon/.git/lwjgl/temp/native/solaris

compile:

BUILD FAILED /home/sworddragon/.git/lwjgl/build.xml:450: srcdir "/home/sworddragon/.git/lwjgl/src/generated" does not exist!

Total time: 0 seconds

After creating the directory manually I got the next errors:

sworddragon@ubuntu:~/.git/lwjgl$ ant compile_native Buildfile: /home/sworddragon/.git/lwjgl/build.xml

-initialize:

compile: [core] Compiling 267 source files to /home/sworddragon/.git/lwjgl/bin [core] /home/sworddragon/.git/lwjgl/src/java/org/lwjgl/openal/EFXUtil.java:34: error: cannot find symbol [core] import static org.lwjgl.openal.AL10.*; [core] ^ [SNIP] - LOTS OF SAME ERRORS [core] 100 errors

BUILD FAILED /home/sworddragon/.git/lwjgl/build.xml:450: Compile failed; see the compiler error output for details.

Total time: 4 seconds

Playing the game Minecraft, moving forward with "w" key, if you click with any mouse button you stop moving even if holding "w" down. (or any movement key)

While in an inventory holding shift and then clicking normally can move an item to a different box. With 2.8.5 installed you have to try many times to get this to work.

Basically all keyboard keys seem to loose function or focus when clicking with the mouse.

I went back to 2.8.4 and had no issues at all.

I get the following exception when running any lwjgl application on this Lubuntu 14.04.02 Notebook.:

Exception in thread "LWJGL Application" java.lang.ExceptionInInitializerError
    at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setVSync(LwjglGraphics.java:446)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:118)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 0
    at org.lwjgl.opengl.LinuxDisplay.getAvailableDisplayModes(LinuxDisplay.java:954)
    at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:738)
    at org.lwjgl.opengl.Display.<clinit>(Display.java:138)

I traced the error to the xrandr parsing function but could not yet exactly pinpoint it.

Below is the output of xrandr. The offending lines are definitely the bottom ones with LVDS-1-1 connected. The laptop has 2 graphics card, I think this is probably the root cause:

$> lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV710/M92 [Mobility Radeon HD 4330/4350/4550]

$> xrandr -q
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 32767 x 32767
LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 310mm x 174mm
   1366x768       60.0*+
   1360x768       59.8     60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
VGA-1-1 disconnected
LVDS-1-1 connected
   1366x768       60.0 +
   1280x720       59.9  
   1152x768       59.8  
   1024x768       59.9  
   800x600        59.9  
   848x480        59.7  
   720x480        59.7  
   640x480        59.4  
HDMI-1-0 disconnected
  1366x768 (0x45)   75.1MHz
        h: width  1366 start 1414 end 1446 total 1564 skew    0 clock   48.0KHz
        v: height  768 start  771 end  776 total  800           clock   60.0Hz

I'm using Fedora 19 with openjdk-1.7.0.25 and the Gnome 3.8 desktop.

Using the new launcher, the "old" Minecraft 1.5.2 works fine in full screen mode, but the new 1.6.1 version just blinks when I hit F11 and stays tiny.

I updated to lwjgl 2.9 jars and natives and it didn't help.

Mojang suggests that this is a LWJGL bug and that it should be reported here. https://mojang.atlassian.net/browse/MC-19751

Some Linux desktop environments (e.g. GNOME Shell) use the X11 window class (set using the WM_CLASS hint) to determine the application's name and provide certain functionality based on that. In the case of GNOME Shell specifically, allowing the user to dock an application to the Dash and showing the correct name in Alt-Tab. (See also this.)

I would suggest adding a setWmClass() method to org.lwjgl.opengl.Display, and possibly setting WM_CLASS to be the same as the window title by default. The setWmClass method would be a stub on non-Linux platforms.

redirected from: https://mojang.atlassian.net/browse/MC-15142

Minecraft uses KeySym under linux to determine which key was pressed. KeySym by definition only has its value set correctly at keyPRESS - not keyRELEASE. To get the real values use the KeyCode. e.g. having de_de set as default layout yields (in xev):

KeyPress event, serial 40, synthetic NO, window 0x4600001, root 0xa9, subw 0x0, time 1668220, (670,378), root:(672,401), 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 40, synthetic NO, window 0x4600001, root 0xa9, subw 0x0, time 1668345, (616,314), root:(618,337), state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

but with de_neo you get:

KeyPress event, serial 40, synthetic NO, window 0x4600001, root 0xa9, subw 0x0, time 1722888, (608,465), root:(610,488), state 0x2000, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 40, synthetic NO, window 0x4600001, root 0xa9, subw 0x0, time 1723003, (608,465), root:(610,488), state 0x2001, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES, XKeysymToKeycode returns keycode: 66 XLookupString gives 0 bytes: XFilterEvent returns: False

(This Effect is a side-effect on having both shift-keys (pressed at the same time) act as Caps-Lock - but thats just a guess). A similar bug was reported to another application ( https://bugzilla.gnome.org/show_bug.cgi?id=683534#c7 ). Workaround: If you make de_de the default keyboard-layout and just switch to de_neo, minecraft uses the de_de-Keysym (in every menu - so you have wasd "set" for walking), but you still have neo in text-chat (thus having vuia as the keys you actually press for walking). Doing so, however, disables the Mod4-Switch making 2 of the 6 levels of the neo-layout (see http://www.neo-layout.org for reference) unusable. This will affect other layouts where similar behaviour is enforced, too.

Edit: To make the Mod4-Switch (at least AltGr) workable again i could add an override ("Key to choose 5th level" set to "Right Alt chooses 5th level, locks when pressed together with another 5th-level-chooser") in the keyboard settings under KDE. YMMV.

LWJGL-2.8.5 returned ö, ä, ü in Keyboard.getEventCharacter() when the corresponding keys have been pressed.

LWJGL-2.9.0 will still return the same keycode '39' in Keyboard.getEventKey() but Keyboard.getEventCharacter() is empty.

The LWJGL-2.9.1 nightly build #87 (12.08.2013 08:31:10) behaves the same and does not return these characters.

@Deprecated tag should be added to all GL bindings that explicitly state they are deprecated, and documented with @deprecated and the associated reason for deprecation.

I'm unable to play Minecraft correctly on my Mac using a Dvorak layout on the built-in Qwerty keyboard. I believe the issue is best described here: http://bit.ly/XuiFiO

I was directed to LWJGL from this comment by Mojang's developer in the comments: http://bit.ly/YLWNCc

When I am playing the game and in chat mode, everything works fine and I'm able to type in Dvorak, but when I try changing the game controls under OPTIONS | CONTROLS Minecraft is reporting the incorrect keys. For the default layout of "WADS" under Dvorak it should be ",AOE" but instead it's "WAOE". The game became unplayable for me when I tried to remap the keys to "ESDF" (which is ".OEU" in Dvorak) but Minecraft thinks the keys are "EOEU". Yes, there are two E's there for forward and back, so pressing forward moves the player backwards.

If you need a clearer explanation, I can make a short video demonstrating the problem.

Thanks,

Miles

Junior family member had knocked the cable just far enough out of the monitor to prevent xrandr showing anything useful, even though the system had booted and selected the resolution correctly, and everything was displaying as expected. But Minecraft refused to start, just never appeared. Eventually found this in the Minecraft log:

java.lang.ExceptionInInitializerError
        at ave.ar(SourceFile:560)
        at ave.am(SourceFile:361)
        at ave.a(SourceFile:310)
        at net.minecraft.client.main.Main.main(SourceFile:124)
Caused by: java.lang.NullPointerException
        at org.lwjgl.opengl.LinuxDisplay.getAvailableDisplayModes(LinuxDisplay.java:947)
        at org.lwjgl.opengl.LinuxDisplay.init(LinuxDisplay.java:738)
        at org.lwjgl.opengl.Display.<clinit>(Display.java:138)
        ... 4 more

Which led me to try xrandr:

$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
VGA-1 disconnected primary (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected 1920x1080+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
  1920x1080 (0x46) 148.500MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz

Eventually I gave up googling and checked the monitor cable... tightened it up, xrandr is happy and so is Minecraft (and the Minecraft player):

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+
   1600x1200     60.00  
   1680x1050     59.88  
   1400x1050     59.95  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   640x480       75.00    72.81    66.67    59.94  
   720x400       70.08  

This is Ubuntu 20.04, Minecraft is 1.8.9 and has loaded this lwjgl:

~/.minecraft/libraries/org/lwjgl/lwjgl/lwjgl/2.9.4-nightly-20150209/lwjgl-2.9.4-nightly-20150209.jar

OK, so this is an unlikely edge case on an old version and unlikely to get updated, maybe the newer code handles this better already, but maybe this report will help guide someone else hitting the same issue to resolve the problem much quicker than it's take me to!

And if it's possible to make future versions handle this error more gracefully, then so much the better.

I usually use Chinese for conversation, so I need to use the input method, but I found that I cannot switch the input method in minecraft. After looking up the code, I think I have located the problem

https://github.com/LWJGL/lwjgl/blob/2df01dd762e20ca0871edb75daf670ccacc89b60/src/native/linux/org_lwjgl_opengl_LinuxKeyboard.c#L87

The input method seems to be disabled here, but modifying this will cause minecraft to be unable to read keyboard input, and it is still impossible to switch the input method in the game, so there should be other places that need to be changed. What should I need to do?

LWJGL2 is used by Minecraft until version 1.13. Millions of players use versions prior to this weekly and are affected by this bug.

When using a high poll rate (tested with 1000), the values returned by Mouse.getDx() and Mouse.getDy() become invalid and do not represent the true state of how the mouse has moved. When moving smoothly, there will be random large single inputs that may dramatically move the cursor more than it should. These happen randomly and I have found no pattern that causes them. (Example https://youtu.be/FOsleZsyzWE). I did some further digging and this seems only to happen when the mouse is grabbed (Mouse.setGrabbed(true)). The root cause seems to be somewhere in native code but that's outside my skillset to push further

Hello. I am a RaspberryPi User.

I want liblwjgl64.so for Minecraft (<1.13). Is there any files?

PC Raspberry Pi 4 [4GB RAM] OS Official Raspberry Pi OS 64bit Architecture aarch64(but require arm64) Java Java8 Require liblwjgl64.so (and other require files) When try to use download pages file Please wait... I forgot COPY AND PASTE

I've confirmed this with two different people, their trackpad scrolling speed is set to the middle (default), and the problem goes away when using a regular mouse.

Example code snippet which can reproduce this:

https://github.com/kami-blue/client/blob/31e92d263c4027d3d9290dfba190ee170960d186/src/main/java/me/zeroeightsix/kami/gui/rgui/windows/ListWindow.kt#L152-L166