Whenever GLFW changed the window style mask, a new mask was created
from scratch based on the attributes set on the GLFW window object.
This caused us to potentially clear unrelated window style bits.
This was always wrong but became a critical issue when Cocoa began
throwing an exception if an application cleared the
NSWindowStyleMaskFullScreen while the window is in macOS fullscreen.
This commit reworks all style mask editing so it only changes the
relevant bits, preserving all others.
This is only a narrow bug fix to prevent crashes, intended for the
stable branch. Our interaction with macOS fullscreen is still very
poor. The next step after this is a set of patches that improve the
interaction between the current API and macOS fullscreen.
Fixes#1886Fixes#2110
The reasoning here is that glfwRestoreWindow will change nothing for
a windowed non-resizable window on Cocoa, and silently refusing to
maximize seems slightly more like something other platforms would do.
This is possibly either the right thing to do or the wrong one.
When showing a window that had already been shown once (and so already
had its shell objects), GLFW would attach a new buffer and commit it
before waiting for the next configure event. This was a violation of
the XDG shell protocol.
This was allowed to work as intended on GNOME and KDE without error.
However wlroots based compositors would (correctly) emit an error.
Unfortunately, I haven't been able to find a way to get both KDE, GNOME
and Sway to send the configure event we need in order to map the
wl_surface again while keeping our existing shell objects, so with this
commit we now create them for each call to glfwShowWindow and destroy
them for each call to glfwHideWindow.
Fixes#1268
If a window was created as maximized, or created as hidden and then
iconified or maximized before first being shown, that state was lost and
the window was shown as restored.
Content scale events would be emitted when a window surface entered or
left an output, but not when one of a window's current outputs had its
scale changed.
GLFW would report a monitor as connected each time its wl_output
received an update, for example if its scale changed.
This would also cause the monitor to be added to the monitor array
again, causing glfwTerminate to segfault when it attempted to destroy
its already destroyed wl_output.
This is a temporary local fix to have updates to GLFW_DECORATED mostly
work as intended. The whole decoration state machine needs to be
restructured, but not by this commit.
The size limits set on our XDG surface did not include the sizes of the
fallback decorations on all sides, when in use. This led to its content
area being too small.
Related to #2127
The handler for xdg_toplevel::configure treated the provided size as the
content area size when instead it is the size of the bounding rectangle
of the wl_surface and all its subsurfaces.
This caused the fallback decorations to try positioning themselves
outside themselves, causing feedback loops during interactive resizing.
Fixes#1991Fixes#2115Closes#2127
Related to #1914
The internal maximization state was not updated when an event was
received that the user had changed the maximization state of a window,
and no maximization events were emitted.
This affected both the GLFW_MAXIMIZED attribute and glfwRestoreWindow.
These changes make GLFW fullscreen more consistent, but unfortunately
also make GLFW even more oblivious to user-initiated XDG shell
fullscreen changes.
Fixes#1995
The current window procedure needs to deal with messages both for user
created windows and the hidden helper window.
This commit separates out the device message handling of the helper
window, allowing both window procedures to be less complicated.
By default, the glfw3native.h header will include the platform-specific
headers necessary for the return types of GLFW native access functions.
Sometimes it is preferrable to declare those types
This commit adds support for the GLFW_NATIVE_INCLUDE_NONE macro, which
when defined disables the inclusion of all platform-specific headers.
Fixes#1348
GLFW did not restore the previous Xlib error handler when removing its
own, instead resetting to the default handler.
This commit saves and restores the previous error handler.
None of this is thread-safe or could ever be.
Fixes#2108
The joystick code did not distinguish between the allocation status of
the GLFW joystick object and whether it is connection to an OS level
joystick object.
These are now tracked separately.
Fixes#2092
The modifier bits for lock keys were only set when the corresponding key
was reported as held down or latched, but not when it was released and
locked.
This avoids glfwCreateWindow emitting GLFW_FEATURE_UNAVAILABLE or
GLFW_FEATURE_UNIMPLEMENTED on Wayland because shared code was calling
unimplemented or unavailable platform functions during final setup.
It also makes it consistent with the final setup of full screen windows.
The code assumed that at least some data would be received via the INCR
mechanism and that, as a result, the string buffer would be allocated.
Bug found by Clang static analysis.
The code assumed that all data offers were selections that supported
plaintext UTF-8.
The initial data offer events are now handled almost tolerably. Only
selection data offers are used for clipboard string and only if they
provide plaintext UTF-8. Drag and drop data offers are now rejected as
soon as they enter a surface.
Related to #2040
The string pointer used to write the contents of our clipboard data
offer was never updated, causing it to repeat parts of the beginning of
the string until the correct number of bytes had been written.
Emitting an error for one specific type of failure in retrieving the
correct name for a display is not very useful, especially when
initialization is otherwise unaffected.
There should be a path for information like that but this isn't it.
Fixes#1791
Operations that take an instance handle should be passed the handle of
whatever module we are inside instead of blindly passing the handle of
the executable.
This commit makes GLFW retrieve its own instance on initialization.
This makes the most difference for window classes, which are
per-instance. Using the executable instance led to name conflicts if
there were several copies of GLFW in a single process.
Note that having this is still a bad idea unless you know what things to
avoid, and those things are mostly platform-specific. This is partly
because the library wasn't designed for it and partly because it needs
to save, update and restore various per-process and per-session settings
like current context and video mode.
However, multiple simultaneous copies of GLFW in a single Win32 process
should now at least initialize, like is already the case on other
platforms.
Fixes#469Fixes#1296Fixes#1395
Related to #927
Related to #1885
Alt+PrtSc emits a different scancode than just PrtSc. Since the GLFW
API assumes each key corresponds to only one scancode, this cannot be
added to the keycodes array.
Instead we replace the scancode at the point of entry.
Fixes#1993
This change broke key names for dead keys, because that depends on
the effect on the global state of simulating two key presses.
Issue found by CTest tests.
Reverts #2018
The normal way of maximizing a window also makes it visible. This
implements window maximization manually for when the window passed to
glfwMaximizeWindow is hidden.
This will very likely not be forward-compatible and should be replaced.
The window content scale correction at creation overwrote the inital,
more pleasant placement of the window by CW_USEDEFAULT, if the window
was created with GLFW_MAXIMIZED set. This is because the translation
to screen coordinates was done using the current position, not the
position from the restored window rect.
A window created maximized and undecorated would cover the whole monitor
Windows placed it on instead of just that monitor's workarea.
This commit adjusts the maximized rect to cover just the workarea,
similar to how undecorated windows that become maximized are handled
during WM_GETMINMAXINFO.
Fixes#1806
The NetBSD sonames for X11 and related libraries is more stable than on
OpenBSD but the version numbers are still bumped more often than their
Linux counterparts, even excluding the one-time version bump across all
X11 related libraries.
This commit moves to using version-less sonames for X11 and related
libraries on NetBSD, which will hopefully be more forward-compatible
than hard-coding NetBSD-specific sonames.
This may not be the correct long-term solution but it runs now.
Binaries also appear to need an LD_LIBRARY_PATH or rpath entry of
/usr/X11R7/lib in order for the libraries to be found by dlopen.
Tested on NetBSD 9.2.
The display sync requests in glfwPostEmptyEvent could just accumulate as
the display was never flushed on secondary threads.
This adds a proper flush after each sync request.
Fixes#1520Closes#1521
There is a seemingly unavoidable race condition when waiting for data on
the X11 display connection, as long as any other thread is also making
Xlib calls. The event data we are waiting for could be read by the
other thread as part of looking for the reply to its request, before our
poll has begun.
This commit replaces the X11 event sent by glfwPostEmptyEvent with
writing to an unnamed pipe. The race condition remains if other Xlib
calls are made on other threads, but glfwPostEmptyEvent should now be
race-free.
This commit is based on work by pcwalton, OlivierSohn, kovidgoyal and
joaodasilva.
Closes#2033
Related to #379
Related to #1281
Related to #1285
The data available on the X11 connection may be a reply or an internal
event for an X11 extension. Previously the check for whether an event
was available for us was done outside waitForEvent. This prevented data
available on other file descriptors from breaking the outer wait loop.
This commit moves the check for whether an event is available into the
wait functions, where there is enough knowledge to limit the check to
the X11 connection.
Related to #932
On Linux, the inotify descriptor was included in the set used for
select, but could not break the outer loop, leading to busy waiting
until timeout or the correct X11 event arrived.
This commit adds a new function for waiting just on X11 events.
Fixes#1872
We switched to kUTTypeURL when NSURLPboardType was deprecated, as the
official replacement symbol NSPasteboardTypeURL was not available on
every version of macOS supported by GLFW.
kUTTypeURL has now also been deprecated.
This commit moves to a compile-time choice between NSURLPboardType and
NSPasteboardTypeURL depending on the minimum targeted macOS version.
Fixes#2003
By definition a hidden window on Wayland does not have valid framebuffer
contents.
This adds a window damage (refresh) event when a window is shown, to
request an initial frame for the now visible window.
Platform code should not generate key events with GLFW_REPEAT.
GLFW_PRESS is translated into GLFW_REPEAT by shared code based on the
key state cache.
This confused the automatic key release logic into not generating an
event with GLFW_RELEASE for a key being repeated when the window lost
input focus.
The OpenBSD ports tree assigns its own soname version numbers, so the
hardcoded sonames GLFW uses to load libraries on non-macOS Unices are
often incorrect. Instead OpenBSD recommends that run-time loading
should leave out the version numbers entirely. The OpenBSD ld.so then
finds the correct library.
This upstreams the ports tree fixes for Xcursor and EGL, and adds the
corresponding fix for all other run-time loaded library sonames.
Tested on OpenBSD 7.0.
This issue was initially reported on IRC.
Corrects the protocol violation when creating an xdg_surface from a
wl_surface that already has a buffer due to EGL buffer swaps.
This commit is based on PR #1731 by @ghost, but adapted and altered:
- The XDG surface and role are now only created when a window is shown
to prevent application lists from showing command-line applications
with off-screen-only windows
- The special case of Wayland+EGL buffer swap is now in the EGL code
to mirror how X11 is handled
- Adaption to run-time platform selection and separate credits file
Fixes#1492Closes#1731
The monitor handle could have become invalid just before the call to
GetDpiForMonitor. It was possible for both window and monitor content
scale queries.
This ensures both that an appropriate error is emitted and that the
retrieved values are zero on error.
Fixes#1615
This removes the GLFW_VULKAN_STATIC CMake option and the
_GLFW_VULKAN_STATIC configuration macro and replaces them with the
glfwInitVulkanLoader function, allowing a single library binary to
provide both behaviors.
This is based on the design from PR #1374 by @pmuetschard.
Closes#1374Closes#1890
This hack breaks when switching a window to fullscreen, if the OpenGL
ICD detects this and switches its swapchain to exclusive mode.
This limits the hack to Windows Vista and 7. This hack was added
because of vsync jitter under DWM on Windows 7 and I have been unable
to reproduce it on any later version.
Is this change causing any problems on any version of Windows? Please
open an issue!
Fixes#1072
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 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.
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 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.
POSIX.1-2008 deprecated gettimeofday, which we used as a fallback if the
monotonic clock was unavailable.
This replaces that fallback with the non-monotonic real-time clock.
Because of the Gordian knot of feature test macros across Unices, this
also includes the shift from some platform source files defining
_POSIX_C_SOURCE to various values to _DEFAULT_SOURCE being defined for
all source files on Linux. This is because -std=c99 on Linux disables
_DEFAULT_SOURCE (POSIX 2008 and extensions).
Once runtime platform selection comes in, this kind of platform-specific
preprocessor logic can be moved into the platform glue files and won't
need to be replicated by third-party build setups, but for now, sorry.
The contents scale of the hosted CAMetalLayer created for MoltenVK was
updated only after the GLFW content scale and framebuffer size events
were emitted, causing the layer to get out of sync with the monitor the
window was on.
Because there are controllers in the wild using the same hardware ID
despite having different numbers of buttons and axes, an error message
was triggered that was only expected for a corrupted mapping database.
This removes the error for now, in preparation for better error handling
for gamepad mappings overall.
Fixes#1763.
