This fixes once and for all the core issue of different Godot `keycode`s
released from the same raw XKB keycode.
The `InputEventKey` `keycode` value _should_ map to the "unmodified"
key, but unfortunately there's an ambiguity with their encoding for
"special" keys ("delete", "insert", etc.), in witch they ignore their
unicode representation. This means that a key that is special when plain
but a character when modified would never be properly picked up, so we
do indeed change its keycode. As a consequence of this exception, some
Godot keys never receive release events and get "stuck".
This patch adds an extra check through an `HashMap` to "unstuck" keys
that changed while having the same keycode.
I also could not resist simplifying a bit the regular key event
generation method but this makes things more consistent and predictable
IMO.
There were two edge cases in the frame waiting logic (aka manual frame
throttling or emulated vsync) which would cause the editor to stall in
one way or another:
1. Waiting right after starting the editor would cause a deadlock
between both threads until something happened in the Wayland event
queue, in turn unblocking the Wayland thread and kickstartin the whole
thing;
2. Starting the editor (and probably other long-loading stuff) without
low consumption mode would suspend the window and never commit its
surfaces, thus never signaling the compositor that we want frame events.
We should only include the vendored headers for Wayland and libdecor-0 when
we use `so_wrap`, i.e. when we *don't* build against system libraries.
The libdecor-0 pkg-config file includes the `libdecor-0/` prefix already,
so its header should be included without it, and likewise in our so wrappers.
Fixes#102671.
The `keycode` field of `InputEventKey` is supposed to be "unshifted";
That is, what the key would output if no modifier keys were pressed.
This should match what's written on the key label, but `Key` enumerates
also all keypad keys, which require a modifier. We thus require some
extra checks for them.
Note that this can still allow "stuck keys", but that's an even deeper
problem.
Images don't have RIDs and this way of checking stuff broke the cursor
cache. Let's do like all other platforms and check the resource
reference instead.
This speeds up build time considerably for these platforms compared to
using `lto=full`, which is sadly single-threaded with LLVM, unlike GCC.
Changes to default behavior of `lto=auto` (i.e. `production=yes`):
- Linux: Prefer ThinLTO for LLVM
- Web: Prefer ThinLTO
- Windows: Prefer ThinLTO for llvm-mingw
The following LLVM targets don't use LTO by default currently, which
needs to be assessed further (gains from LLVM LTO on performance need
to be weighed against the potential size increase from heavy inlining):
- Android
- iOS
- macOS
- Windows clang-cl
This restriction was added to fix#7373 back then, which was a symbol conflict
between FreeType's bundled copy of gzip/zlib, and distro packages.
But we also unbundled FreeType's zlib in #69395 so this is no longer an issue.
On the other hand recent issues pointed out that using system-provided icu4c
or harfbuzz can cause issues (#91401, #100301). We still allow it for now but
raise a warning.
Before, we would check both methods together, leading to loops.
Now we track the actual reason we suspended and only unsuspend when
that same reason triggers. For example, if we suspend because of the
suspended flag we'll unsuspend only because it got unset. Conversely, if
we suspend because of a timeout we'll unsuspend only if we get a new
frame event.
We do this because, while some compositors properly report a "suspended"
state (hinting us to stop repainting), most don't and we need a "safety
net" anyways as we do not want to constantly stay at 1fps (the max time
we'll wait before giving up) either.
Dynload-wrapper 0.7 introduces the --include-dir option which lets us restrict
what headers are considered for generation.
In this case it removes the `XFreeThreads` Xlib function which does not
exist on Ubuntu 22.04 and older.
The v1 version is deprecated and bound to be removed in the future from
all compositors. This patch adds a v1/v2 designator to everything
related to the protocol and prefers the v2 protocol if both are
available.
Additionally, renames the event handler to follow the Wayland interface
name, for consistency with the rest of the codebase.
Fixes#95897
During CI scenarios $HOME may be set to an invalid value (such as
`/var/empty`).
Using temp dirs fits better with godot's usage of these paths and is
independent from the user's $HOME.
Version 0.6 of https://github.com/hpvb/dynload-wrapper/ now supports all
of the features we need to generate the wrappers without editing them.
This replaces the hand-patched wrappers with "clean" generated ones.
Godot checks if there's Vulkan or GLES3 support.
If no support is found, it shows an error message.
However the code for this error message is left out when building with
opengl3=no
Make Drag and Drop an application-wide operation.
This allows do drop on Controls in other Viewports/Windows.
In order to achieve this, `Viewport::_update_mouse_over` is adjusted to
remember the Control, that the mouse is over (possibly within nested
viewports). This Control is used as a basis for the Drop-operation, which
replaces the previous algorithm, which was only aware of the topmost
Viewport.
Also now all nodes in the SceneTree are notified about the Drag and Drop
operation, with the exception of SubViewports that are not children of
SubViewportContainers.
Initially the WaylandThread cursor code was supposed to be as stateless
as possible but, as time went on, this wasn't possible.
This expectation made the resulting API quite convoluted, so this patch
aims to simplify it substantially bot in terms of API surface and, most
importantly, in terms of actual implementation complexity.
This patch also fixes custom cursors since I accidentally changed the
mmap flags to MAP_PRIVATE some time ago. This took me hours to notice.
While experimenting with the recent "extent to title" PR, I noticed that
it's not guaranteed for a "button released" event to be emitted when
the pointer leaves the main surface, leaving some buttons stuck.
Not doing this for tablets since the spec makes this behavior clear and
explicit, so we (hopefully) shouldn't have this issue there.
Features:
- Debug-only tracking of objects by type. See
get_driver_allocs_by_object_type et al.
- Debug-only Breadcrumb info for debugging GPU crashes and device lost
- Performance report per frame from get_perf_report
- Some VMA calls had to be modified in order to insert the necessary
memory callbacks
Functionality marked as "debug-only" is only available in debug or dev
builds.
Misc fixes:
- Early break optimization in RenderingDevice::uniform_set_create
============================
The work was performed by collaboration of TheForge and Google. I am
merely splitting it up into smaller PRs and cleaning it up.
Before, they would always complain even if there was no attempt at
initializing them (e.g. because there's no X11 display).
While we're at it, this patch also adds a specific message for OpenGL ES
and rewords "OpenGLES" to "OpenGL ES" in an error, for consistency
(AFAIK we either say "GLES" or "OpenGL ES").
Before, multiple capability events would instantiate the same object
over and over as long as its bit was set. This caused issues with
hotplug and device suspension.
On Windows this allows to avoid having to change the owner of the window
after it has been created, which in rare circumstances may cause the
window to bug out.
Allocated XImages are improperly free'd with XFree.
The X11 documentation says that XImage should use
XDestroyImage to free both the image structure and
the data pointed to by the image structure.
Also fix a potential use-after-free bug.
This reduces even further the amount of work we have to do when scaling
and potentially improves input accuracy as now the input code is free
from any form of rounding.
Before of this patch, as explained in the usual
commented-wall-of-text-longer-than-the-actual-patch-itself™, due to the
multithreaded nature of the Wayland thread, it was possible to commit a
surface while the renderer was doing stuff, which was _very_ wrong.
Initially the consequences of such a sin weren't obvious but, now that
explicit synchronization is becoming more and more common, we can't
commit a buffer randomly without basically guaranteeing a nasty, nasty
crash (and we should have avoided commits altogether in the first place
to ensure atomic surface updates).
We now only trigger a commit _in the main thread_ when low processor usage
mode is on _and_ if we know that we won't be rendering anything as, due to
its intermittent nature, it makes "legacy" (pre xdg_wm_base v6) frame
callback based suspension quite annoying.
- Make warnings print only once per session.
- Tweak the message to be less confusing, and mention that the issue
most likely stems from a graphics driver limitation.
Input events go to the tooltip because it's added to `popup_list` in
DisplayServer `popup_open`. I think there's no harm in tooltips being omitted
from the list, so this commit blocks non-popup windows from being added if they
have `FLAG_NO_FOCUS` and `FLAG_MOUSE_PASSTHROUGH`.
I'm not happy with this way of detecting tooltips. It'll also catch other
windows where this behavior may or may not be wanted.
I thought about adding `FLAG_TOOLTIP`, but went with the smaller change for
now.
Fixes#79500.
This avoids any assumption from the driver, which would otherwise select
a specific platform and potentially mess up everything, resulting
usually in a display server failure.