AwtKeyInput Missing Keycodes for "PrintScreen"

[MeFisto94]

Hey Guys,
As the SDK received an issue request that taking a screenshot while the SceneComposer is open leads to unsupported key:154 being shown.

After some research, I found out that https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-desktop/src/main/java/com/jme3/input/awt/AwtKeyInput.java#L375 or rather https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-desktop/src/main/java/com/jme3/input/awt/AwtKeyInput.java#L605 is responsible for that.

So if jme has a Key related to PrintScreen or if there are plans on allowing PrintScreen as a key tell me, so I can work on it.

[empirephoenix]

Is this key the same on all platforms? If so, I see no reason why we should not support it.

[grizeldi]

The original report comes from linux.

[empirephoenix]

I can check linux, can you check what windows does?

[grizeldi]

Sadly I can't. Ubuntu here.

[empirephoenix]

XD, so does ubuntu does this then?

[grizeldi]

Yup, it was me reporting it to MeFisto ;P

[ghost]

You can use KeyEvent.VK_PRINTSCREEN but there is no such key under Mac OS X as far as I know.

[DomenicDev]

I would like to take this issue.

I have got a question though: What Code does the Key "PrintScreen" belongs to?

[MeFisto94]

A bit background here:
In order for jme to handle the PrintScreen Key, it has to be added to https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/input/KeyInput.java, which however requires a numeric value.

Furthermore what about KEY_LAST? It would need to be increased and hence breaking compatibility for anyone relying on this being 0xE0 instead of referring to KEY_LAST (which can be ignored maybe, because it would be misuse).

[DomenicDev]

So it's okay to just increase LAST_KEY to 0xE1 and give PRINT_SCREEN the value of 0xE0 ?

[pspeed42]

I think someone has not done a great job of explaining what the real issue is because I capture the Prt Scr button on Windows all the time... in fact, I guess it's the default mapping for the screen shot app state.... which I guess is really the Sys Req key on all of my keyboards:
https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-core/src/main/java/com/jme3/app/state/ScreenshotAppState.java#L176

...so I guess there are keyboards that do not pair these?

As far as this:
"It would need to be increased and hence breaking compatibility for anyone relying on this being 0xE0 instead of referring to KEY_LAST"
...those people should have their Java license taken away, I think. ;) That's what constants are for.

[MeFisto94]

I've just done some research:
https://en.wikipedia.org/wiki/System_request / https://de.wikipedia.org/wiki/Systemabfrage-Taste (The German Version seems to be more detailed, so I'll translate it):

In 1984 the IBM Computer/AT had 84 keys instead of 83, because the Sysreq Key was added. however since 1987 it has been consolidated with the Print Screen Key.
BUT: The article also states, that Sysreq still has it's own scancode, because on Notebooks there could be a separate SysReq Key or the Key isn't present at all.

This would mean:

• Adding a Print Screen Key
• Refactoring old code (ScreenshotAppState) to use this Scancode, just in case there would be some odd notebook keyboards. We're not loosing/breaking anything that way.

[pspeed42]

Yeah, and I think adding the keycode is easy. Just add the constant. It sounds like it should be 154:
unsupported key:154

...which there is no KeyInput value for yet. (154 = 0x9a)
public static final int KEY_UNLABELED = 0x97;
public static final int KEY_NUMPADENTER = 0x9C;

...so there is room for it there. (Then change the appropriate places in the system-specific event classes of course.. AwtKeyInput in this case.)

[MeFisto94]

This also matches with https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2#file-usb_hid_keys-h-L198 and https://gist.github.com/MightyPork/6da26e382a7ad91b5496ee55fdc73db2#file-usb_hid_keys-h-L110

[MeFisto94]

