| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| tests-Reinstate-meta_test_get_plugin_name.patch | tests: Reinstate meta_test_get_plugin_name() Another package could conceivably have been relying on this. This partially reverts commit 2a5ad7cb5196e9bdda9c747f8bd881b95b74a8b4. |
Simon McVittie <smcv@debian.org> | no | 2023-08-17 | ||
| tests-Break-up-stacking-installed-tests-into-more-smaller.patch | tests: Break up stacking installed-tests into more, smaller tests Running each stacking test as a separate installed-test is analogous to what was done for build-time tests in c6d1cf4a (!442) and should make it easier to track regressions, by being able to see whether a regression is specific to one .metatest script or applies to more than one. An accidental side-effect of this is that state is not carried over between one test and the next, which makes the workspace-basic test stop crashing (see #2559). (If the same issue can happen in real life, the previous patch mitigates it from a crash to a critical warning.) Accidentally mitigates: https://gitlab.gnome.org/GNOME/mutter/-/issues/2559 Accidentally mitigates: https://bugs.debian.org/1024438 |
Simon McVittie <smcv@debian.org> | yes | 2022-12-18 | ||
| tests-Use-a-more-interoperable-path-to-bash.patch | tests: Use a more interoperable path to bash On systems that have undergone the /usr merge, /bin/bash and /usr/bin/bash can be used interchangeably, but on systems where /bin and /usr/bin are separate (such as Debian 11 or older), bash was traditionally in /bin and there is no bash in /usr/bin. |
Simon McVittie <smcv@debian.org> | yes | upstream | 2023-03-06 | |
| meson-add-back-default_driver-option.patch | meson: add back default_driver option In autotools it was possible to pass the --with-default-driver option to force the usage of a specific cogl driver at build time. Expose this functionality in meson as well |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | invalid | https://gitlab.gnome.org/GNOME/mutter/merge_requests/392 | 2019-01-16 | |
| tests-Mark-view-verification-tests-as-incomplete-in-big-e.patch | tests: Mark view-verification tests as incomplete in big-endian archs Saved pixmaps are invalid in big-endian architectures, so let's disable the tests for now, checking only the basic metadata but not comparing the contents. |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | yes | upstream | 2021-06-15 | |
| theme-load-icons-as-Gtk-does-with-fallback-and-RTL-suppor.patch | theme: load icons as Gtk does with fallback and RTL support | =?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | invalid | 2018-03-30 | ||
| theme-use-gtk_render_icon_suface-to-paint-button-icon.patch | theme: use gtk_render_icon_suface to paint button icon This will properly take care of the icon transformations and of the shadow. Fixes #100 |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | invalid | upstream | 2018-03-30 | |
| debian/backends-native-kms-crtc-Don-t-compare-gamma-values-on-un.patch | backends/native/kms-crtc: Don't compare gamma values on unitialized memory On hotplugs, to check if we had a gamma change we compare the gamma states values, and we assumed that the gamma pointers were initialized by KMS, however drmModeCrtcGetGamma may not set those values, leaving the gamma values not initialized. And this may lead meta_kms_crtc_state_changes() to return wrong values. |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2371 | 2022-04-12 | |
| debian/meson-Do-not-mark-CI-test-tools-as-required.patch | meson: Do not mark CI test tools as required This way we can mark them as nocheck without build issues. |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | 2022-02-18 | ||
| debian/tests-Do-not-run-screencast-tests.patch | tests: Do not run screencast tests They require to have a full running pipewire (that requires a system dbus daemon) so, we can't easily get one up and running while building. So let's disable this for now |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | no | 2021-05-20 | ||
| debian/tests-skip-monitor-width-size-check-as-it-may-lead-to-une.patch | tests: skip monitor width size check as it may lead to unexpected failure This seems to be broken only on autopkg-tests. |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | not-needed | 2022-03-14 | ||
| debian/tests-Tag-unstable-tests-as-flaky.patch | tests: Tag unstable tests as flaky Then test runners can run these ones non-fatally. This is Debian-only: for upstream these tests should be fixed. |
Iain Lane <iainl@gnome.org> | not-needed | 2019-08-14 | ||
| debian/wayland-data-device-Allow-any-drag-timestamp-as-drag-star.patch | wayland-data-device: Allow any drag timestamp as drag start serial In some scenarios under wayland DnD may not work because the start-drag serial is not matching the one we expect for the pointer that we set when handling the button event. This is because since commit 26676a82 we're repeatedly pinging the windows at each event to ensure that they're still alive, but we're using the event timestamp for that, and this makes wayland to use such value as the start-drag serial. To avoid this, let's keep track of all the grab timestamps we got while dragging and accept a serial to match any of these. |
=?utf-8?b?Ik1hcmNvIFRyZXZpc2FuIChUcmV2acOxbyki?= <mail@3v1n0.net> | yes | upstream | 2022-04-06 | |
| triple-buffering/onscreen-native-Tidy-up-secondary-GPU-buffer-tracking.patch | onscreen/native: Tidy up secondary GPU buffer tracking The primary plane of a CRTC can only have one `current_fb` and therefore only one `next_fb`, so don't confuse the situation by maintaining two of each. In the past a single onscreen targeted multiple CRTCs meaning separate tracking was necessary, but not anymore. If we're using `COPY_MODE_ZERO` then the `imported_buffer` will reference the importee internally. We don't need to keep a redundant reference to the old buffer after importation. If we're using `COPY_MODE_PRIMARY` or `COPY_MODE_SECONDARY_GPU` then we only need to keep the final copy for the duration of scanout. All of that happens before the flip so only one `next_fb` needs to live on after the flip. And if there's only one `next_fb` then there's only one `current_fb`. In a related cleanup we now also ensure that `onscreen_native->gbm.next_fb` is only assigned once per frame. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-11-10 | |
| triple-buffering/onscreen-native-Hold-primary-GPU-FBs-for-the-secondary-sc.patch | onscreen/native: Hold primary GPU FBs for the secondary scanout lifetime This is out of an abundance of caution. In cases where we have copied the primary GPU's buffer to a dumb buffer for secondary GPU (DisplayLink) scanout, we don't really know how long OpenGL will take to complete that copy in the background. And there is no swap buffers or locking of the secondary GPU front buffer to guarantee when. So to avoid needing `glFinish` or similar we now reference the original source FB for the scanout lifetime of the secondary (dumb) buffer. This is effectively identical to the pre-!2087 behaviour. Although it's not theoretically optimal because the primary GPU FB is not needed after scanout starts (`next_fb` is moved to `current_fb`), this approach does give us the simplicity of only having to track the lifetime of a single buffer after it is flipped. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-01-19 | |
| triple-buffering/kms-update-Hold-a-reference-to-the-buffer-used-in-a-plane.patch | kms/update: Hold a reference to the buffer used in a plane assignment | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-16 | |
| triple-buffering/kms-crtc-Add-an-API-to-hold-references-to-buffers-while-a.patch | kms/crtc: Add an API to hold references to buffers while asssigned to planes | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-16 | |
| triple-buffering/kms-page-flip-Pump-the-CRTC-s-buffer-reference-queue-on-s.patch | kms/page-flip: Pump the CRTC's buffer reference queue on scanout Precise timing of this call is not important. We only need to notify that the *previous* scanout is definitely no longer happening. So any old buffers no longer used in the latest scanout can be released. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-17 | |
| triple-buffering/kms-impl-device-Release-buffers-from-MetaKmsCrtc-in-prepa.patch | kms/impl-device: Release buffers from MetaKmsCrtc in prepare_shutdown This allows them to release their buffers cleanly while all the associated resources to do the release still exist. Otherwise we might crash later in meta_drm_buffer_finalize. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-02-09 | |
| triple-buffering/kms-impl-device-simple-Pump-the-CRTC-s-buffer-reference-q.patch | kms/impl-device/simple: Pump the CRTC's buffer reference queue on scanout In this case "on scanout" means when `drmModeSetCrtc` succeeds. This is the only case where there won't be a `meta_kms_page_flip_data_flipped` to do it for us. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-12-07 | |
| triple-buffering/kms-impl-device-simple-Keep-a-reference-to-buffers-assign.patch | kms/impl-device/simple: Keep a reference to buffers assigned to planes The MetaKmsCrtc will hold these references during future scanouts until such time as a new buffer is assigned to the plane AND another scanout has occurred after that. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-17 | |
| triple-buffering/kms-impl-device-simple-Keep-a-reference-to-buffers-needed.patch | kms/impl-device/simple: Keep a reference to buffers needed in retries | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-12-07 | |
| triple-buffering/kms-impl-device-atomic-Keep-a-reference-to-buffers-assign.patch | kms/impl-device/atomic: Keep a reference to buffers assigned to planes The MetaKmsCrtc will hold these references during future scanouts until such time as a new buffer is assigned to the plane AND another scanout has occurred after that. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-17 | |
| triple-buffering/onscreen-native-Stop-holding-the-current-onscreen-buffer.patch | onscreen/native: Stop holding the current onscreen buffer The scanout lifetime of the buffer is now automatically managed via meta_crtc_kms_assign_primary_plane. Se we don't need `current_fb` at all, and `next_fb` can be unreferenced as soon as we've passed it to meta_crtc_kms_assign_primary_plane. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-18 | |
| triple-buffering/onscreen-native-Keep-the-onscreen-alive-longer-than-MetaD.patch | onscreen/native: Keep the onscreen alive longer than `MetaDrmBufferGbm` Because `MetaDrmBufferGbm` uses `gbm_surface` in its destructor and `gbm_surface` can't be refcounted directly. So we reference its owner (the onscreen) instead. This avoids a crash that can otherwise occur when hotplugging monitors as the old onscreen might get disposed before the new onscreen has presented a replacement frame on the same `MetaKmsCrtc`. We could instead wrap and refcount all users of `gbm_surface`, but that would be a lot more work for no additional benefit right now. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-24 | |
| triple-buffering/cursor-renderer-native-Stop-holding-onto-historical-curso.patch | cursor-renderer/native: Stop holding onto historical cursor buffers Their scanout lifetimes are now managed automatically via the call to meta_kms_update_assign_plane. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-18 | |
| triple-buffering/cursor-renderer-native-Remove-MetaCursorBufferState.patch | cursor-renderer/native: Remove MetaCursorBufferState It was theoretically useful for flagging when a NULL buffer had been SET, but in practice set_cursor_sprite_buffer is never called when the buffer is NULL. So we can instead just compare the buffer with NULL to tell when it is valid. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-18 | |
| triple-buffering/cogl-onscreen-Add-function-cogl_onscreen_count_pending_fr.patch | cogl/onscreen: Add function cogl_onscreen_count_pending_frames | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-17 | |
| triple-buffering/kms-Keep-a-shutting_down-flag.patch | kms: Keep a shutting_down flag | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-04-20 | |
| triple-buffering/renderer-native-Avoid-requeuing-the-same-onscreen-for-a-p.patch | renderer/native: Avoid requeuing the same onscreen for a power save flip This is a case that triple buffering will encounter. We don't want it to queue the same onscreen multiple times because that would represent multiple flips occurring simultaneously. It's a linear search but the list length is typically only 1 or 2 so no need for anything fancier yet. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-10-26 | |
| triple-buffering/renderer-native-Steal-the-power-save-flip-list-before-ite.patch | renderer/native: Steal the power save flip list before iterating over it Because a single iteration might also grow the list again. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-11-01 | |
| triple-buffering/onscreen-native-Log-swapbuffers-and-N-buffering-when-MUTT.patch | onscreen/native: Log swapbuffers and N-buffering when MUTTER_DEBUG=kms | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-12-10 | |
| triple-buffering/onscreen-native-Replace-an-assertion-that-double-bufferin.patch | onscreen/native: Replace an assertion that double buffering is the maximum Because it soon won't be the maximum. But we do want to verify that the frame info queue is not empty, to avoid NULL dereferencing and catch logic errors. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-07-28 | |
| triple-buffering/onscreen-native-Deduplicate-calls-to-clutter_frame_set_re.patch | onscreen/native: Deduplicate calls to clutter_frame_set_result All paths out of `meta_onscreen_native_swap_buffers_with_damage` from here onward would set the same `CLUTTER_FRAME_RESULT_PENDING_PRESENTED` (or terminate with `g_assert_not_reached`). Even failed posts set this result because they will do a `meta_onscreen_native_notify_frame_complete` in `page_flip_feedback_discarded`. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-16 | |
| triple-buffering/onscreen-native-Split-swap_buffers_with_damage-into-two-f.patch | onscreen/native: Split swap_buffers_with_damage into two functions 1. The EGL part: meta_onscreen_native_swap_buffers_with_damage 2. The KMS part: post_latest_swap |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-07-28 | |
| triple-buffering/onscreen-native-Warn-instead-of-crashing-if-posting-witho.patch | onscreen/native: Warn instead of crashing if posting without an update | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-12 | |
| triple-buffering/onscreen-native-Add-a-missing-frame-notification.patch | onscreen/native: Add a missing frame notification In the unlikely event that swap_buffers_with_damage drops the previous swap it was forgetting to notify about the discarded frame. That could lead to frame clock freezes. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-10-28 | |
| triple-buffering/onscreen-native-Defer-posting-if-there-s-already-a-post-i.patch | onscreen/native: Defer posting if there's already a post in progress And when the number of pending posts decreases we know it's safe to submit a new one. Since KMS generally only supports one outstanding post right now, "decreases" means equal to zero. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-17 | |
| triple-buffering/onscreen-native-Keep-a-reference-to-the-CRTC-used.patch | onscreen/native: Keep a reference to the CRTC used Otherwise it may get destroyed during hotplug events. Meanwhile we're still active and might try using it in the next/final frame notification callbacks. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-11-02 | |
| triple-buffering/onscreen-native-Add-function-meta_onscreen_native_discard.patch | onscreen/native: Add function meta_onscreen_native_discard_pending_swaps | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-11-04 | |
| triple-buffering/onscreen-native-Skip-try_post_latest_swap-if-shutting-dow.patch | onscreen/native: Skip try_post_latest_swap if shutting down Otherwise we could get: meta_kms_prepare_shutdown -> flush_callbacks -> ... -> try_post_latest_swap -> post and queue more callbacks So later in shutdown those callbacks would trigger an assertion failure in meta_kms_impl_device_atomic_finalize: g_hash_table_size (impl_device_atomic->page_flip_datas) == 0 Also remember to discard_pending_swaps to break the circular reference between MetaOnscreenNative and its next_fb caused by the association "gbm_surface owner". Or else that would trigger another assertion failure: meta_device_pool_finalize: runtime check failed: (!pool->files) |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-05-11 | |
| triple-buffering/renderer-native-Discard-pending-swaps-when-rebuilding-vie.patch | renderer/native: Discard pending swaps when rebuilding views It's analogous to discard_pending_page_flips but represents swaps that might become flips after the next frame notification callbacks, thanks to triple buffering. Since the views are being rebuilt and their onscreens are about to be destroyed, turning those swaps into more flips/posts would just lead to unexpected behaviour (like trying to flip on a half-destroyed inactive CRTC). |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-11-04 | |
| triple-buffering/clutter-frame-clock-Lower-the-threshold-for-disabling-err.patch | clutter/frame-clock: Lower the threshold for disabling error diffusion Error diffusion was introduced in 0555a5bbc15 for Nvidia where last presentation time is always unknown (zero). Dispatch times would drift apart always being a fraction of a frame late, and accumulated to cause periodic frame skips. So error diffusion corrected that precisely and avoided the skips. That works great with double buffering but less great with triple buffering. It's certainly still needed with triple buffering but correcting for a lateness of many milliseconds isn't a good idea. That's because a dispatch being that late is not due to main loop jitter but due to Nvidia's swap buffers blocking when the queue is full. So scheduling the next frame even earlier using last_dispatch_lateness_us would just perpetuate the problem of swap buffers blocking for too long. So now we lower the threshold of when error diffusion gets disabled. It's still high enough to fix the original smoothness problem it was for, but now low enough to detect Nvidia's occasionally blocking swaps and backs off in that case. Since the average duration of a blocking swap is half a frame interval and we want to distinguish between that and sub-millisecond jitter, the logical threshold is halfway again: refresh_interval_us/4. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-08-10 | |
| triple-buffering/clutter-frame-clock-Merge-states-DISPATCHING-and-PENDING_.patch | clutter/frame-clock: Merge states DISPATCHING and PENDING_PRESENTED Chronologically they already overlap in time as presentation may complete in the middle of the dispatch function, otherwise they are contiguous in time. And most switch statements treated the two states the same already so they're easy to merge into a single `DISPATCHED` state. Having fewer states now will make life easier when we add more states later. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2020-07-24 | |
| triple-buffering/clutter-frame-clock-Add-triple-buffering-support.patch | clutter/frame-clock: Add triple buffering support | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2020-09-10 | |
| triple-buffering/clutter-frame-clock-Log-N-buffers-in-CLUTTTER_DEBUG-frame.patch | clutter/frame-clock: Log N-buffers in CLUTTTER_DEBUG=frame-timings | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-12-10 | |
| triple-buffering/clutter-frame-clock-Don-t-clamp-compute_max_render_time_u.patch | clutter/frame-clock: Don't clamp compute_max_render_time_us Because values over refresh_interval_us are real and valid. They tell us when we're not keeping up. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-12-13 | |
| triple-buffering/clutter-frame-clock-Subtract-buffer-queue-latency-from-ma.patch | clutter/frame-clock: Subtract buffer queue latency from max_swap_to_flip_us swap_to_flip times were getting stuck at over one frame interval because of a positive feedback loop with triple buffering. The moment triple buffering started it would cause swap_to_flip times to exceed one frame interval. Then that high value would feed back through max_render_time which in turn ensured triple buffering continued which ensured swap_to_flip stayed over one frame interval. So even when actual GPU render times became low we were stuck with a high value of max_render_time and stuck in triple buffering when we should have switched to double buffering. By subtracting the constant buffer queue latency from max_swap_to_flip_us we break this positive feedback loop and only include real performance measurements. So now the frame clock is able to drop back to double buffering when appropriate. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-02-17 | |
| triple-buffering/clutter-frame-Add-ClutterFrameHint-to-ClutterFrame.patch | clutter/frame: Add ClutterFrameHint to ClutterFrame This will allow the backend to provide performance hints to the frame clock in future. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-07 | |
| triple-buffering/backends-Flag-that-the-frame-attempted-direct-scanout.patch | backends: Flag that the frame attempted direct scanout We need this hint whether direct scanout succeeds or fails because it's the mechanism by which we will tell the clock to enforce double buffering, thus making direct scanout possible on future frames. Triple buffering will be disabled until such time that direct scanout is not being attempted. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-07 | |
| triple-buffering/clutter-Pass-ClutterFrameHint-s-to-the-frame-clock.patch | clutter: Pass ClutterFrameHint(s) to the frame clock | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-07 | |
| triple-buffering/clutter-frame-clock-Throttle-back-to-double-buffering-for.patch | clutter/frame-clock: Throttle back to double buffering for direct scanout There's no compositing during direct scanout so the "render" time is zero. Thus there is no need to implement triple buffering for direct scanouts. Stick to double buffering and enjoy the lower latency. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-07 | |
| triple-buffering/clutter-frame-clock-Add-env-var-MUTTER_DEBUG_DISABLE_TRIP.patch | clutter/frame-clock: Add env var MUTTER_DEBUG_DISABLE_TRIPLE_BUFFERING You can set environment variable MUTTER_DEBUG_DISABLE_TRIPLE_BUFFERING=1 to disable triple buffering. This shouldn't ever be needed except when debugging. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-03-10 | |
| triple-buffering/kms-Keep-a-hash-table-of-CRTCs-relating-to-the-KmsUpdate.patch | kms: Keep a hash table of CRTCs relating to the KmsUpdate This will allow more efficient lookup than linear searching each of the GLists. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-22 | |
| triple-buffering/kms-Map-ensure_connector_update-to-a-specific-CRTC-if-act.patch | kms: Map ensure_connector_update to a specific CRTC if active Otherwise the connector update gets orphaned and never committed: https://launchpad.net/bugs/1966178 Although I wonder if there's a nicer way to decide when to apply connector updates (i.e. not reliant on swap buffers). |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-04-13 | |
| triple-buffering/kms-Add-functions-meta_kms_update_include-s-_crtc.patch | kms: Add functions meta_kms_update_include[s]_crtc() | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-22 | |
| triple-buffering/kms-Add-per-CRTC-update-functions.patch | kms: Add per-CRTC update functions | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2021-09-22 | |
| triple-buffering/cursor-renderer-native-Use-CRTC-specific-update-retrieval.patch | cursor-renderer/native: Use CRTC-specific update retrieval | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-01-28 | |
| triple-buffering/crtc-native-Use-CRTC-specific-update-retrieval.patch | crtc/native: Use CRTC-specific update retrieval | Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-01-28 | |
| triple-buffering/onscreen-native-Use-CRTC-specific-update-retrieval.patch | onscreen/native: Use CRTC-specific update retrieval For mode setting we want all CRTCs to share the same MetaKmsUpdate, but after that we don't want them to share the same update for regular flips and cursor movement. The reason being that different CRTCs are attached to different displays with different clocks. So each CRTC would finish the same update at slightly different times. If you wait for all CRTCs to complete a shared update then you have waited half a frame on average, possibly more. This waiting would consume most of the render time for the next frame and risk stuttering. If you only wait for one CRTC to complete a shared update then the next shared update may be posted before other CRTCs have finished the last, so the next update would fail due to those other CRTCs still being busy. So the only safe answer for maintaining full framerate of multiple outputs is to ensure unsynchronized CRTCs don't share the same update. At least not after mode setting. This fixes a multi-monitor bug for atomic KMS whereby `meta_onscreen_native_finish_frame` would fail its post because it was trying to commit a cursor update on the wrong (busy) CRTC. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-01-28 | |
| triple-buffering/tests-native-kms-render-Fix-failing-client-scanout-test.patch | tests/native-kms-render: Fix failing client-scanout test It was assuming an immediate transition from compositing (triple buffering) to direct scanout (double buffering), whereas there is a one frame delay in that transition as the buffer queue shrinks. We don't lose any frames in the transition. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-06-30 | |
| triple-buffering/kms-Avoid-queuing-multiple-un-assignments-to-the-same-pla.patch | kms: Avoid queuing multiple (un)assignments to the same plane in an update Just like we already do in `meta_kms_update_assign_plane`. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-09-08 | |
| triple-buffering/onscreen-native-Increase-secondary-GPU-dumb_fbs-from-2-to.patch | onscreen/native: Increase secondary GPU dumb_fbs from 2 to 3 So that they don't get overwritten prematurely during triple buffering causing tearing. https://launchpad.net/bugs/1999216 |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2022-12-09 | |
| triple-buffering/clutter-frame-clock-Target-the-correct-next_presentation_.patch | clutter/frame-clock: Target the correct next_presentation_time_us Where "correct" means a different time to when we expect the previous update(s) to present. Otherwise we get stuck in triple buffering for too long by scheduling the next update earlier than necessary. This logic error has existed for a long time but it worked because prior to triple buffering, `calculate_next_update_time_us` would only ever be called from the `IDLE` state. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2023-02-03 | |
| triple-buffering/clutter-frame-clock-Fall-back-to-triple-buffering-not-dou.patch | clutter/frame-clock: Fall back to triple buffering, not double buffering When the driver doesn't support GPU timestamps (Xorg, Raspberry Pi, others) https://launchpad.net/bugs/2017137 https://launchpad.net/bugs/2017097 |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2023-04-24 | |
| triple-buffering/clutter-frame-clock-Avoid-rapidly-toggling-dynamic-max-re.patch | clutter/frame-clock: Avoid rapidly toggling dynamic max render time This could happen when moving the cursor over GUIs that only redraw in response to cursor movement. Mutter would experience alternating cursor-only updates and page flips, and so the `max_render_time_allowed_us` would jump between pessimised and optimised resulting in inconsistent frame pacing. Aside from fixing the smoothness problem this should also provide lower latency cursor movement. (cherry picked from commit be0aa2976e19f4a6b91bd90ce3942d6b107af7c0) |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2023-06-14 | |
| triple-buffering/clutter-frame-clock-Record-measurements-of-zero-for-curso.patch | clutter/frame-clock: Record measurements of zero for cursor-only updates But only if we've ever got actual swap measurements (COGL_FEATURE_ID_TIMESTAMP_QUERY). If it's supported then we now drop to double buffering and get optimal latency on a burst of cursor-only updates. |
Daniel van Vugt <daniel.van.vugt@canonical.com> | no | https://gitlab.gnome.org/Community/Ubuntu/mutter/-/commits/triple-buffering-v4-43 | 2023-07-18 | |
| debian/tests-Disable-restore-size-test.patch | tests: Disable restore-size test This intermittently fails on x86 and consistently fails on 32-bit ARM. Workaround for https://gitlab.gnome.org/GNOME/mutter/-/issues/2509 |
Simon McVittie <smcv@debian.org> | not-needed | upstream | 2022-11-15 | |
| workspace-Don-t-crash-on-invalid-argument-to-meta_workspa.patch | workspace: Don't crash on invalid argument to meta_workspace_index | Simon McVittie <smcv@debian.org> | yes | debian upstream | 2022-12-18 | |
| debian/Mark-xwayland-test-case-as-known-to-be-flaky-on-32-bit-AR.patch | Mark xwayland test case as known to be flaky on 32-bit ARM | Simon McVittie <smcv@debian.org> | no | debian | 2022-12-20 | |
| cursor-renderer-native-Workaround-broken-arm64-drivers.patch | cursor-renderer-native: Workaround broken arm64 drivers By forcing cursors to use dumb buffers. At least until Mesa gets fixed for panfrost, vc4, v3d... |
Daniel van Vugt <daniel.van.vugt@canonical.com> | yes | upstream | 2022-11-04 |