We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4443

Summary: Incorrect scan code reported for numpad 5
Product: SDL Reporter: bplu4t2f
Component: eventsAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: bplu4t2f, icculus, petrifiedrowan
Version: 2.0.9Keywords: target-2.0.10
Hardware: x86   
OS: Windows (All)   

Description bplu4t2f 2019-01-06 12:29:13 UTC 
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.
Comment 1 Alice R. 2019-01-18 22:33:48 UTC 
(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.
Comment 2 Ryan C. Gordon 2019-05-21 02:08:20 UTC 
Sam, I’ll look into this if you don’t want to; just reassign it to me.
Comment 3 Sam Lantinga 2019-06-08 17:48:20 UTC 
Fixed, thanks!
https://hg.libsdl.org/SDL/rev/74ba5a85d682