Version 1 of the presentation protocol requires that 0 be sent for the
refresh rate for variable refresh rate. Fix this by checking the mode
during the presentation event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4227>
Ignore the gravity argument in the move_resize_internal() vmethod,
and use the window getter to get it. It should be functionally
equivalent, and will eventually replace the argument entirely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3972>
New protocol that allows a client to require that a previously flagged
content update must be presented before a content update can be applied.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
Allow a transaction to have a timing constraint.
Any transaction with a timing constraint will be deferred at its initial
commit, without testing the target time. The timing constraints are cleared
later in an on_before handler immediately before repaint.
The new frame clock api to schedule later ticks is use to ensure we get an
appropraitely timed tick to clear the constraint.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
g_hash_table_steal leaked the MetaMonitorSpec key in the old
compositor->outputs hash table:
==1059254== 62 (32 direct, 30 indirect) bytes in 1 blocks are definitely lost in loss record 8,232 of 13,059
==1059254== at 0x48489F3: calloc (vg_replace_malloc.c:1340)
==1059254== by 0x4C65C19: g_malloc0 (gmem.c:133)
==1059254== by 0x4956FE8: meta_monitor_spec_clone (meta-monitor.c:108)
==1059254== by 0x4A7B9E8: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:555)
==1059254== by 0x4A7C09E: meta_wayland_outputs_init (meta-wayland-outputs.c:796)
==1059254== by 0x4A63B60: meta_wayland_compositor_new (meta-wayland.c:874)
==1059254== by 0x49B58D0: meta_context_start (meta-context.c:523)
==1059254== by 0x10A8D7: main (mutter.c:148)
==1059254==
==1059254== 62 (32 direct, 30 indirect) bytes in 1 blocks are definitely lost in loss record 8,233 of 13,059
==1059254== at 0x48489F3: calloc (vg_replace_malloc.c:1340)
==1059254== by 0x4C65C19: g_malloc0 (gmem.c:133)
==1059254== by 0x4956FE8: meta_monitor_spec_clone (meta-monitor.c:108)
==1059254== by 0x4A7B9E8: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:555)
==1059254== by 0x4A7BA8C: on_monitors_changed (meta-wayland-outputs.c:572)
==1059254== by 0x4F5E9BF: g_closure_invoke (gclosure.c:833)
==1059254== by 0x4F72D82: signal_emit_unlocked_R.isra.0 (gsignal.c:3887)
==1059254== by 0x4F747A8: signal_emit_valist_unlocked (gsignal.c:3519)
==1059254== by 0x4F7A665: g_signal_emit_valist (gsignal.c:3262)
==1059254== by 0x4F7A722: g_signal_emit (gsignal.c:3582)
==1059254== by 0x49691BD: meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:1241)
==1059254== by 0x496EA8D: meta_monitor_manager_rebuild (meta-monitor-manager.c:3968)
v2:
* Use g_autoptr. (Sebastian Wick, Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4149>
The buffer resource doesn't need to exist for a timeline to exist so we
still have to send the timeline release. Only guard the
wl_buffer_send_relase call.
Fixes: e8b890ab53 ("wayland: Implement linux-drm-syncobj-v1")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4157>
Even though the touch moved to being set up in CLUTTER_ENTER, it
is still meant to lock onto the pressed surface, we however will
receive crossing events if the touch moves between actors/surfaces,
triggering warnings when the touch info registration is attempted
on the already existing touch sequence.
The reasons to handle this in CLUTTER_ENTER still apply, so ensure
the touch info for the sequence does not previously exist to avoid
the warning.
Fixes: 2e82a2049f ("wayland: Register touchpoint info on CLUTTER_ENTER")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4166>
We try to emit wl_touch.cancel in the situations where grabbing input
would take input away from the wl_touch interface. This however does
not play fine with grabs induced by wayland interfaces (e.g. xdg popups).
A more natural place to handle this is the MetaWaylandSeats' default
input handler, specifically the focus() vmethod. Here, we may know if the
focus surface matches the current surface as picked by MetaWaylandTouch,
and if it does not, either a grab or another input handler stole input
away from the default event handler.
A case where this will notably not happen anymore is in the transition
to a xdg_popup grab, since the grabbing client will still be handling
input, and touch input will not be unfocused away despite the transition
to a grab.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3752
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4166>
The logic to allow src/wayland to update the pointer cursor changed
to bypassing grabs in commit e69e4fa6, since it is nowadays the
responsibility of the DnD source to update the pointer cursor in reaction
to the negotiated action.
This is not entirely correct, and was done at the expense of regressions.
Change the logic so we explicitly check for a DnD grab existing, or use
the active focus instead (i.e. grab-aware). This fixes the regression, and
keep DnD cursor icons working.
This is a partial revert of commit e69e4fa6dbbd62677de61bcd2f5f3bec515e79ce.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3460
Fixes: e69e4fa6db ("Revert "wayland: Check focus surface to set a pointer cursor"")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4166>
When creating a new color state from the primitives Colorimetry, EOTF
and Luminance; it is needed to previously check their tags to properly get
their values and avoid UB.
This check is duplicated and is a bit unreadable.
Using this new function helps keeping readability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4144>
Most of the implementation at color state was specific to a color state
generated from parameters so move it to a new class Params.
In the next commits a new color state ICC class will be added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4144>
- Event stream adaptations. When there is a toplevel-drag in place, do:
- Send wl_data_source.dnd_finished and end the session successfully
- Send wl_data_source.cancelled and end the MetaWindowDrag when ESC key
is pressed.
- Modify MetaWaylandDataDevice such that, when a toplevel-drag is
running, it does:
- Propagate motion events, so that they can be processed further by
MetaWindowDrag.
- Ends the associated MetaWindowDrag upon release event.
- Hook up the window mapping process in MetaWindowWayand, such that:
- the initial position of the window attached to the ongoing
toplevel-drag instance can be calculated and set.
- the appropriate gravity and flags can be set when calling MetaWindow's
meta_window_move_resize_internal, which allows it for example to be
moved freely (unconstrained) as per current dragging cursor.
Status:
- [x] Basic window drag triggering
- [x] Exclude the dragged window from event targets
- [x] Event forwarding (window drag vs wayland grabs)
- [x] Offset calc relative to toplevel geometry
- [x] Attach already mapped windows
- [x] Properly support not-yet-mapped windows
- [x] Disable visibility change animations
- [x] Dnd events stream adaptations
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
- For already mapped windows, the window drag session is started
straight away;
- For about-to-be-mapped window (ie: undocking window use case):
- The "shown" signal for the dragged window triggers the actual
MetaWindowDrag once it's mapped.
- MetaWindowWayland now handles the case of toplevel-drag and position
the window about to be mapped according to the toplevel-drag
parameters.
- While attached to a toplevel-drag, the window state is updated to:
- Actor's "reactive" state is set to false, which in practice excludes
it from the possible drag target list;
- WindowActor's "tied to drag" state is set to true, which results in
initial placement constraints to be skipped, so newly created
(detached) windows can be freely dragged around.
- Toplevel drag session ends upon:
- dnd drop and cancellation.
- xdg_toplevel_drag_v1 object destruction (client-side).
- data source destruction.
Status:
- [x] Basic window drag triggering
- [x] Exclude the dragged window from event targets
- [x] Event forwarding (window drag vs wayland grabs)
- [x] Offset calc relative to toplevel geometry
- [x] Attach already mapped windows
- [x] Properly support not-yet-mapped windows
- [ ] Disable visibility change animations
- [ ] Dnd events stream adaptations
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
The cogl_scanout_get_dst_rect() fell back on the buffer dimensions as
the destination rectangle when nothing was explicitly set. This,
however, is not necessarily correct. For example, if a buffer is larger
the CRTC resolution, but the surface is scaled to exactly match the CRTC view,
the expected destination size should match the CRTC resolution, not the
buffer dimension, which would be the case if no explicit destination was
set.
In meta_wayland_try_aquire_scanout() we're in a good position to
determine the destination rect in the CRTC primary plane, since we have
all the prerequisits, i.e. that the surface effectively covers the whole
CRTC, the actor allocation box (the non-black border part), the scale
and transform of the view.
This tweaks the CoglScanout API a bit to make it explicit that the
dst_rect must be unconditionally provided, and removes the fallback to
the buffer dimension as the destination rectangle, which sometimes
resulted in a destination rectangle being larger than the primary plane
itself, resulting in clipping and incorrect scaling.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3773
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4147>
The "dst_rect" calculated is in "CRTC space", meaning the bounding box
used for calculating it should be the view layout dimension, scaled by
the view scale and transform by the view transform. Previously it was
only transformed, not scaled. While fixing this, rename the variables to
make it a bit more clear what coordinate space they are expected to be
in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4147>
This allows drag-and-drop within the same surface with touch input.
Test case: drag-and-drop a file into a directory in Nautilus.
Prior to this change that would only work if the finger first leaves
then re-enters the surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4091>
For zwp_text_input_v3_set_surrounding_text(), the protocol specifies:
"If the client is unaware of the text around the cursor, it should
not issue this request, to signify lack of support to the compositor."
Mutter currently doesn't clear its stored surrounding text when the
input focus changes, re-using the existing text for the newly focused
client. This already seems problematic, but since clients aren't
supposed to set surrounding text to NULL or an empty string if they
don't have one (and instead should simply avoid calling
`set_surrounding_text()`), this is clearly a bug in Mutter.
Fix it by unsetting the stored surrounding text when removing input
focus from a client.
Fixes: 33088d59db ("wayland/text-input: Pass char based offset to ClutterInputFocus")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3604>
The cursor and anchor position of the surrounding text *must* be within
(or right before/after) the string that is submitted as surrounding text.
Everything else is a client error that we shouldn't accept and log as such.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3650>
meta_wayland_text_input_focus_delete_surrounding() is accessible from JS and
used by gnome-shell via ClutterInputMethod.delete_surrounding(). Mutter
should never crash on invalid function calls from JS, so g_return_if_fail()
instead of asserting in case the parameters are wrong here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3650>
