Keyboard not responding since update to 1.0 beta3

[elias]

Another thing - are you using JInput or similar, accessing directinput outside of LWJGL?

- elias

[Nop]

So far, I have precise information from two users having the problem:

Win 98 4.10 build 2222
DirectX 9.0c 4.09.0000.0904

Win 98 4.10 build 2222 A
4.09.0000.0904 (DirectX 9.0c)

All users did not change their system configuration except for updating my client software. My client did not contain any changes in the keyboard code, just the upgrade of the lwjgl libs.

[elias]

Ok, they should work fine with the directinput8 input methods of LWJGL, so I'm out of ideas, really :/ (I assume you've already tried -Dorg.lwjgl.util.Debug=true and checking any debug output to see if there's anything suspicious there) If you want to move forward on this issue, I see two possibilities:

1. Do a binary search on the LWJGL version, that is, try the LWJGL version "1.0beta", and if that works, "1.0beta2", until we know which version that broke input for you.
2. Go with my hunch and disable the directinput8 path:

Change:

   private static WindowsDirectInput createDirectInput() throws LWJGLException {
        try {
            return new WindowsDirectInput8(getDllInstance());
        } catch (LWJGLException e) {
            LWJGLUtil.log("Failed to create DirectInput 8 interface, falling back to DirectInput 3");
            return new WindowsDirectInput3(getDllInstance());
        }
    }

in WindowsDisplay.java to:

   private static WindowsDirectInput createDirectInput() throws LWJGLException {
            return new WindowsDirectInput3(getDllInstance());
    }

[Nop]

I have gotten some players to run a client with the debug flag enabled. Here is the result:

Illarion Client V0.98astarted Sat Oct 21 00:04:28 BST 2006
Initial mode: 1152 x 864 x 32 @0Hz
Found 30 displaymodes
Removed 0 duplicate displaymodes
Found mouse object: X-axis
Found mouse object: Y-axis
Found mouse object: Wheel
Found mouse object: Button 0
Found mouse object: Button 1
Found mouse object: Button 2
Mouse buffer overflowed

That is all, nothing else. And it is the same for every player.

Can it be the mousebuffer message? But the mouse is working for all of them.

Is there anything I can do about the mouse buffer?

[elias]

The mouse buffer message is normal, and can be ignored. I did a memory corruption fix (in SVN), which could theoretically cause all sorts of trouble. But it's very hard to trigger, so I'm not sure you are affected by this. Other than trying the current SVN version, I need you to do the binary search of the offending version and/or the dinput8->dinput3 fallback.

- elias

[Nop]

Ok, we have started the binary search. For a start I have reverted back to LWJGL 0.98. I have the first positive feedback that keyboard input works again with that version of the lib and the latest version of my code. I'm waiting for the feedback of some more people, then I am going to step up through the versions. Any bets which one it is going to be? :-)

[elias]

I'm guessing the version that introduced dinput8 support. Not sure if that was introduced in beta 3 or beta2.

- elias

[Nop]

I have moved to LWJGL 0.99 now. While the I/O works, for one player an unrelated problem has popped up. This is the log:

Initial mode: 1024 x 768 x 32 @0Hz
Exception occurred while querying registry: org.lwjgl.LWJGLException: Failed to open registry key
java.lang.NullPointerException
at org.lwjgl.opengl.Win32Display.nGetVersion(Native Method)
at org.lwjgl.opengl.Win32Display.getVersion(Win32Display.java:83)
at org.lwjgl.opengl.Display.getVersion(Display.java:826)

Any hint what's the problem here?

[elias]

It's a known bug with Display.getVersion()/getAdapter(), which is fixed (possibly only in SVN). You can work around it by catching the NPE and treating the value as null. Sorry for the inconvenience.

- elias

[Nop]

Can you tell me what causes this problem? Two players are having this problem, but when I start the same version, updated in the same manner, it runs fine.

[elias]

It's caused by a failure to read the registry key with the display adapter information. When it succeeds (on your machine) the bug is not triggered. The fix was a simple null check.

- elias

[Nop]

We have nailed down the problem. Everything is working fine up to V1.0 beta 1.

After update to V1.0 beta2 the keyboard is no longer working properly for Win 98 SE. F-keys, cursor keys and Alt-Shift-Ctrl do work, but letters do not.

I think your guess was correct. Now what can we do to solve the problem?

[elias]

Excellent. A quick check reveals that beta2 was the release that introduced dinput8 support (for jinput compatibility). The release also moved the input stuff from native to java. If my guess is correct, we'll need to disable dinput8 and test without it. Can you svn checkout the beta3 version (we fumbled the beta2 tag in SVN):

https://svn.sourceforge.net/svnroot/java-game-lib/tags/lwjgl1.0beta3

or the latest HEAD:

https://svn.sourceforge.net/svnroot/java-game-lib/trunk/LWJGL

and change src/jav/org/lwjgl/WindowsDisplay.java:

from:

   static WindowsDirectInput createDirectInput() throws LWJGLException {
        try {
            return new WindowsDirectInput8(getDllInstance());
        } catch (LWJGLException e) {
            LWJGLUtil.log("Failed to create DirectInput 8 interface, falling back to DirectInput 3");
            return new WindowsDirectInput3(getDllInstance());
        }
    }

to

   static WindowsDirectInput createDirectInput() throws LWJGLException {
            LWJGLUtil.log("Falling back to DirectInput 3");
            return new WindowsDirectInput3(getDllInstance());
    }

thus only using dinput3 everywhere. It should be equivalent to dinput8, except that jinput will not work with LWJGL. Rebuild lwjgl.jar and re-use the lwjgl.dll from beta3 (or one built freshly off HEAD).

If that fix works, I'll make sure dinput3 is always used on win9x machines.

Please reply if you have any doubts, or reach me on msn at: elias_naurAThotmail.com

- elias

[Nop]

I have done this, but it did not work. I changed the source to DirectX3 only and used that lwjgl.jar with the beta3 binaries. The no typing problem persists with this version.

Any more ideas?

[elias]

I finally got hold of a Win98 SE machine, to try and reproduce the bug. However, I can't reproduce what I think you specify as the bug, but I can reproduce the bug I fixed in HEAD that makes Keyboard.getEventCharacter() fail on (some?) win9x platforms. Your original code snippet does not contain getEventCharacter(), but the way you explain that the Function keys and the arrow keys work, makes me suspect that maybe it's not really getEventKey() that fails, but getEventCharacter instead.

So, I'd like to know exactly which method you use for "typing" that fails on Win98 SE - is it Keyboard.getEventKey() or Keyboard.getEventCharacter()? Note that I mean character input, not arrow keys, function keys and the escape key (which can only be queryed through getEventKey()). In fact, my question could be posed as: Do you use Keyboard.getEventCharacter() at all in your project?

- elias