While having automatic completions is a very nice feature of gdctl (I
had suggested to use it too :)), it's not something that distros may
have by default and in particular it's not a package in main in ubuntu.
So, make the code less restrictive on completions, since completions is
not a core functionality of the tool and it can definitely work without
them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4279>
While the `get_key_focus()` method returned the stage itself when
no explicit focus was set, it made sense for the corresponding
setter to accept the stage as synonym for NULL.
But now that the getter always returns the property value, it
makes more sense to expect NULL to unset the key focus.
Keep the current behavior of normalizing the key focus to NULL
in that case to minimize breakage, but print a warning to
use NULL instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4256>
Moving the key focus to the stage should be done by unsetting the
focus rather than setting it to the stage itself.
`clutter_stage_set_key_focus()` already "normalizes" the stage to
NULL internally, so this does not change the actual behavior of the
code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4256>
The method currently returns the stage itself when the property
is NULL.
This has become particularly problematic as the method is detected
as getter by gobject introspection, and gjs now optimizes property
accesses by calling the getter method instead.
Address this by turning the method into a genuine getter without
falling back to the stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4256>
While the existing `get_key_focus()` methods looks like a getter of the
`key-focus` property and is detected as such by gobject introspection,
it behaves differently in that it returns the stage if no explicit
focus has been set.
This is about to change, so adjust the couple of cases that rely
on the fallback to the stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4256>
Previously if we had no measurements then `compute_max_render_time_us`
would pessimise its answer to ensure triple buffering could be reached:
if (frame_clock->state >= CLUTTER_FRAME_CLOCK_STATE_DISPATCHED_ONE)
ret += refresh_interval_us;
But that also meant entering triple buffering even when not required.
Now we make `compute_max_render_time_us` more honest and return failure
if the answer isn't known (or is disabled). This in turn allows us to
optimize `calculate_next_update_time_us` for this special case, ensuring
triple buffering can be used, but isn't blindly always used. So when
TIMESTAMP_QUERY support is missing we now take the same path as if
presentation timestamps are missing (introduced in 56fc09151d and
improved in 0555a5bbc1), which has the benefit of naturally switching
from double to triple buffering as required without actually having to
measure render times.
This makes a visible difference to the latency when dragging windows in
Xorg, but will also help Wayland sessions on platforms lacking
TIMESTAMP_QUERY such as Raspberry Pi.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
This replaces the DISPATCHED state with new sub-states that are possible
with triple buffering:
DISPATCHED_ONE: Double buffering
DISPATCHED_ONE_AND_SCHEDULED: Scheduled switch to triple buffering
DISPATCHED_ONE_AND_SCHEDULED_NOW: Scheduled switch to triple buffering
DISPATCHED_ONE_AND_SCHEDULED_LATER: Scheduled switch to triple buffering
DISPATCHED_TWO: Triple buffering
Triple buffering is currently disabled until the test cases get updated to
handle it in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
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.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
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.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Although since all SCHEDULED* states basically have the same transitions
it's easier to show them as a single state. The mermaid diagram also won't
render correctly if there is a mix of combined and singular states. We
must use either always combined states or always singular states.
Fixes: 5b214dc2b7 ("clutter/frame-clock: Allow scheduling an update in the future")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
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).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
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`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
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.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1441>
Introduces two new NamedTuples to deal with dimensions and positions.
The position is special in that x and y can be None. This was previously
wrongly declared to be only int. This commit fixes instances mypy found
where None positions were not handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4267>
It's not a single-element-tuple but something we can iterate and
produces strings.
Also ignore typing for the requests module because we'd have to install
more things for it to be available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4267>
Now with the new parsing mechanism we are able to set `Super` as
default for overlay-key. The parsing of the `Super` string will
fail at the new mechanism will kick in by appending `_L` and `_R`.
The parsing of the new two strings then will succeed and we will
be able to use both Super_L and Super_R to activate the overview.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
The overlay-key and locate-pointer-key are special keys. They
can be used together with other keys to create a combo or they
can be used as a single key. This means that we are treating a
modifier key as a regular key while still allowing to use it as
part of a combo. This requires a special treatment that we can't
extend to an arbitrary list of keys.
However, we would like to use both Super_L and Super_R to
activate the overview. In order to allow this, introduce a new
parsing mechanism. With the new mechanism, if we fail to parse
the configured string, we will try to parse again by appending
_L first and _R later. If both succeed then we will use their
combos for handling the special key.
With this in place, we can configure Super as overlay-key. The
parsing of Super will fail, but Super_L and Super_R will succeed.
Allowing us to use both.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1277
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
The second combo is still disabled. This is in preparation for a
subsequent commit that is going to parse the preference in a
different way and might end up with two combos defined.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
Special keys are going to be represent by up to two combos. This
functions is able to handle them by adding all the keycodes that
these combos resolve to. Special keys don't have modifiers, so there
is no need to devirtualize them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
This function allows, given an array of combos, to get all the
keycodes associated with them. Right now it is used for just
one combo, but will be used for two combos in order to handle
special keys like the overlay-key and the locate-pointer-key.
As it is now, this function is still useful for aggregate the
GArray creation/destruction in a single place.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
See 44269e6a1dadb643af3a748c2bcca04ac1ab72eb. The function
add_keycodes_for_keysym() is going to be called more than
once on purpose and we want the keycodes do be appended to
a non-empty GArray.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
We are going to need to call this function more than once to add
all the keycodes to the same GArray. Switch to handle GArrays and
rename the function in order to give a hint that keycodes are going
to be added to the passed GArray.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
We use them in a single place, there is no need to internally keep
track of them. The MetaKeyBindingManager has their resolved key
combo (overlay_resolved_key_combo and locate_pointer_resolved_key_combo)
which is enough. Get the special binding combos from the preference
right away when needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4050>
