GIVEUP is triggered when a Multimedia key is pressed. [LWJGL Input] about nullpomino HOT 12 CLOSED

which version? (slick/sdl/swing?)
do your logs says anything interesting?

For singleplayer modes I have the same problem (r618), regarding the volume 
control keys.
When I am in a game mode (play matrix), at any time when one of these 6 keys is 
pressed (volume +/-, mute, etc.), nullpo jumps back to the main menu screen.

I'm using a normal Cherry eVolution STREAM keyboard, which has no special keys 
apart from the volume and player control keys, which work natively with windows 
(and almost all applications/mediaplayers know how to handle them nowadays by 
default). These keys do not need any special multimedia key drivers or similar, 
i.e. the keyboard uses the default HID keyboard Device Driver in Win7 x64.

I'm not sure what the exact keycode is that gets sent when pressing one of 
those keys - a quick google search didn't turn up much. I could try to get the 
exact key codes with a little dummy application, if this can't be replicated by 
any of the devs due to missing hardware.

I tried using the keys in the control assignment page in nullpo, since it 
apparently listens for those special keys. When pressing any of the 6 keys it 
shows "EQUAL" as the assigned value.

we just discovered by accident that use of these media keys triggers a very 
nasty resource bug (thx Rosti), this could be reproduced on two machines:

1. start any single player mode
2. press one of these default multimedia keys (volume +/- etc., most laptops 
have Fn+key combinations for them. this might be vendor specific tho, how those 
are handled)
3. you get kicked back to the main menu, choose netplay
4. observe CPU usage and MEM usage, both explode

CPU usage = 100% (or one full core, in my case 25%)
memory use increases ultra fast, on my machine it reached 2GB+ RAM usage in a 
couple seconds after choosing netplay

I'd say priority on this is very high, because it can have very nasty side 
effects and slow down the complete system, without giving any indications to 
the user in the game why this happens.

just for clarification: this was only tested on slick so far

I don't have multimedia keys on my keyboard, so I can't reproduce this bug.
But I want to know the following things:
1. What key is set to "GIVEUP" button?
2. Does the bug still happen when "NONE" key is set to "GIVEUP" button?
3. What happens when JInput option is used? (run the game with command line 
"-j" option)

1. L on my machine, don't know for Rostis laptop, but pbbly another key
2. yes
3. seems to be ok, no going back to main menu

OK, thanks for the report. I think this is the bug of LWJGL/Slick's input 
handler. (in other words, it's out of our control)
The -j option becomes default from r619.

I'm not sure what the exact benefits are of using the lwjgl input handler, but 
I guess there are some.
I'm not 100% convinced this is a real "bug" of lwjgl, more along the lines that 
it is more sensitive than the JInput handler, and can also pickup those extra 
keys.

I quickly debugged this, to get you more info, so that you can maybe add some 
sort of exception handling for those keys.
I breaked at line 225 in StateKeyboardConfig.java, to get the key code values. 
When being in the Keyboard Config Screen in Nullpo for each of the 6 special 
keys, when pressed they all give:
int key = 13
char c = 0 (the actual 0 byte)

I also verified for my key config that indeed keymap[BUTTON_GIVEUP=12] = 38 
(which is L)
so still a bit of a mystery why GIVEUP gets triggerd. my guess is that maybe 
the 0 byte triggers could trigger all events, one of which just happens to be 
GIVEUP?

Using of JInput per default with -j, might have broken other keys?
See issue 53 for more info, might be related.

I just tested and r636 fixes the multimedia key issue.
This means we can go back to running with the lwjgl input handler per default, 
which should also improve key type detection again and thereby fix issue 53, 
from what I could test so far (/ key becomes assignable again etc.) - this 
needs verification tho.
Removed -j again in r637. (should the .exe be reverted? not sure how it works, 
just saw it was also changed in r619)

Sorry, removed -j in r638 of course.