KeyCode: Numpad key triggers regular key

[ufReitter]

Bevy version

284889c
0.4.0 had the same result

Operating system & version

macOS 11.2.2

What you did

     if keyboard_input.just_pressed(KeyCode::Key5) {
         thruster.thrust = thruster.thrust_max * 1.;
     }

    if keyboard_input.just_pressed(KeyCode::Numpad5) {
        submarine.bow_thruster = 0.;
    }

What you expected to happen

When pressing "5" on Number Pad the second If-Statement is triggered

What actually happened

When pressing "5" on Number Pad only the first If-Statement (Key5) is triggered

[bjorn3]

Bevy translates straight from winit keyboard events. Winit does support Numpad* events on macOS: https://github.com/rust-windowing/winit/blob/b9f3d333e41464457f6e42640793bf88b9563727/src/platform_impl/macos/event.rs#L176-L186 Does it change when you turn numlock on or off?

[nehalem501]

Does it change when you turn numlock on or off?

There is no numlock key in macOS if using an Apple keyboard with a numpad (it is always "on").

[bjorn3]

Then I think there is no way to distinguish numpad numbers and non-numpad numbers. Can other programs distinguish between them? For example in Blender the numpad numbers 2, 4, 6 and 8 should change between different view orientations while the non-numpad numbers should be interpreted as regular numbers.

[ufReitter]

Did not try Blender. But the system distinguishes between numpad and non numpad. When I open the mac virtual keyboard only the regular number keys highlight when pressed and not when pressing the numpad ones. In a text editor the numpad input appears fine.

[bjorn3]

Could you open an issue on winit? https://github.com/rust-windowing/winit/issues/

[mockersf]

The scan code is correct, the issue is on the key code

To account for different keyboard layout, winit is attempting to translate the keyboard event to a keycode using the actual character typed, so it can't differentiate between Numpad5 and Key5...

It's done here if you want to open the discussion on winit side - on my azerty layout, this function seems to produce a lot of wrong keycodes

[maroider]

There's currently ongoing work to improve the keyboard input API in Winit, which should address the fundamental issue encountered here.

See:

• Meta Issue: Keyboard input rust-windowing/winit#1806
• A keyboard input model rust-windowing/winit#753
• New keyboard API for Windows rust-windowing/winit#1788
• New keyboard API for macOS rust-windowing/winit#1890
• New keyboard API for the web rust-windowing/winit#1888

[mockersf]

should be fixed by #8745

[alice-i-cecile]

Resolved upstream.