This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Patch (numpad_arrows.patch, text/plain, 2020-08-28 00:57:43 +0000, 2019 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Windows 10, x86

Comments on the original bug report:

On 2020-08-28 00:56:45 +0000, Cameron Gutman wrote:

The fix for bug 4709 introduced a regression in SDL 2.0.12 which caused the scancodes of the number pad's arrow keys to change based on whether numlock is enabled or disabled. When enabled, the scan codes are appropriately mapped to SDL_SCANCODE_KP_8, SDL_SCANCODE_KP_4, etc. However, when disabled, they are incorrectly switched to the scancodes corresponding to the primary arrow keys (SDL_SCANCODE_UP, SDL_SCANCODE_LEFT, etc).

The cause of this issue is that VKeytoScancode() is mapping VK_LEFT, VK_RIGHT, etc. to SDL_SCANCODE_LEFT, SDL_SCANCODE_RIGHT, etc. prior to the code in WindowsScanCodeToSDLScanCode() which fixes up the numpad's scancodes to be consistent with and without numlock.

Because we only want to perform that mapping for the on-screen keyboard if no scan code is reported in the event, I've fixed this by only performing the VK_LEFT -> SDL_SCANCODE_LEFT mapping if none of the other mappings in WindowsScanCodeToSDLScanCode() match. This should fix this issue without regressing the on-screen keyboard fix in bug 4709.

On 2020-08-28 00:57:43 +0000, Cameron Gutman wrote:

Created attachment 4453
Patch

On 2020-11-12 00:50:50 +0000, Cameron Gutman wrote:

Can we add target-2.0.14 for this one? This is a 2.0.12 regression impacting real apps - https://twitter.com/voidpnt/status/1250803819484573698

On 2020-11-12 02:58:28 +0000, Sam Lantinga wrote:

Patch added, thanks!
https://hg.libsdl.org/SDL/rev/9296b2bfb5d1