libxkbcommon already provides functions to convert keysyms
to codepoints and UTF-8. The library has offered these
functions since 0.5.0 (https://xkbcommon.org/doc/0.5.0/group__keysyms.html),
so using them won't cause any compatibility problems.
The EGL_EXT_present_opaque extension is primarily a workaround meant for
Wayland, even if the language in it doesn't mention this. GLFW
previously always enabled this extension where supported. This caused
issues on X11 when running the Nvidia binary blob.
This commit ensures the extension is only enabled on Wayland.
Fixes#2365
It is reportedly possible to get opposing directions of an XInput DPad
bit mask set simultaneously with some controllers.
This commit ensures that those values are not passed on to other parts
of GLFW.
This commit is based on the PR #2291 by @ PeterJohnson but with the
following changes:
- moved XInput-specific special case to XInput implementation
- attempt to preserve data by only masking out the invalid axis
- admin (credit, changelog, commit message)
Closes#2291
The shared function for reading back context attributes,
_glfwRefreshContextAttribs, did not check whether the newly created
context had been successfully made current. This violated the invariant
that the context TLS slot always points to a valid window and that its
context is current whenever _glfw.platform.getProcAddress is called.
Related to #2327
The Wayland implementation of glfwWaitEvents* keeps waiting until it
sees evidence that a significant event has been processed. However,
this included updating an animated cursor (not a significant event)
but did not include previously buffered Wayland events or libdecor
events (definitely significant events).
This commit corrects these cases.
When setting the visibility of a libdecor frame on a compositor that
supports XDG decorations, libdecor 0.1 will update the geometry of the
XDG surface. GLFW attempted to set the visibility before having told
libdecor what size the content area is. This caused a Wayland protocol
error when libdecor attempted to set the window size to 0x0.
This commit adds setting the content area size for the libdecor frame
directly after creation, allowing libdecor to know what it's doing.
Much of libdecor is initialized only after certain events have been
received from the compositor and some parts of libdecor 0.1 are unsafe
to use until this delayed initialization has completed.
Since libdecor does not provide an API to query if or be notified when
this has happened, GLFW processed events until its newly created
libdecor frame had created its XDG shell objects.
This commit switches to using a generic Wayland sync point created just
after libdecor (and presumably its plugin) has set up its delayed
initialization, instead of relying on the more specific implementation
detail mentioned above.
It also makes this wait mandatory before the first libdecor frame is
created instead of a pre-condition for certain libdecor frame calls,
hopefully removing even more dependence on implementation details.
The bitmask passed to MsgWaitForMultipleObjects was missing
QS_SENDMESSAGE, causing glfwWaitEventsTimeout not to return when the
thread received messages sent from other threads.
Fixes#2408
A GLFW_CURSOR_UNAVAILABLE error would be emitted each time the cursor
moved over the fallback decorations if the standard cursor shape
appropriate for that part was missing on the system.
These errors served no useful purpose and have been removed.
This replaces the previous scheme where scancodes were equal to keycodes
(an implausible and potentially misleading situation) with a set of
scancodes invented purely for the null platform.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
Where available, the libdecor library is loaded at init and becomes the
preferred method for window decorations. On compositors that support
XDG decorations, libdecor in turn uses those. If not, libdecor has
a plug-in archtecture and may load additional libraries to either use
compositor-specific decorations or draw its own.
If necessary, support for libdecor can be disabled with the
GLFW_WAYLAND_LIBDECOR init hint. This is mostly in case some part of
the dynamic loading or duplication of header material added here turns
out to cause problems with future versions of libdecor-0.so.0.
Fixes#1639Closes#1693
Related to #1725
This commit simplifies the detection of which element of a fallback
decorated window the pointer has entered. Instead of looping through
the list of windows, the user pointer of fallback decoration surfaces is
set to the GLFW window object.
This replaces (one case of) manual management of weak links between
windows and monitors, both objects with complex life times, with
wl_object pointers used as opaque key values.
This is in preparation for adding support for libdecor, which creates
its own proxies on our display. It will likely also be helpful to some
people using native access on Wayland.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
If a window was initially fullscreen then it would not get an XDG
decoration object. If the window was later switched to windowed mode it
would then get fallback decorations instead of XDG ones.
Because EGL ties client API support to configs, attempts to create
a context with an unavailable client API will fail with the unhelpful
"failed to find suitable config" error description.
This attempts to detect cases where there are usable configs for the
other client API and emit a hopefully more helpful error.
Related to #2173
We only care about displayable pixel formats (as defined in
WGL_ARB_pixel_format) for window context creation.
This changes pixel format enumeration to ignore non-displayable formats,
which are specified to be listed after displayable ones, by always using
the return value of DescribePixelFormat as the pixel format count.
On systems lacking the EGL_EXT_present_opaque extension, some
compositors treat any buffer with an alpha channel as per-pixel
transparent.
This commit ignores any EGLConfig with an alpha channel if the extension
is missing and the window is created with GLFW_TRANSPARENT_FRAMEBUFFER
set to false.
This is technically not a breaking change since GLFW_ALPHA_BITS is not
a hard constraint, but it is still going to inconvenience anyone using
the framebuffer alpa channel to store other kinds of data.
Related to #1895
