This patch introduces a new protocol proxy, which multiplxes Wayland
clients into a single connection, allowing us to redirect calls (e.g.
create toplevel -> create subsurface). Mixed with some state tracking
and emulation, we can embed a full-featured client into the editor.
Previously, on Linux and BSD, inhibiting the screensaver was handled
using the org.freedesktop.ScreenSaver D-Bus API. Unfortunately, this API
is not available in a Flatpak sandbox. (This is because there is a
desire to tie inhibit sessions to a specific app and visible window; but
the org.freedesktop.ScreenSaver API does not support this.)
As a result, when using the Flatpak build of the Godot Editor (or a
Flatpak-ed build of a game) and using a controller to play a game, the
session will become idle after a few minutes.
The XDG desktop portal -- which is already used for color-picking, file
choosing, and querying the system theme -- has an Inhibit interface that
provides a superset of the functionality of the
org.freedesktop.ScreenSaver API, and is available to any sandboxed app.
Refactor code for making XDG portal requests that was previously
duplicated for the FileChooser and ColorPicker portal code. Check the
portal version to determine whether these portals can be used:
- FileChooser portal version 3 is required due to the use of the
"directory" parameter.
- On the Settings portal, the only addition in version 2 is the
ReadOne() method which is not used here, so version 1 suffices.
- On the Screenshot portal, the only addition in version 2 is the
"interactive" parameter to the Screenshot() method; this code only
uses the PickColor() method, so version 1 suffices.
Then, add support for the Inhibit portal. Use it if available and if
running in a sandbox. Prefer to use org.freedesktop.ScreenSaver if not
running in a sandbox, even if the portal is available, because (at least
in the GNOME 43 implementation of the portal) it does not work correctly
if the portal cannot map the request to a running app. This adds a small
amount of complexity to the implementation, but supporting both APIs is
necessary anyway (there are many systems in the wild that support
org.freedesktop.ScreenSaver but not the desktop portal).
Fixes https://github.com/godotengine/godot/issues/108634
Fixes a timing issue where dialogs got configured right before having
their parent set. This gave compositors the time to resize/rearrange the
dialog as if it were a normal window, only to be marked as "floating"
right away. On niri, this manifested as huge dialog windows.
This is achieved with the addition of a `p_parent_id` parameter to
`window_create`, akin to its popup counterpart.
`window_create` now also accepts a single `Size2i` parameter instead of
two integers, in line with the rest of the `WaylandThread` API. The
original idea was to have a very "barebones" API, akin to the `drivers/`
directory, but that didn't pan out.
This race condition made me pull my hair. `wl_display_roundtrip` has its
own little event loop, which apparently conflicts hard with the
always-running event loop thread.
I kinda assumed that it would be thread-safe thanks to its internal
`wl_display_prepare_read` call that the docs talk about but that's
clearly not enough.
Luckily this method is called very few times and the only dangerous
instances are in the initialization routine, which first starts the
thread and then does various roundtrips. Libdecor has also some internal
roundtrips of its own which would often fail. Starting the thread after
all initialization fixes the issue.
Tested this by spamming *lots* of `wl_display_roundtrip` in
`WaylandThread::init()` with and without this fix.
Without this, the screen does go into idle after a few minutes on a RPi5 with default install (wayland w/ labwc), even
though `screen_keep_on` is set. DBUS is enabled but apparently, the screensaver call is not enough.
The `Vector2i` division operator casts doubles down to `int32_t`. It
would thus truncate the fractional scale factor to 0 if less than 1,
resulting in a FPE on x86_64.
Fixup to "Wayland: Check selection devices before using them"
This slipped under the radar... until for some reason optimized builds
started crashing, perhaps due to timing-related shenanigans, no idea.
Related #106229. The cursor-shape protocol allows us to not have to deal with cursor theming and instead depend on the
compositor for it.
This still does not quite solve the issue when the compositor doesn't implement the protocol
(or running under the x11 backend) but for gnome/kde and a few more this should resolve things.
This issue came from the frame-based refactoring done in the multiwin
PR.
It looks like some (all?) compositors group certain events alongside
`wl_pointer::leave`, which I absolutely did not expect. The docs don't
seem to mention it either from what I can tell.
We now fall-back on the old pointed window if and only if the current
window is invalid and the old one isn't. Each state fetch is guarded
with an `ERR_FAIL_NULL` so this should still catch any potentially
corrupted window with missing data but a valid ID.
I also added the usual big comment so that this "quirk" does not get
lost to time.
In #101774, some libdecor-specific code was added, but without adding the guards. This broke the build with
`libdecor=no`.
Add `#ifdef` guard as necessary.
Before, the WSI was unfortunately quite broken and we had work around it
by manually pacing frames. Needless to say it was not an ideal solution.
Now, the WSI can make use of the new fifo_v1 protocol to work properly.
If it's available, we'll trust the WSI by disabling manual frame pacing.
While we're at it, let's clean up the suspension code a bit by removing
some duplicated stuff and handling the suspension state through a switch
case.
