When the swap interval was nonzero, EGL on Wayland would wait
indefinitely for a frame callback on a suspended window, causing
applications that call eglSwapBuffers to halt.
This re-implements the wait for a surface frame so that we can add
a reasonable timeout, while setting the EGL swap interval to zero. That
allows applications to make progress despite the window being suspended.
Some insights for how to structure this workaround were gleaned from
dri2_wl_swap_buffers_with_damage in Mesa.
This initial implementation still has a race between glfwHideWindow and
glfwSwapBuffers when rendering on a separate thread. This could lead to
a window becoming visible again after being hidden on the main thread.
Related to #1350Fixes#2582Fixes#2640Fixes#2719Fixes#2723Fixes#2800Fixes#2827
This adds support for high-resolution scroll input scaled to match
legacy discrete scroll input. It is available on compositors that
support wl_seat version 8 or later.
High-resolution "discrete" values now replace non-scaled scroll
values when available.
This adds support for wl_seat version 5, which adds pointer frames.
This allows two-dimensional scroll input to be emitted as single events
instead of one event per axis per motion.
It's also the the foundation for future enhancements like properly
scaled discrete scroll events and server-side key repeat.
Fixes#2494
The client-side key repeat timer fd was only created for wl_seat version
4 or later, but was then used unconditionally during event processing.
Rather than have this mechanism do nothing in a more correct way on
wl_seat version 3 or earlier (which is very old by now), this commit
creates the key repeat timer fd and then sets (hopefully gentle)
hardcoded repeat delay and rate.
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 implements window attention requests via the xdg-activation-v1
protocol.
This was updated by @ elmindreda to work with recent Wayland related
changes to the main branch:
- Switched to current way of handling Wayland protocol files
- Added the xdg-activation-v1.xml protocol file to deps/wayland
- Added missing macros to rename protocol interface globals
The protocol file was copied from wayland-protocols 1.33.
Closes#2287
This brings the latest released versions of all used Wayland protocol
files into this repository, removing the need for the user to arrange
a sufficiently new version of wayland-protocols.
The wayland.xml protocol file was copied from wayland 1.22.0.
The additional protocol files were copied from wayland-protocols 1.32.
Because of how files are moved and renamed inside the wayland-protocols
repository, it will not always be possible to update all our protocol
files from a single release without also potentially updating related
code (acceptable) and prematurely breaking compatibility with
compositors that still only support an earlier incompatible version
(unacceptable).
The macro in src/CMakeLists.txt has been modified to hopefully make it
easier to add new protocol files. This made it necessary to change the
name of a few of the generated header files.
Closes#2053
A segfault could occur during termination if libdecor was found but no
windows were created between initialization and termination. The wait
for libdecor to finish its initialization was only performed before
window creation, not at termination.
Regression introduced by 9fdc425931.
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.
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 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.
The cursor theme was only loaded if the chosen seat had a mouse
(wl_pointer) during initialization. If a mouse was connected only after
glfwInit, there would be no cursor theme but the rest of the cursor
related code assumed one had already been loaded.
This also moves the details of cursor theme loading out into a separate
function to declutter platform init.
Because the original cursor theme loading code checked whether we got
a wl_shm, and because the rest of the code just assumes we have
a wl_shm, initialization will now fail if there isn't one.
Fixes#1450
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.
Versions of wayland-scanner prior to 1.17.91 named every global array of
wl_interface pointers 'types', making it impossible to combine several
unmodified private-code files into a single compilation unit.
This overrides that name with a macro for each file, allowing them to
coexist.
Fixes#2016Closes#2032
The Wayland backend was the only one where half the window and input
related code was in the init module. As those bits want to share more
utility code with the window module, the interface between them grows.
To prevent that, this gathers nearly all window and input related code
into the window module.
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
