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.
If detectEWMH failed to query the EWMH helper window, it would return
without restoring the previous Xlib error handler. This was bad
(because other code might also be using the facility) and bad (because
GLFW would assert the next time it tried to grab the error handler).
This commit adds the necessary release call.
Closes#2593Fixes#2601Closes#2631
libxkbcommon already provides functions to convert keysyms to codepoints
and UTF-8. The library has offered these functions since 0.5.0[1], so
using them won't cause any compatibility problems.
[1] https://xkbcommon.org/doc/0.5.0/group__keysyms.htmlCloses#2444
This replaces some workarounds and manual logic with new features
available with CMake 3.16, including list(FILTER), list(JOIN),
foreach(IN LISTS) and enable_language(OBJC). Policy settings no longer
needed with 3.16 have been removed.
Related to #2541
The intent of enforcing GLFW_EGL_CONTEXT_API for EGL native access
functions was to ensure that the application had requested the same
context creation API at window creation time that it then attempted
native access for.
With the 3.4 ABI this both isn't true anymore, as a single binary may
have multiple meanings of GLFW_NATIVE_CONTEXT_API, and is no longer
necessary, since glfwGetPlatform provides enough information to
disambiguate even without knowing what GLFW_PLATFORM was set to.
This all leaves the requirement that the context creation API be
GLFW_EGL_CONTEXT_API as just an unnecessary annoyance.
Fixes#2518
This provides very limited support for context creation via EGL on the
Null platform. It supports Unix-like systems with a version of Mesa
that provides EGL_MESA_platform_surfaceless.
Even then, the actual framebuffer provided is not resized along with the
'window'. That will hopefully change once context and framebuffer
creation are separated, but this commit should at least allow more
applications than before to run on the Null platform.
This adds support for Vulkan 'window' surface creation on the Null
platform via the VK_EXT_headless_surface extension, where available.
Tested with MoltenVK.
This adds the GLFW_UNLIMITED_MOUSE_BUTTONS input mode which permits
mouse buttons over GLFW_MOUSE_BUTTON_LAST to be reported to the mouse
button callback.
Closes#2423
When GLFW_ANY_PLATFORM is used (which is the default), X11 would be
selected on a Wayland system with XWayland and where XDG_SESSION_TYPE
was not set.
Closes#2035
This adds a function for querying the current title of a window. This
currently returns a copy of the last title set via GLFW.
Fixes#1448Closes#1909Closes#2482
