This also gets rid of the MetaFrameSyncMode enum and instead issues a
VRR update when the requested state differs from the CRTC state.
Fixes: fee33299 ("onscreen/native: Allow requesting frame synchronization")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3646>
This includes checking the vrr_capable property on the connector as well
as the VRR_ENABLE property on any CRTC the connector might get assigned
to. Also takes into account when a GPU is tagged for broken VRR support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3646>
As we are getting close to have a Wayland-only build, guard those usages
so we don't 'regress'.
Once Kiosk figures it use case, we can revert both this commit and the
previous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3652>
When multiple configure requests sent to the wayland client within a sort period, maximized windows may end up in wrong position and cover struts. To avoid this, queue a resize when the resize event sent by the wayland client results a changed size or position to ensure that the final size and position will be always right.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3601>
Using `meta_wayland_single_pixel_buffer_from_buffer()` can fail if
the buffer resource is already gone. Given that we release the buffer
immediately, that is actually expected - but the client this was tested
with did/does not do so.
This made the single pixel black bar optimization fail for
GstWaylandsink, while working for the mpv Wayland backend.
Access the object directly, which is both faster and works as long as
the buffer is alive.
Fixes: ed50cbbfe4 (window-actor/wayland: Update scanout candidate check)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3662>
Gestures are independent from each other when they are on different
actors and when they don't have a conflict over input with each other: For
example a gesture on one window and a gesture on another window will
recognize at the same time perfectly fine right now.
For those gestures (let's call them "independent gestures") we don't want
to control how the conflicting input should be handled, i.e. whether one
gesture wins over another or whether both can be recognizing using the
same touchpoint (e.g. zoom+rotate on the same actor). Instead we want
to control whether they are allowed to start while another one is running.
For now, make it impossible for two gestures to recognize globally at
the same time in all cases. This helps prevent subtle bugs and makes life
easier for users of the API. We can introduce API for fine grained control
over the behavior later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
With the next commit, we'll need a list of all gestures that currently are
active globally. Since actors and actions (and therefore also gestures) in
Clutter are bound to a stage, it makes sense for this list to exist on the
ClutterStage level.
The list itself is a simple GPtrArray (to allow for quick searches) that
doesn't reference the gestures and is not manipulated by the stage itself.
All manipulation of the array is left to ClutterGestures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Quite often there are situations where multiple gestures try to
recognize, keeping track of the same set of points (for example an edge
drag gesture on the stage and a click gesture somewhere in the
scenegraph). Usually what's wanted here is that the first gesture to
move to RECOGNIZING wins over all other active gestures and "claims" the
point for itself.
We implement this by introducing a concept called "influencing". It
works by making all gestures operating on a shared set of points aware
of each other using ClutterAction->register_sequence().
ClutterGesture uses this vfunc to keep track of all other
ClutterGestures that are potentially conflicting, and keeps a list
(priv->cancel_on_recognizing) of those. As soon as the move to
RECOGNIZING happens, all gestures inside this list get moved to
CANCELLED.
To allow fine-grained control over this behavior, two APIs are
introduced:
1) on the implementation level (should_influence() and
should_be_influenced_by()): This is a vfunc that gets called as soon as
a potential conflict is detected. It's helpful when a specific gesture
always behaves the same towards another gesture, for example to make
sure a LongPress gesture never cancels a DragGesture.
2) on the gesture user level, clutter_gesture_can_not_cancel() is
introduced: This allows control for the user of a gesture to specify
that a specific instance of a gesture won't cancel another gesture.
Calling this twice so that both gestures can't cancel each other allows
for things like simultaneous recognition of a pinch-to-zoom and rotate
gesture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
Introduce ClutterGesture, a new ClutterAction subclass and the successor
of ClutterGestureAction that brings the necessary tools to handle
sequences of events and abstract touch and mouse gestures from those.
The big difference compared to ClutterGestureAction is that ClutterGesture
provides the implementation with point_added/moved/ended and
sequences_cancelled events and expects the implementation to move the
ClutterGesture through the ClutterGestureState state machine. This state
machine is then used internally by ClutterGesture to coordinate with other
gestures.
With the next commits, ClutterGesture will handle relationships between
conflicting gestures completely by itself, allowing the implementation or
the user to specify the details of the relationship between two gestures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
clutter_event_get_source() is still valid for the case of crossing events,
just like clutter_event_get_related(). The latter is not deprecated, so the
former shouldn't be either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
ClutterStage will unref an action in the middle of its own event handler in
case the action causes its own actor to be destroyed. In this case the
action would get freed underneath our feet. To avoid it, take a ref on the
action while calling its handle_event() vfunc, just as we do in
clutter_actor_event() while emitting an event to an actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2389>
The gnome-shell magnifier listens to the `visibility-changed` signal
and calls meta_cursor_tracker_set_pointer_visible(false) when the
cursor became visible.
This leads to a reentrance in meta_cursor_tracker_set_pointer_visible()
and clutter_seat_uninhibit_unfocus() gets called twice, once from the
meta_cursor_tracker_set_pointer_visible(false) by the magnifier and then
the original meta_cursor_tracker_set_pointer_visible(true) continues,
after the first call has set is_showing to false again. This breaks the
inhibitor counting and the ability to use the cursor while using the
magnifier.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3661>
Near window destruction, there might be cases where the surface
actor does no longer have a surface, yet it's still in the stage
and eligible for picking. In that situation looking for modal
dialogs attached to this surface will evidently fail, so avoid
this check on a NULL surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3332
Fixes: 93a9e7f3f ("core: Move code ignoring events on windows with modals to Wayland")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3660>
`eglGetProcAddress()` used to not work for core API in EGL versions
below 1.5. The workaround in place in turn can fail - notably for setups
with a local Mesa build in /usr/local.
EGL 1.5 is almost 10 years old and similar workarounds don't seem to be
in place for toolkits we rely on, notably GTK4. Thus remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
Since commit e30eb78891 `ClutterFrameClock` assumes that a valid CPU time
implies timestamp query support, which is also checked in
`cogl_onscreen_egl_swap_buffers_with_damage()`.
Unconditionally setting the CPU time on direct scanout meant that the
compositing path would be stuck on the last (direct scanout optimized)
result on GL implementations without timestamp query support since.
be0aa2976e (clutter/frame-clock: Avoid rapidly toggling dynamic max render time)
Fix that by explicitly marking the gpu rendering duration as valid when
querying the GPU timestamps is supported and check for it ClutterFrameClock.
Fixes: 56580ea7c9 ("backends/native: Assume zero rendering time for direct scanout buffers")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3655>
This makes sure that xdg-output.logical_size and
xdg-output.logical_position are only sent when they actually changed.
There should be no behavior change in wl_output_transform_from_transform
but it now uses the same technique of tracking the protocol state and
comparing it to the current state to compute which properties have
changed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3622>
X11 server side focus changes, such as when a focus change was requested
by mutter for a globally active window, did not go through
meta_display_set_input_focus(), which is responsible for emitting the
`focus-window` signal. Since this signal is what triggers the display
server specific code to handle focus changes, this was leading to a
problem on Wayland where the focus remained on the last active Wayland
window when the focus got changed to a globally active XWayland window.
This commit now changes handling X11 server side focus changes to also
go through the code path that emits the signal while making sure to not
trigger another focus change and keeping the same serials as the
previous code to not interfere with future focus changes.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3651>
MetaSelectionSourceMemory currently uses GBytes for its underlying data.
This can cause memory overhead when large items, such as HD images, are
stored in the clipboard. This commit changes the underlying data
structure to a MetaAnonymousFile object, which writes to memfd instead
of heap. When reading, MetaSelectionSourceMemory will create a
Gio.UnixInputStream from the file descriptor generated by
MetaAnonymousFile. We subclass the UnixInputStream as
MetaUnixInputStream, to override the stream's close_fn function so
that it invokes meta_anonymous_file_close_fd when the stream terminates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3551>
Which got introduced in wl_compositor version 6.
Note that if the surface is visible on multiple monitors with different
transforms, we pick the transform of the monitor which we choose for the
scale as well. This doesn't really matter at the moment, as the
transform is only really relevant for direct-scanout - which we
currently only support for fullscreen clients.
Once we support direct-scanout for partially visible clients we'll
likely want to introduce a more sophisticated algorithm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3580>
Some clients - notably the Gstreamer vapostproc element when using Intel
GPUs - only support BGRA, not BGRx. We already assume that we can
support this format for window screen casts, and even in case of failure
we now have a re-negotiation fallback in place. Thus it's pretty safe to
support it for all screen cast types.
The possible duplication in case of window screen casts doesn't seem to
be a problem for either Pipewire or existing clients like OBS.
Note that the implementation lays the foundation to make it easy to add
more formats in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3617>
Currently, ClutterFrameClock uses g_source_set_ready_time() to determine
the usec timing of the next frame. That translates into a poll() with a
millisecond timeout if no trigger occurs to break the poll() out early.
To avoid spinning the CPU, GLib always rounds *up* to the next millisecond
value unless a timeout of 0 was provided by a GSource.
This means that timeouts for the ClutterFrameClock can easily skew beyond
their expected time as the precision is too coarse.
This applies the same concept as GNOME/glib!3949 but just for the
ClutterFrameClock. That may be more ideal than adding a timerfd for every
GMainContext, but we'll see if that lands upstream. I wanted to provide
this here because it could easily be cherry-picked in the mean time if
this is found to be useful.
From a timer stability perspective, this improves things from erratically
jumping between 100s and 1000s off of the expected awake time to single
or low double digits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3636>
