There are two "focus lost" signals in the Godot X11 display server:
1. `FocusOut` - native X11 signal
2. `NOTIFICATION_APPLICATION_FOCUS_OUT` - Godot signal after 250ms of
no other window getting focus.
When focus is lost, the intent is to clear any input pressed events so
that, when focus returns, we have a clean slate.
The bug is that the pressed events are (attempted to be) cleared on the
first signal, X11's `FocusOut`. This is always a no-op because it
returns early if the application still has focus. Godot's X11 server
only sets that flag after the second signal, not the first.
Move the pressed event clearing from the first signal handler to the
second. This makes clearing pressed events do what it says.
This does not affect Wayland because it does not have the 250ms grace
period.
Simple repro is to load any 3D scene, hold 'W' and, while 'W' is held,
click on any non-Godot window. Release 'W', click back to Godot, and
hold RMB. It will zoom forward as if 'W' is still pressed.
After the fix, the same test has RMB look around as expected when no
other keys are pressed.
Fixes#118897
Godot suppresses X11 BadWindow errors during some operations because
they can occur with normal usage.
X11 errors are asynchronous. Sometimes, when a BadWindow error is sent,
it is dequeued after the original non-BadWindow-suppressing error
handler has been restored. This results in an error callstack being
shown to the user.
Call `XSync` before restoring the original error handler. This ensures
that any queued BadWindow errors go to the suppressing handler.
Fixes#117814
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.
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.
An input method is not required for the application to run.
However, it is still assumed that the user requires an input method
for text input; therefore, in order to avoid generating spam, a warning
is issued only once whenever the input method becomes inactive.
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.