Newt, wrong keycode for # key?

Hello, I work on a team that uses JOGL and Newt for a Java game.
We received a report from players about the key bindings having issues with the “#” key, it registers as a backslash with the keybind system. At first we thought it was maybe down to keyboard layout but after testing it became clear the problem is not caused by the layout and only affects Newt (keycode correctly returns 520 in AWT).

I put together a simple Newt test application with a basic KeyListener:

public class TestKeyListener implements KeyListener {
        @Override
        public void keyReleased(KeyEvent e) {}

        @Override
        public void keyPressed(KeyEvent e) {
                System.out.println("keyCode: " + e.getKeyCode() + ", keyChar: "+ e.getKeyChar() + ", modifiers: " + e.getModifiers() + ", keySymbol: " + e.getKeySymbol());
        }
}

I then tried it on a couple of different machines (Windows 7 and Mac OS X Yosemite) to check it wasn't a problem with one specific platform. The result for the “#” key always returned:

keyCode: 92, keyChar: #, modifiers: 0, keySymbol: 39

The character is correct but keyCode 92 matches VK_BACK_SLASH (0x5C). The VK_NUMBER_SIGN (0x23) is hard defined 35 so the result this really doesn't seem to make sense, even the keySymbol if that was intended to be used instead doesn't match up.
On the flip side backslash (like most keys) behaves correctly:

keyCode: 92, keyChar: \, modifiers: 0, keySymbol: 92

I traced it as far back as I could with the Eclipse debugger on a Windows machine, it comes through from the native side to WindowDriver.sendKeyEvent(short, int, short, short, char) with keyCode 92 already.
I've not seen a bug report for it so I'm unsure if this behaviour is intentional but it seems a strange thing to chose to do.

Hi

Please make a bug report.

NEWT is designed to map KeyChar to Unicode as close as possible
The keyCode mapping follows a US/ANSI mechanical keyboard layout by design in order to have the same physical key position mapping on all systems. [1]

keyCode 92 in decimal is thus mapped to keyChar unicode UTF-16 0xC5 \ [2]

if you use a non US/ANSI keyboard, lets pretend you use a UK/ISO keyboard layout and press the key labeled in UK # (located close to return)
then NEWT will give you the US/ANSI keySymbol: 39 because that maps to UTF-16 0x27 '
on the US/ANSI keyboard # is located on the 3 digit key.
The US/ANSI Keyboard layout looks like this:
http://en.wikipedia.org/wiki/Keyboard_layout#mediaviewer/File:ANSI_Keyboard_Layout_Diagram_with_Form_Factor.svg

There exist three major mechanical keyboard maps ANSI, ISO and JIS
NEWT is currently designed to return ANSI keyCodes for all keyboards.
This is a ANSI to ISO and ANSI to JIS mechanical key map problem. [3]

I do not think the operating system can detect the mechanical keyboard map because the keyboard do not know what kind of mechanical map it is or what is printed on the keys.
This is the reason why operating systems have to ask the user for the mechanical and national layout during os installation.

[1] https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/com/jogamp/newt/event/KeyEvent.html
[2] http://www.unicode.org/charts/PDF/U0000.pdf
[3] http://en.wikipedia.org/wiki/Keyboard_layout#Mechanical.2C_visual_and_functional_layouts

Cheers
Xerxes

Hello, I work on a team that uses JOGL and Newt for a Java game.
We received a report from players about the key bindings having issues with the “#” key, it registers as a backslash with the keybind system. At first we thought it was maybe down to keyboard layout but after testing it became clear the problem is not caused by the layout and only affects Newt (keycode correctly returns 520 in AWT).

I put together a simple Newt test application with a basic KeyListener:

public class TestKeyListener implements KeyListener {
        @Override
        public void keyReleased(KeyEvent e) {}

        @Override
        public void keyPressed(KeyEvent e) {
                System.out.println("keyCode: " + e.getKeyCode() + ", keyChar: "+ e.getKeyChar() + ", modifiers: " + e.getModifiers() + ", keySymbol: " + e.getKeySymbol());
        }
}

I then tried it on a couple of different machines (Windows 7 and Mac OS X Yosemite) to check it wasn't a problem with one specific platform. The result for the “#” key always returned:

keyCode: 92, keyChar: #, modifiers: 0, keySymbol: 39

The character is correct but keyCode 92 matches VK_BACK_SLASH (0x5C). The VK_NUMBER_SIGN (0x23) is hard defined 35 so the result this really doesn't seem to make sense, even the keySymbol if that was intended to be used instead doesn't match up.
On the flip side backslash (like most keys) behaves correctly:

keyCode: 92, keyChar: \, modifiers: 0, keySymbol: 92

are you sure that both US/ANSI ' and \ key returned keyCode 92?
if that is the case then that is a bug.

I traced it as far back as I could with the Eclipse debugger on a Windows machine, it comes through from the native side to WindowDriver.sendKeyEvent(short, int, short, short, char) with keyCode 92 already.
I've not seen a bug report for it so I'm unsure if this behaviour is intentional but it seems a strange thing to chose to do.

---

If you reply to this email, your message will be added to the discussion below:

http://forum.jogamp.org/Newt-wrong-keycode-for-key-tp4033690.html

To start a new topic under jogl, email [hidden email]
To unsubscribe from jogamp, click here.
NAML

Thank you for the explanation, the keyCode behaviour makes more sense now.
I'm not completely clued up on keyboard layouts so didn't want to jump to calling it a bug. We work with UK/ISO keyboards which I probably should have mentioned. The US/ANSI layout explains why most haven't had an issue (besides that fact it's usually an awkwardly located key on a UK keyboard anyway).
It sounds like the keySymbol would be a better choice for us to use for key bindings when the application is running in Newt.

This page is a good resource how scan codes map and differs by comparing
U.S. 101-key keyboard, the international 102-key keyboard, the Japanese 106-key keyboard and USB keyboard scancodes.
http://www.quadibloc.com/comp/scan.htm

Inside JogAmp NEWT we try to abstract the complexity of the currently in use legacy scancode standards by mapping all scancode variants to unicode UTF-16 and we hope that in the future a new keyboard standard will emerge where keyboards will send unicode UTF-16 scancodes directly.