Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect scan code reported for numpad 5 #3117

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments
Closed

Incorrect scan code reported for numpad 5 #3117

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 2.0.9
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2019-01-06 12:29:13 +0000, wrote:

When num lock is on, the scancode reported for numpad 5 is SDL_SCANCODE_KP_5, which is correct. However, when num lock is off, windows reports the VK_CLEAR virtual key code, which is incorrectly translated into SDL_SCANCODE_CLEAR inside of the VKeytoScancode(WPARAM vkey) function.

Like all the other numpad keys (and following the entire point of scan codes to begin with), numpad 5 should always map to SDL_SCANCODE_KP_5. The "case VK_CLEAR: return SDL_SCANCODE_CLEAR;" should be removed.

Personally I feel like the entire VKeytoScancode function smells, since the scan code mapping from Windows to SDL should never require any virtual key code knowledge, so there might be more similar bugs there that nobody has found yet.

On 2019-01-18 22:33:48 +0000, Alice R. wrote:

(In reply to bplu4t2f from comment # 0)

When num lock is on, the scancode reported for numpad 5 is
SDL_SCANCODE_KP_5, which is correct. However, when num lock is off, windows
reports the VK_CLEAR virtual key code, which is incorrectly translated into
SDL_SCANCODE_CLEAR inside of the VKeytoScancode(WPARAM vkey) function.

Like all the other numpad keys (and following the entire point of scan codes
to begin with), numpad 5 should always map to SDL_SCANCODE_KP_5. The "case
VK_CLEAR: return SDL_SCANCODE_CLEAR;" should be removed.

Personally I feel like the entire VKeytoScancode function smells, since the
scan code mapping from Windows to SDL should never require any virtual key
code knowledge, so there might be more similar bugs there that nobody has
found yet.

Since we switched from SDL 2.0.5 to SDL 2.0.8, MegaZeux had this bug exactly as described. This is problematic since MegaZeux uses numpad 5 as an alternate key for space when numlock is disabled, and some MegaZeux games may use numpad 5 directly. We could translate SDLK_CLEAR to SDLK_KP_5 when numlock is disabled, but that would make the clear key act like numpad 5, which also doesn't make sense.

On 2019-05-21 02:08:20 +0000, Ryan C. Gordon wrote:

Sam, I’ll look into this if you don’t want to; just reassign it to me.

On 2019-06-08 17:48:20 +0000, Sam Lantinga wrote:

Fixed, thanks!
https://hg.libsdl.org/SDL/rev/74ba5a85d682

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant