We need an object to hold additional scanout related information, such
as scaling and positioning data. Turn CoglScanout into such an object,
moving the interface into CoglScanoutBuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
Popups were missing the "input focus" unification in the pointer
seat, triggering MetaWaylandKeyboard focus changes underneath. On
one hand this missed moving all associated focus with it, on the
other hand this made keyboard and global input focus get out of
sync, and bring funky behavior like keyboard focus loss after
dismissing popups.
Fixes: 7b232d9f65 ("wayland: Keep track of the "input focus" on MetaWaylandSeat")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3256
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3568>
There doesn't seem to be a good reason to keep this code in
`MetaWaylandSurface`. Moving it to `MetaWaylandBuffer` cleans things
up and will allow us to tread buffers differently depending on their
type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3559>
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>
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>
The value of this variable represents the last point in time in
which an update would be allowed to scheduled for the given frame.
Rename it for clarity and in preparation for the next commits.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
The value returned from clutter_frame_get_target_presentation_time()
is always same as the value returned from
clutter_frame_get_min_render_time_allowed() when they are called
consecutively because both functions effectively return the value of
frame->has_target_presentation_time. This is with the assumption
that this variable is only ever modified by the same thread that
also executes on_after_update().
As such, a case where the former returns FALSE after the latter
returned TRUE is not possible, which means the line that sets
"target_presentation_time_us = 0;" is effectively unreachable.
Acknowledging this fact allows the call to
clutter_frame_get_target_presentation_time() to be moved outside the
"else" case and into the "if" condition itself. This is done in
preparation for the next commits.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3521>
It adds the following clarification:
```
Starting from version 5, the invalid_format protocol error is sent if
all planes don't use the same modifier.
```
We already send an error, just the wrong one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3450>
This is the unified focus (key, IM, pads, ...) for the focus window.
Just like MetaWaylandPointer and others keep track of the "current"
surface, this is the "current" surface for those (not necessarily
the focused surface, e.g. in the case of compositor grabs).
Since this unified focus will exist regardless of keyboard
capabilities (e.g. even if just for "logical" focus like IM/clipboard
that does not depend on input devices), it does not make sense
to trigger a focus sync on keyboard capability changes, the focus
is staying the same, we however need to focus the keyboard interface
to the already existing focus when the capability is enabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
Instead of letting the MetaDisplay be aware of the Wayland compositor,
and take care of updating its focus. This makes the MetaWaylandCompositor
able to track focus changes by itself, using MetaDisplay as the source
of truth.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3511>
Finding the shm offset and shm stride for each plane is the main issue.
The rest is just creating multiple textures for each plane.
One assumption is that shm planes are always contiguous in memory so the
next plane comes directly after the size of the current plane.
The size of a plane is determined by the height and stride. There is
only a single stride parameter for shm buffers but we assume that the
first plane is always non-subsampled which gives us a number of "logical
elements" on one line (stride / bpp of the first plane). The stride of
the other planes is then the number of logical elements devided by the
subsampling factor and multiplied by the bpp of the plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3371>
ClutterInputFocus/GtkIMContext uses char based offset for
delete_surrounding, however, text_input_v3 uses byte based offset for
it. Currently only GTK with mutter can work correctly via text_input_v3
because they both forget to convert between char based offset and byte
based offset.
This commit fixes it in mutter by saving committed surrounding text in
MetaWaylandTextInput and converting char based offset to byte based
offset with the UTF-8 encoded surrounding text.
Fixes <https://gitlab.gnome.org/GNOME/mutter/-/issues/2146>.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2712>
A surface commit may change the buffer scale but not attach a new
buffer. In that case, the size of the previously attached buffer needs
to be consistent with the new buffer scale.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
meta_wayland_surface_get_buffer_width/height uses the currently applied
buffer, which may have a different size.
Fixes: 7649e2f3ab ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
Multiple reasons:
* More consistent with the protocol spec language.
* Ensures the size is checked and the protocol error sent from a
protocol processing context, instead of whatever context
meta_wayland_surface_commit might get called from.
* The latter implies that surface->resource is guaranteed to be valid.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3211
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3463>
The include is currently satisfied by
window-x11-private → iconcache → x11-display-private
The icon cache is about to be removed, so add the missing include
directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3452>
Split the struct into mutable and immutable parts. Access the mutable
parts via getters and the immutable parts via a single struct. This
avoids copying around the immutable parts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3280>