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.
This commit is contained in:
Grzesiek11 2023-10-21 11:27:12 +02:00
parent 3eaf1255b2
commit b168c47c6a
No known key found for this signature in database
GPG Key ID: 4A5445FB68CDB5C4
3 changed files with 5 additions and 3 deletions

View File

@ -263,6 +263,7 @@ video tutorials.
- Jonas Ådahl
- Lasse Öörni
- Leonard König
- Grzesiek11
- All the unmentioned and anonymous contributors in the GLFW community, for bug
reports, patches, feedback, testing and encouragement

View File

@ -229,6 +229,7 @@ information on what to include when reporting a bug.
- [Win32] Bugfix: Instance-local operations used executable instance (#469,#1296,#1395)
- [Win32] Bugfix: The OSMesa library was not unloaded on termination
- [Win32] Bugfix: Right shift emitted `GLFW_KEY_UNKNOWN` when using a CJK IME (#2050)
- [Win32] Bugfix: Extended scancode of 0 was not being processed correctly
- [Cocoa] Added support for `VK_EXT_metal_surface` (#1619)
- [Cocoa] Added locating the Vulkan loader at runtime in an application bundle
- [Cocoa] Moved main menu creation to GLFW initialization time (#1649)

View File

@ -710,11 +710,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