This adds compile-time support for multiple platforms and runtime
detection of them. Window system related platform functions are now
called from shared code via the function pointer struct _GLFWplatform.
The timer, thread and module loading platform functions are still called
directly by name and the implementation chosen at link-time. These
functions are the same for any backend on a given OS, including the Null
backend.
The platforms are now enabled via CMake dependent options following the
GLFW_BUILD_<platform> pattern instead of a mix of automagic and ad-hoc
option names. There is no longer any option for the Null backend as it
is now always enabled.
Much of the struct stitching work in platform.h was based on an earlier
experimental branch for runtime platform selection by @ronchaine.
Every platform function related to windows, contexts, monitors, input,
event processing and Vulkan have been renamed so that multiple sets of
them can exist without colliding. Calls to these are now routed through
the _glfw.platform struct member. These changes makes up most of this
commit.
For Wayland and X11 the client library loading and display creation is
used to detect a running compositor/server. The XDG_SESSION_TYPE
environment variable is ignored for now, as X11 is still by far the more
complete implementation.
Closes#1655Closes#1958
The performance counter API is guaranteed to succeed on Windows XP and
later so there is no need for a fallback.
This removes our last dependency on winmm.
These headers come from when GLFW only supported a single context
creation API at a time, chosen at compile-time.
Since EGL and OSMesa are now always enabled and the platform-specific
APIs are tied to their specific window system, there is no reason to
keep these declarations separate from the internal.h and *_platform.h
header files.
This is done in preparation for runtime platform selection, to make sure
every platform can build with EGL enabled.
It may be possible to add support for things like the ANGLE null
platform later.
The native access functions for context handles did not verify that the
context had been created with the same API the function was for.
This makes these functions emit GLFW_NO_WINDOW_CONTEXT on API mismatch.
When the Vulkan loader is present but there are no required surface
extensions, as will for example happen with the Null platform, glfwinfo
caused an error in glfwGetPhysicalDevicePresentationSupport and produced
confusing output.
There is a suppression interval (0.25 seconds by default) after a call
to CGWarpMouseCursorPosition, during which local hardware events
(keyboard and mouse) are ignored. GLFW already calls
CGEventSourceSetLocalEventsSuppressionInterval with a value of 0.0, but
it doesn't help in this case, there is still a short delay before the
cursor can be moved. Moving the CGAssociateMouseAndMouseCursorPosition
call after the cursor position has been restored, fixes the issue.
Closes#1962
The Wayland protocol spec[1] states that set_cursor must be called
with the serial number of the enter event. However, GLFW is passing in
the serial number of the latest received event, which does not meet the
protocol spec.
[1] https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_pointer
As a result, set_cursor calls were simply ignored by the compositor.
This fix complies with the protocol more closely by specifically caching
the enter event serial, and using it for all set_cursor calls.
Fixes#1706Closes#1899
According to the libxkbcommon documentation[1], xkb_keymap_key_repeats
requires keymap and keycode as input:
int xkb_keymap_key_repeats( struct xkb_keymap * keymap,
xkb_keycode_t key)
However, in inputChar in wl_input.c we are passing in xkb_keysym_t,
which was a type mismatch.
This results in some keys not repeating when they should and vice versa.
[1] https://xkbcommon.org/doc/current/group__components.html#ga9d7f998efeca98b3afc7c257bbac90a8Closes#1908.
This updates to a newer version of glad2 and switches to the header-only
variant.
This also (finally) switches to the newer glad2 loader signature that
allows us to pass in glfwGetInstanceProcAddress directly.
This adds the glfwInitAllocator function for specifying a custom memory
allocator to use instead of the C runtime library.
The allocator is a struct of type GLFWallocator with fields
corresponding to malloc, realloc and free, while the internal API
corresponds to calloc, realloc and free.
Heap allocation calls are filtered before reaching the user-provided
functions, so deallocation of NULL and allocations of zero bytes are not
passed on, reallocating NULL is transformed into an allocation and
reallocating to size zero is transformed into deallocation.
The clearing of a new block to zero is performed by the internal
calloc-like function.
Closes#544.
Fixes#1628.
Closes#1947.
This will be useful when building GLFW as a CMake object library and
linking it into a larger library that exports pkg-config information.
Partly based on #1307 by @a3f.
Closes#1307.
This adds the GLFW_LIBRARY_TYPE CMake cache variable, which allows users
and higher-level projects to set what type of library GLFW is built as.
When not empty, this value overrides the standard BUILD_SHARED_LIBS
option for GLFW while still allowing it to control the type of other
libraries in a larger project.
This also allows building GLFW as an object library without adding dummy
source files (as required by Xcode) or producing unused library
binaries.
Projects using CMake 3.12 or later can link the resulting GLFW object
library normally using target_link_libraries.
Fixes#279.
Related to #1307.
Closes#1497.
Closes#1574.
Closes#1928.
The insight to use wayland.xml to resolve the difficult-to-redirect
interface symbols was gleaned from SDL.
Instead of compiling the code output of wayland-scanner separately it is
made part of the wl_init compilation unit. This lets us do things like
transparently rename our copies of Wayland globals.
The OS version of wayland-client-protocol.h is no longer used by GLFW,
but it is presumably ABI compatible with the output of wayland-scanner.
Closes#1174.
Closes#1338.
Related to #1655.
Closes#1943.
