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.
The Wayland spec says:
> The compositor must send the wl_keyboard.modifiers event after this
event.
We did not during "fake" focus changes (e.g. from/to embedded
applications), effectively resetting the modifier state.
This patch simply tracks keyboard modifiers and informs clients whenever
we send custom enter events.
`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!
From the spec:
> The wl_pointer.enter and wl_pointer.leave events are logical events
> generated by the compositor and not the hardware. These events are
> also grouped by a wl_pointer.frame. When a pointer moves from one
> surface to another, a compositor should group the wl_pointer.leave
> event within the same wl_pointer.frame. However, a client must not
> rely on wl_pointer.leave and wl_pointer.enter being in the same
> wl_pointer.frame. Compositor-specific policies may require the
> wl_pointer.leave and wl_pointer.enter event being split across
> multiple wl_pointer.frame groups.
From my understanding™ this means that a compositor SHOULD group
leave/enter events together. Is this common? From my testing... Not
really. Notably, (only?) KDE does this.
Our pointer frame event assumed that we would be working with the
currently pointed window but since all events must be logically grouped
together I think it can really only group "normal" events related to the
*leave* event.
Now, whenever there's a pointer focus change, we send everything to the
old window, if it exists, otherwise the currently pointed one.
This approach seems to handle complex event frames with both leave and
enter events properly now, with good results on all compositors.
This patch also and makes it harder to get to a null check when the
window simply does not exists (the error was meant only for existing but
invalid windows), along with an helper method to aid in this.
EGL brings in platform-specific headers such as the dreaded `windows.h`,
and `platform_gl.h` is used throughout `drivers/gles3` for basic OpenGL
types such as `GLuint`. We don't want `windows.h` pollution there.
Note for Android: EGL seems used explicitly only via `rasterizer_gles3.cpp`
to enable GL debug printing, and some custom stuff in `config.cpp`.
Fixes#117676
PR #111964 made a Ref<ColorManagementProfile> which we intentionally
leaked across a client-server barrier owned, which caused a use-after-free.
Manually adding reference/unreference calls keeps the ptr valid without memory leaks.
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 now reuse the `global_remove` event handler. This removes a
considerable amount of duplication, minimizes human error (such as
cleaning up a global in one place but not the other), and helps test the
dynamic global removal logic.
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`.
Thaddeus Crews
Naoto Kondo
ArchercatNEO
Dery Almas
Allen Pestaluky
Pāvels Nadtočajevs
Rémi Verschelde
Lukas Tenbrink
Kongfa Waroros