We've done some further investigation as the fix didn't work as expected and it turns out that this issue only applies to the AwtPanelsContext (since it's the only user of AwtInputs) but that the LwjglKeyInput (jme3-lwjgl) does NOT fire KEY_PRINTSCREEN. (LWJGL/lwjgl#145)

The Problem here is if we add KEY_PRINTSCREEN, then many complaints will arise when people try to use the Print Key instead of the SysReq one.

However hacking jme3-lwjgl so it triggers two key events might not be an acceptable solution?

[pspeed42]

If an app wants to respond to print screen then they should register to listen to that. If they want to handle 90% of user's "hitting print screen" then they will also want to register for sys req. (Bottom line is we should not be interpretting intent at the key event processing level... if it's a separate print screen button then send that code. If it's a sys req button that happens to also be print screen then send the sys req code.)

However, the fact that LWJGL doesn't even send it is a separate bug.

[MeFisto94]

Well technically I think LWJGL is just wrong there assuming that it's the SysReq Key because (at least according to wikipedia) the actual sysreq key is now rather a combination of alt + something else.
Awt might be querying the OS in a different way or is simply aware of the difference.

How about a javadoc hint for KEY_PRINTSCREEN in combination with lwjgl? Because else everyone falls into the pit of "why doesn't print screen listen to a keypress of "print screen"".

[pspeed42]

That seems reasonable... Mention that it's for separate prt scrn buttons only (and consider using prt screen instead of "print screen"... See the other constants.)... And that for most use cases you really want sys req. It's a similar issue with enter and numpad enter (which is actually the regular enter let on Macs)

…

On Jan 14, 2018 6:01 AM, "MeFisto94" ***@***.***> wrote: Well technically I think LWJGL is just wrong there assuming that it's the SysReq Key because (at least according to wikipedia) the actual sysreq key is now rather a combination of alt + something else. Awt might be querying the OS in a different way or is simply aware of the difference. How about a javadoc hint for KEY_PRINTSCREEN in combination with lwjgl? Because else everyone falls into the pit of "why doesn't print screen listen to a keypress of "print screen"". — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#682 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGrfnnFhIpv6MXPb0QOTdr9gCX82Qy7mks5tKd5xgaJpZM4OS6pq> .

[pspeed42]

Oh, and the lwjgl thing is definitely a bug on their side and probably deserves a mention in our docs... But anyone wanting to do actual "print screen" behavior will always want at least sys req anyway.

…

On Jan 14, 2018 6:04 AM, "Paul Speed" ***@***.***> wrote: That seems reasonable... Mention that it's for separate prt scrn buttons only (and consider using prt screen instead of "print screen"... See the other constants.)... And that for most use cases you really want sys req. It's a similar issue with enter and numpad enter (which is actually the regular enter let on Macs) On Jan 14, 2018 6:01 AM, "MeFisto94" ***@***.***> wrote: > Well technically I think LWJGL is just wrong there assuming that it's the > SysReq Key because (at least according to wikipedia) the actual sysreq key > is now rather a combination of alt + something else. > Awt might be querying the OS in a different way or is simply aware of the > difference. > > How about a javadoc hint for KEY_PRINTSCREEN in combination with lwjgl? > Because else everyone falls into the pit of "why doesn't print screen > listen to a keypress of "print screen"". > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#682 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGrfnnFhIpv6MXPb0QOTdr9gCX82Qy7mks5tKd5xgaJpZM4OS6pq> > . >

[DomenicDev]

Isn't it that most people rather know PrintScreen than SysRq? Or am I wrong?

[pspeed42]

Only if you were born recently, I guess. Anyone who has ever mapped a key knows that the key is really keycode sys req. Lying to them and telling them that it's a prt scrn button is wrong. Just wrong wrong wrong.

It's the sys req keycode. We should NOT NOT NOT be interpretting it as anything else at a low level key input API. That would be as horribly wrong as deciding that we should map letter keys differently to help the French play WASD based games on their keyboards. Do not interpret the keycodes.

...plus, then what would you do for those folks who really do want to let users map them differently.

[DomenicDev]

I created a pull request for this issue:

#806

[DomenicDev]

Hi Nehon, thanks for merging. Can this issue be closed by now?