piston icon indicating copy to clipboard operation
piston copied to clipboard

Many keys are not recognized by the input system

Open Lokathor opened this issue 8 years ago • 6 comments

Many keys on the keyboard are simply not recognized by the system at all, usually symbol keys or some of the numpad keys. As an example, the ; key doesn't generate any kind of input event, not even an event for an Unknown keyboard button press. I'd like all the keys to work, not just 80% of them.

I'm on windows, and using the piston_window defaults.

Lokathor avatar Mar 28 '17 01:03 Lokathor

piston_window uses Glutin by default, so there could be some missing mappings here: https://github.com/PistonDevelopers/glutin_window/blob/master/src/lib.rs#L376

bvssvni avatar Mar 28 '17 18:03 bvssvni

The full list of missing or incorrect keys seems to be:

  • ScrollLock
  • PrintScreen
  • ` ~
  • [ {
  • ] }
  • \ |
  • CapsLock (registers as Unknown)
  • ; :
  • ' "
  • / ?
  • NumPad . (but it properly registers as a Delete key if numlock is off)
  • NumPad Enter and normal Enter are the same (if it matters?)
  • Left and Right Alt read as Left and Right Gui instead.

An Input event of the Text form fires and gives the correct value for all the keys (eg, a "`" event when pressing the ` key), so the keys are being read by the system. It's just that they're just not also generating Press events properly.

Lokathor avatar Mar 28 '17 18:03 Lokathor

I was recently attempting to capture the numpad's directional keys, but on my x86_64 Linux machine, if NumLock is turned off, no event is produced when pressing any of the keys in the numpad. Is this the same issue, or something different altogether?

Enet4 avatar Nov 13 '17 18:11 Enet4

Probably the same thing. Numpad with and without numlock produces different key codes in other systems I've worked with, so im assuming it's part of how keyboards work and Piston is just not accounting for it.

Lokathor avatar Nov 13 '17 18:11 Lokathor

A deeper look into the glutin_window event handler shows that the patterns for keyboard input always match for Some(key) in virtual_keycode. Can it be that pressing these keys is yielding keyboard input events with only a scan code, and None for the virtual key code? Does it make sense to fix this by making map_key fill in these blanks with the appropriate keys based on the scan code?

Enet4 avatar Nov 13 '17 19:11 Enet4

The library would ideally have a way to signal to the application that a VK code was more of a guess than normal. I'm not sure what the answer there is. Some sort of VKGuess option maybe.

Lokathor avatar Nov 13 '17 19:11 Lokathor