mirror of
https://github.com/glfw/glfw.git
synced 2024-11-14 18:34:34 +00:00
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:
parent
3eaf1255b2
commit
b168c47c6a
@ -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
|
||||
|
||||
|
@ -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)
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user