For secondary GPU rendering contexts we currently might choose an EGL
config with a format which is not supported on all primary planes. The
renderer is created when a GPU is detected and lighting up outputs and
thus assigning CRTC and primary planes can happen at any point after
that. This means we have to make sure that all possible plane
assignments will work with the rendering context when we create it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3235
Fixes: cc7bca073 ("crtc/kms: Dynamically assign primary and cursor planes")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3512>
It can be used to force a specific RGB range. Some monitors don't follow
the specification and expect a signal different from what we send. This
property allows to force a mode which hopefully then works correctly for
the sink.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3535>
A ring will naturally go from 355 degrees to 5 degrees (or vice versa),
giving us the illusion of a direction change. Avoid this by assuming
that any change larger than 180 degrees is actually the equivalent
smaller change in the other direction.
Closes#1885
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3545>
BTN_STYLUS is the lower one and traditionally (read: in X) maps to
middle button (2), BTN_STYLUS2 is the upper one and traditionally maps
to right button (3).
This is also what GTK does and our desktop actions too map MIDDLE to
BTN_STYLUS and RIGHT to BTN_STYLUS2.
See also gtk!6168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3541>
The code that maybe flushed IM state before processing a key event
became ineffective at commit 7716b62fa2, since the handle_event()
method on MetaWaylandTextInput won't handle key events, only IM
events and touch/button press events causing IM state to be
committed. Basically, the events that directly change the IM state.
Move this ineffective code to the the filter_event() method handling
the key presses in order to let the IM maybe filter them, and handle
them so that any key event that is let through (both key events
previously injected by the IM, and key events that the IM chooses to
ignore) will ensure that the pending IM state is flushed before the
key event is handled and emitted to the client.
This brings back lost guarantees of orderly event emission when IMs
alternate key events and IM actions.
Fixes: 7716b62fa2 ("clutter: Separate ClutterInputFocus event processing and filtering")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3090
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3536>
adwaita-icon-theme updated its cursor metaphors and changed all DnD
cursors to use arrows instead of hands, except for the grab related
ones. Mutter was using "grabbing" as default DnD cursor, which now
does not match the other DnD cursors ("copy" and "no-drop") anymore.
Change this to the "default" cursor.
Additionally, because the "no-drop" cursor now puts a stronger emphasis
on the crossed out symbol also prefer "default" for
META_CURSOR_DND_IN_DRAG and only use "no-drop" for things that
explicitly don't accept a drop.
Related: https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/merge_requests/63
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3532>
When Wayland clients send commits without a buffer attached ("empty"
commits), they may lead to stage updates that do not result in any
frame being submitted for presentation ("empty" updates).
Due to how frame scheduling is handled, there can be many such
"empty" updates in a single refresh cycle. If frame callbacks were
emitted after each of these "empty" updates, and if the client
sending "empty" commits was using frame callbacks to throttle the
same logic that results in these "empty" commits being sent, it would
result in a feedback loop between Mutter and the client where the
client would send "empty" commits and Mutter would reply almost
immediately with a frame callback causing the client to send "empty"
commits continuously.
As such, when an "empty" update is detected, frame callbacks are
scheduled to be emitted only once in every refresh cycle, avoiding the
feedback loop.
When a "non-empty" update is detected, frame callbacks are instead
emitted immediately to allow clients to draw their next frame as soon
as possible. It is safe to emit frame callbacks in this case because
the frame for the current refresh cycle is already "finalized" and
that any commit sent by the client at that point would only be handled
in a future refresh cycle.
To implement this, the previous logic had used
meta_frame_native_had_kms_update() to detect "non-empty" updates,
assuming that those would always result in a KMS presentation with the
native backend.
However, this approach misses the fact that virtual monitors do not
use KMS, and as such do not result in KMS presentation even for
"non-empty" updates. As a result, frame callbacks would not be emitted
immediately, resulting in unintended throttling of client rendering.
Instead, assume that it is safe to emit frame callbacks immediately
whenever an update results in the frame clock waiting to be notified
of presentation, since this is also when commits sent by clients are
scheduled to be handled in a future refresh cycle.
This issue was mostly hidden because frame callbacks would be sent
immediately when the target presentation time for the frame had
changed compared to the previous frame. However, this behavior was
removed in 26d8b9c69 ("wayland: Remove unnecessary dispatch of frame
callback source"), exposing the issue.
Fixes: a7a7933e0 ("wayland: Emit frame events in GSource after "empty" updates")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3263
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3549>
Calculate the frame deadline in ClutterFrameClock's
calculate_next_update_time_us() rather than in MetaWaylandCompositor's
on_after_update().
The specifics of the deadline calculation for a given frame should be
implementation detail of the frame clock and and remain internal to
allow extensibility.
This extensibility is specifically useful for scenarios where a
different deadline calculation is needed due to alternative frame
scheduling logic, such as for VRR.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
To avoid communicating lower frame rate to clients through frame
callbacks, it is important to avoid delaying the source dispatch when
a dispatch is already scheduled.
To that end, the previous logic would emit pending frame callbacks
immediately in case a source dispatch was still scheduled for the
previous refresh cycle and then (potentially) schedule another source
dispatch for the current refresh cycle.
However, emitting pending frame callbacks immediately would send
frame events for every pending frame callback, including for the
current "empty" update. Scheduling another source dispatch for the
current cycle was then unnecessary and potentially undesirable
because there may not even be another "empty" update during the cycle.
Instead, let the already-scheduled source dispatch handle emitting any
pending frame callbacks, and do not schedule an additional source
dispatch for the current cycle as it may not be needed.
This approach is useful because it removes an implicit assumption
that the refresh rate is fixed and that target presentation time
remains constant within a refresh cycle. This assumption does not
apply for VRR.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
