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.
A window created with GLFW_VISIBLE set was not made visible by the
initial buffer swap during context attribute refresh.
Regression introduced by @elmindreda in
094aa6d3c7.
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.
We were previously storing the pointer position only when on the main
window, so when the user clicked on a fallback decoration it would use
the last position of the cursor on the main window, instead of the
position in the decoration surface.
Fixes part of #1991.
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
(cherry picked from commit 094aa6d3c7)
If a window lost input focus while a key was held down, the key repeat
mechanism would resume once the window regained focus.
(cherry picked from commit e24fe4b189)
This extensions allows GLFW to instruct the driver to ignore the alpha
bits, even in formats which contain them. This makes it possible to use
the alpha bits as extra storage, without it affecting the end result
getting displayed to the user.
Fixes#1434Fixes#1803
(cherry picked from commit 6281f498c8)
In the case the key repeat timerfd was interrupted before read(), the
cursor timerfd wasn’t read at all even when it could.
Related to #1711
(cherry picked from commit 68879081cb)
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
This extensions allows GLFW to instruct the driver to ignore the alpha
bits, even in formats which contain them. This makes it possible to use
the alpha bits as extra storage, without it affecting the end result
getting displayed to the user.
Fixes#1434Fixes#1803
Only apply the content scale to the initial size of the window if
content scale retrieval succeeded.
Related to #1615.
(cherry picked from commit 53d86c64d7)
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
(cherry picked from commit fbfd7e65c8)
The conversion of window icon image data involves unsigned char color
values being promoted to int and then shifted to the left by 24. For
32-bit ints this is just far enough to trigger undefined behavior.
It worked by accident because of how current compilers translate this
piece of code.
This was caught by @slimsag while working on [Zig bindings for GLFW][1],
and diagnosed together with @Andoryuuta, as described [in an
article][2]. Zig has UBSan enabled by default, which caught this
undefined behavior.
[1]: https://github.com/hexops/mach-glfw
[2]: https://devlog.hexops.com/2021/perfecting-glfw-for-zig-and-finding-undefined-behavior#finding-lurking-undefined-behavior-in-6-year-old-glfw-code
Thanks to Maato, martinhath, dcousens, drfuchs and Validark for helping
to refine the solution.
This commit message was rewritten by @elmindreda to hopefully reflect
the conclusions of the pull request thread.
Related to hexops/mach#20
Closes#1986
(cherry picked from commit 9cd4d2fa20)
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
The conversion of window icon image data involves unsigned char color
values being promoted to int and then shifted to the left by 24. For
32-bit ints this is just far enough to trigger undefined behavior.
It worked by accident because of how current compilers translate this
piece of code.
This was caught by @slimsag while working on [Zig bindings for GLFW][1],
and diagnosed together with @Andoryuuta, as described [in an
article][2]. Zig has UBSan enabled by default, which caught this
undefined behavior.
[1]: https://github.com/hexops/mach-glfw
[2]: https://devlog.hexops.com/2021/perfecting-glfw-for-zig-and-finding-undefined-behavior#finding-lurking-undefined-behavior-in-6-year-old-glfw-code
Thanks to Maato, martinhath, dcousens, drfuchs and Validark for helping
to refine the solution.
This commit message was rewritten by @elmindreda to hopefully reflect
the conclusions of the pull request thread.
Related to hexops/mach#20
Closes#1986
This docstring previously indicated that GLFW_CONTEXT_REVISION was
a window hint and attribute, but in fact it is only a window attribute
(there is no code which uses this constant in any other context.)
We noticed this in https://github.com/hexops/mach/pull/71/files#r749741814Closes#1992
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
(cherry picked from commit 37fc28bff6)
