Previously the Wayland display server would attempt to enable
HDR output and try to detect if it failed afterwards which had some issues.
Now we can query the rendering driver for support and avoid ever enabling
HDR output when this would fail.
`DisplayServer::get_mouse_position` expects global values, but input
usually works in surface-local coordinates.
Previously, we queried WaylandThread directly and transformed the mouse
position when requested, which was somewhat racy. We now instead keep
track of the transformed position while dispatching input events (as the
whole context is there) and return that when requested.
Unlike Godot, Wayland doesn't have the concept of a single "mouse".
Because of this, we could easily emit "mouse enter/exit" events in weird
ways by e.g. using the tablet while using the mouse. This became even
easier to break with the addition of touch support.
This patch does its best to avoid this by tracking a single "hovered
window" and emitting events based on that. This logic is split between
`WaylandThread` and `DisplayServerWayland`:
* `WaylandThread` does all the "smart" tracking and makes sure that, as
long as there's *any* device pointing something, the hovered window will
be set to something. For example: if I have a pointer on a window and
quickly tap anything, the hover will switch to whatever is under the
pointer instead of getting unset once my finger lifts from the screen.
* `DisplayServerWayland` actually applies the hover change. This is
tricky as window event dispatching has side effects and might even
delete windows or change the hover itself!
We now pass the buffer scale along the window size to the display server
and set everything from there.
This should avoid races where the buffer scale changes while we handle
window rect changes.
We assumed that a window will be ready after a single roundtrip but
that's actually not guaranteed by the XDG shell protocol.
This patch waits for an arbitrary timeout (10s) before erroring out and
forcefully closing the window. Since this exercised quite some code
paths, it also reworks some window handling logic and fixes a bunch of
synchronization issues.
This will allow decoupling `display_server.h` from a number of headers in the
codebase which only require those enums and not all the DisplayServer API.
A number of headers in the codebase included `rendering_server.h` just for
some enum definitions. This means that any change to `rendering_server.h` or
one of its dependencies would trigger a massive incremental rebuild.
With this change, we decouple a number of classes from `rendering_server.h`,
greatly speeding up incremental rebuilds for that area.
On my machine, this reduces incremental compilation time after an edit of
`rendering_server.h` by 60s (from 2m57s).
- Removes `native_menu.h` dependency from `display_server.h`.
It's now forward-declared in all DisplayServer implementations and should
be included in the .cpp's.
- Removes some unused `rb_set.h` and `rb_map.h` dependencies, which leads to
having to include them explicitly in half the scene and editor codebase...
which shows how much we depend on `display_server.h`.
- Forward-declare `input_event.h`, so now we need only `keyboard.h`.
`DisplayServer::window_set_size` is called lots of times in the code,
with the assumption (I suppose) that it's going to be idempotent.
We had checks in _update_window_rect but we still called
`WaylandThread::window_set_size`, which did a lot of stuff. In
particular, this caused issues with HiDPI as it "overrode" the window
size before it had a time to figure out its scale.
Despite what I thought in the past, it is allowed, as long as we follow
certain limitations depending on the toplevel's state.
As usual I peppered the code with comments expaining what those
limitations are.
Regarding popups, AFAICT there are no major limitations, although we
should eventually use the new `reposition` method, which autoadjusts the
popup to follow the screen's borders and whatnot. I didn't do that in
this patch as it requires some elbow grease, especially if we want to do
it synchronously.
Makes it more consistent with the rest of the `WaylandThread` methods
(so that we can silently check for the window's existence).
Fixes errors when trying to capture the pointer when no surface has been
pointed yet (its logic assumed that this method was silent).
We double-check everywhere anyway but I added it in some places where we
can't either guarantee that it'll check (to avoid segfaults) or that
would be useful to report directly.
Previously we had different logic for direct key presses and client-side
key repetition, as one queued up input events and the other dispatched
them directly (client-side key repetition is run from the main thread).
I kinda figured out that this difference doesn't really matter, as we
can queue them up before the thread message dispatching logic. That's
exactly what we do now, which allows us to make a single method for both
of them, making the code much clearer and simplifying future maintenance.
This patch also includes a tiny fixup in the compose logic, which checks
for the validity of the generated key event before actually working with
it. The cases in which we can end up with an invalid reference are very
few, so it's not the end of the world, but it's still absolutely a good
idea to check, to avoid nasty surprises down the line.
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.
Thaddeus Crews
ArchercatNEO
Dery Almas
Allen Pestaluky
Pāvels Nadtočajevs
Rémi Verschelde
Kiisu_Master
Nintorch
Dario
Riteo Siuga
metamuffin
Will Thompson
chocola-mint