Also fix iOS export logic that would force a min target of iOS 14.0 (for Metal)
even when targeting the Compatibility renderer.
Co-authored-by: Pāvels Nadtočajevs <7645683+bruvzg@users.noreply.github.com>
Simpler alternative to #103026 which avoids breaking compatibility.
Instead of introducing a new `auto` default value, we ensure that all
supported drivers are registered regardless of the editor's host platform,
and that the defaults are the intended ones.
This solves the following issues:
- macOS exports are meant to default to Metal in 4.4, but they would
default to Vulkan if exported from Linux, Windows, or Android editors.
- Windows exports couldn't be made with Direct3D 12 from Linux, macOS, or
Android editors, as the option couldn't be selected outside Windows.
Unlike #103026, it doesn't solve the issue of not always saving the
rendering drivers to `project.godot`, but now the defaults are at least
consistent between editor platforms.
Co-authored-by: Pāvels Nadtočajevs <7645683+bruvzg@users.noreply.github.com>
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.
AThousandShips
Anish Mishra
Rémi Verschelde
cafebeef
Hilderin
Thaddeus Crews
Pāvels Nadtočajevs
Adam Scott
David Snopek
Fredia Huya-Kouadio
Jānis Kiršteins
Riteo