[FIXED] Right shift key gets stuck being reported as "down"

Started by avm1979, October 19, 2013, 17:31:17

Previous topic - Next topic

spasi

Quote from: FlukeFan on January 05, 2015, 20:50:59I think the 'release' of the two shift keys needs to be almost simultaneous.

That's a pretty good hint actually. Could you change the code to:

if ( isKeyDown(Keyboard.KEY_LSHIFT) && !isKeyPressedAsync(WindowsKeycodes.VK_LSHIFT) )
	handleKey(WindowsKeycodes.VK_SHIFT, Keyboard.KEY_LSHIFT, false, (byte)0, 0L, false);
else if ( isKeyDown(Keyboard.KEY_RSHIFT) && !isKeyPressedAsync(WindowsKeycodes.VK_RSHIFT) )
	handleKey(WindowsKeycodes.VK_SHIFT, Keyboard.KEY_RSHIFT, false, (byte)0, 0L, false);

and try again?

FlukeFan

Hi,

I tried that, but I'm still seeing the same behaviour.  :-(

I don't know if this helps at all, but once the bug occurs, if I switch to another window (say Eclipse, or any other app) without touching the keyboard, Windows seems to think the shift is still down too (my mouse starts selecting text, rather than just moving the pointer).

Cornix

Have you tried updating your drivers? Maybe its a hardware fault.

FlukeFan

Hi,

Ok, I've managed to reproduce this in Notepad alone, so it looks like a hardware problem (if I press/release both shift keys then press a letter, every 10th (or so) is capitalised).  I'm amazed, because I've never seen any other problems with this (Dell) laptop's keyboard.

I'm really sorry for wasting everyone's time.  Thanks for all your help.

Richard

cursorcorner

This issue is reproducible in many API's and many programs. It is not an issue with the hardware, but appears to be an issue with ambiguity in W3C DOM keyboard event handling standard. The only legal types that the standard allows for are left, right, number pad and standard. This leaves ambiguity in how API's are expected to handle the same key code with multiple simultaneous key positions.

On a 2012 Macbook Pro running Yosemite 10, I am also seeing the left/right shift stuck-key behavior. This issue also exists for left/right alt and ctrl keys. The issue is easily reproduced by holding the left key, then the right, then releasing the left and finally the right for any of types mentioned.

AWT correctly alerts that one of the two (either left or right) is released via the event handler leaving the other in what might be interpreted as a stuck state by applications that try to distinguish left and right keys, but LWJGL does not report that either has been released for some reason. This is why the key is sometimes still reported as "pressed." I also saw this issue in Windows 7.

The mentioned issue is why many games refuse to distinguish left and right action-keys even though the hardware is capable of distinguishing them. The only Java API I have seen that is capable of directly accessing the left/right action key states so far is jnativehook, but it shows the simultaneous selection of left and right action keys as a modifier change only and not as an event.

If this issue can be fixed in LWJGL, I would choose it over AWT. I can also do some digging in the code to see if I find anything.

Sample code:

import org.lwjgl.LWJGLException;
import org.lwjgl.input.Keyboard;
import org.lwjgl.opengl.Display;
import org.lwjgl.opengl.DisplayMode;

public class InputSampler {

    public void start() {
        try {
           Display.setDisplayMode(new DisplayMode(800, 600));
           Display.create();
       } catch (LWJGLException e) {
           e.printStackTrace();
           System.exit(0);
       }
        while (!Display.isCloseRequested()) {
        pollInput();
        Display.update();
    }

    Display.destroy();
    }

    public void pollInput() {
         
       while( Keyboard.next() ) {
           if( Keyboard.getEventKeyState() ) {
              System.out.print(Keyboard.getKeyName(Keyboard.getEventKey()));
              System.out.println(" pressed");
          } else {
              System.out.print(Keyboard.getKeyName(Keyboard.getEventKey()));
              System.out.println(" released");
           }
       }

    }

    public static void main(String[] argv) {
        InputSampler inputExample = new InputSampler();
        inputExample.start();
    }

}

FlukeFan

I managed to replicate this in Notepad.  I don't think any API that runs on top of the operating system will be able to avoid this?

spasi

Quote from: cursorcorner on May 24, 2015, 21:12:21If this issue can be fixed in LWJGL, I would choose it over AWT. I can also do some digging in the code to see if I find anything.

I cannot reproduce what you describe, on either Windows or OS X. I used both your code above and other LWJGL tests.

Have you tried LWJGL 3 on the same machines?