Fix extended scancode of 0 not being processed correctly

On Windows, keyboard events with an extended 0 Windows scancode are now
processed by mapping the virtual-key code to a Windows scancode using
the Win32 MapVirtualKey function.

Some keyboard scancodes (in particular, ones used for some non-typical
keys) are not mapped to corresponding Windows scancodes, and are instead
mapped to an extended 0 Windows scancode, with the distinction being
only in the virtual-key code.

This causes GLFW to report a 256 GLFW scancode (0x00 | 0x100, 0x100
being the extended bit bitmask) for any of those keys, which causes API
consumers to be unable to distinguish between them.

There exists, however, a Win32 function MapVirtualKey that maps those
virtual key-codes to proper Windows scancodes. GLFW even appears to use
this workaround, but after further inspection, it checks whether the
Windows scancode is 0 (0x00), and not extended 0 (0x100).

This change makes GLFW check for the extended 0 keycode instead, which
seems to work correctly. I'm not sure if checking for the non-extended 0
Windows scancode was intentional, as I never seem to have encountered
one during testing with multiple keyboards. Thus, the handling of the
non-extended 0 Windows scancode was removed, but it can be brought back
if necessary.

README.md

@@ -133,6 +133,7 @@ information on what to include when reporting a bug.
  - [Null] Added Vulkan 'window' surface creation via `VK_EXT_headless_surface`
  - [Null] Added EGL context creation on Mesa via `EGL_MESA_platform_surfaceless`
  - [EGL] Allowed native access on Wayland with `GLFW_CONTEXT_CREATION_API` set to
+ - [Win32] Bugfix: Extended scancode of 0 was not being processed correctly
    `GLFW_NATIVE_CONTEXT_API` (#2518)
 
 

src/win32_window.c

@@ -714,11 +714,11 @@ static LRESULT CALLBACK windowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM l
             const int mods = getKeyMods();
 
             scancode = (HIWORD(lParam) & (KF_EXTENDED | 0xff));
-            if (!scancode)
+            if (scancode == 0x100)
             {
-                // NOTE: Some synthetic key messages have a scancode of zero
+                // NOTE: Some synthetic key messages have a scancode of extended zero
                 // HACK: Map the virtual key back to a usable scancode
-                scancode = MapVirtualKeyW((UINT) wParam, MAPVK_VK_TO_VSC);
+                scancode = KF_EXTENDED | MapVirtualKeyW((UINT) wParam, MAPVK_VK_TO_VSC);
             }
 
             // HACK: Alt+PrtSc has a different scancode than just PrtSc