I hit this rare error running the "x11" test from the suite locally:
(mutter:194027): Gdk-ERROR **: 18:21:52.525: The program 'mutter' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 663 error_code 9 request_code 143 (DAMAGE) minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The only call from the Damage extension in use by Mutter that could
return BadDrawable is XDamageCreate(), and it's likely to be this
call. Wrap this X11 in an error trap, in order to catch possible
failures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2793>
Flushing the input thread might implicitly iterate the mainloop, and thus
update the stage while still inside the clutter_test_flush_input() call.
This means the stage update has already happened when we call
wait_stage_updated(), and that's why we call clutter_stage_schedule_update()
there currently.
This clutter_stage_schedule_update() call is not necessary though, instead
we can flush the input thread from inside wait_stage_updated() after
setting was_updated to FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2792>
If the window is unmapped or otherwise unmanaged while still existing,
we would fail to let the frames client follow up in destroying the
frame for the window.
Delete the _MUTTER_NEEDS_FRAME property, so that the frames client
can react to meta_window_destroy_frame(), this avoids stale invisible
frame windows for clients that simply unmap windows to reuse them
later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2791>
Recent versions of Xwayland can allow or disallow X11 clients from
different endianess to connect.
Add a setting to configure this feature from mutter, who spawns
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785>
This define was dropped by commit 0e8aaebc00 (xwayland: Make
XSetIOErrorExitHandler() mandatory), but some #ifdef checks were
brought back by commit 36f30341ac (wayland: Add a prepare-shutdown
signal).
Since there's no define anymore in config.h, these pieces of code
were unintentionally disabled, and a meta_get_display() call be
also left over. Remove the ifdefs and update the code to build
again.
Fixes: 36f30341ac - wayland: Add a prepare-shutdown signal
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2786>
This XChangeWindowAttributes call was never surrounded by an error trap
and was not really expected to fail with BadWindow since the frame window
would be owned by Mutter itself.
This however is no longer true, and we might be getting a BadWindow from
the frame window given the right timing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
Commit 4e0ffba5c attempted to fix initialization of keyboard a11y,
but mousekeys do attempt to create a virtual input device at a
time that it is too early to try to create one.
Defer this operation until keyboard devices are added, so that
we are ensured to already have the seat input thread set up.
Fixes: 4e0ffba5c - backends/native: Initialize keyboard a11y on startup
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2778>
Quoting Carlos:
The META_PRIORITY_EVENTS ± 1 happening below are in order to set these idles
and timeouts in a priority that is relative to the literal GDK event priority,
making those diverge is a likely way to sneakily break things.
But that's unlikely to happen, and decoupling mutter from GTK further
should make it moot, so perhaps it's alright after all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Clutter has an API to get the text direction but used to depend
on gtk3's translation domain. In order to avoid broken i18n
in case gtk3 is not installed, move the transtalable string to
clutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Now that dynamic max render time uses a new algorithm and takes dispatch
lateness into account, this seems worth a shot. We'll see how it works
out in the wild.
The net result compared to before these changes is still slightly higher
(by ~0.5 ms) minimum latency for me, as measured by
weston-presentation-shm. It should be less vulnerable to frame drops
though.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2500>
Store only two values per kind of duration: The short term and long term
maximum.
The short term maximum is updated in each frame clock dispatch. The long
term maximum is updated at most once per second: If the short term
maximum is higher, the long term maximum is updated to match it.
Otherwise, a fraction of the delta between the two maxima is subtracted
from the long term maximum.
Compared to the previous algorithm:
* The calculcations are simpler.
* The calculated max render time has a slow exponential drop-off (by at
most a few milliseconds every second) instead of potentially abruptly
dropping after as few as 16 frames.
This should fix https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4830
since the short term maximum should always include a sample from the
clock's second tick.
v2:
* Use divisor 2 instead of 4.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2500>
Dispatch lateness is the difference between when we wanted frame clock
dispatch to run and when it actually started running. This can be up to
1ms even under normal circumstances due to process scheduling
granularity, or even higher under load.
This keeps track of dispatch lateness of the last 16 frame clock
dispatches, and incorporates the maximum into the dynamic render time
estimate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2500>
There are two tests; one checks that clearing with a color that cannot
be represented using 8 bits per channel doesn't loose precision when
painted, then read back using glReadPixels(). Would the texture backing
store have 8 bits per channel instead of 10, we'd get a different value
back.
The other test checks that painting from one fbo to another also doesn't
loose that precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
