mojira.dev
MC-310984

`KEY_ZENKAKUHANKAKU` and key 195 map to the same key even though they shouldn't

According to the SDL3 key code list for Linux (https://github.com/libsdl-org/SDL/blob/855cbec702f246661ff00a0bce9e0683012840c2/src/events/scancodes_linux.h ), KEY_ZENKAKUHANKAKU should map to SDL_SCANCODE_LANG5 (key.keyboard.148), and the unnamed key 195 should instead map to Not Bound (i.e. UNKNOWN). However, unexpectedly, they both map to Mode (SDL_SCANCODE_MODE), which defies what the document explicitly specifies.

This is easiest to reproduce if you have a Japanese keyboard, since the ZENKAKUHANKAKU key is physically present. A script is attached for those without such a keyboard to hand.

To reproduce (Linux):

  • download the Python script attached in the comment section

  • open a command window in the same folder it’s present

  • go into Minecraft’s key binds menu, then click on a key to rebind

  • paste this into the command window and run it: ./simulate-keys 'sleep 2' 'press 85' 'sleep 0.1' 'release 85'

  • note what key is registered

  • repeat, but with this command: ./simulate-keys 'sleep 2' 'press 195' 'sleep 0.1' 'release 195'

  • observe

Expected results: two different keys, since 85 and 195 are two different numbers and assigned different IDs in the SDL3 spec: https://github.com/libsdl-org/SDL/blob/855cbec702f246661ff00a0bce9e0683012840c2/src/events/scancodes_linux.h

Actual results: for some reason, they both map to the same thing.

Linked issues

Attachments

Comments 3

Thank you for helping us improve Minecraft! We saved your files:

[media][media][media][media][media]

The script since I can’t attach it to the base ticket:

[media]

As of snapshot 9 they bind to Mode rather than key.keyboard.257.

muzikbike

(Unassigned)

Plausible

Platform HC

Low

Input

26.3 Snapshot 7, 26.3 Snapshot 8, 26.3 Snapshot 9

Retrieved