If a modal dialog (i.e. with a "revolves around center of parent window" policy)
becomes fullscreen, we cannot neatly honor both the modal dialog going fullscreen
and the window staying around the center of its parent.
In order to make fullscreening work in this situation, allow fullscreen modal
dialogs to "snap out" of the parent. This rule will become again effective after
the window is unfullscreened.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3425
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3695>
By ignoring obcured surfaces we can generalize the single-pixel-buffer
background check to work with arbitrary surface trees, as long as the
two top ones are the background and content surfaces.
As a nice side effect of this, clients like Firefox now usually take the
shorter `meta_window_is_fullscreen (window) && n_visible_surface_actors == 1`
route.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3699>
Move the code out of cogl_onscreen_egl_swap_buffers_with_damage, and
call the new function from callers of the former.
v2:
* Use early return if the cogl context doesn't support timestamp
queries. (Sebastian Wick)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3689>
`mtk_rectangle_new()` allocates the object dynamically,
but in the "contains-point" test case the allocated object
was not freed. Fix that by creating the object on the stack.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3679>
Avoids using a static and make sure things are properly freed by
using g_autoptr. Also take the opportunity to add some missing NULL
initialization for auto-pointers variables
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3687>
In consistence with the code style, and in order to fix build errors
with older clang:
../src/backends/native/meta-onscreen-native.c:521:7: error: expected expression
521 | graphene_rect_t src_rect;
| ^
../src/backends/native/meta-onscreen-native.c:529:39: error: use of undeclared identifier 'src_rect'; did you mean 'dst_rect'?
529 | &src_rect);
| ^~~~~~~~
| dst_rect
../src/backends/native/meta-onscreen-native.c:522:20: note: 'dst_rect' declared here
522 | MtkRectangle dst_rect;
| ^
And warnings with newer clang:
../src/backends/native/meta-onscreen-native.c:521:7: warning: label followed by a declaration is a C23 extension [-Wc23-extensions]
521 | graphene_rect_t src_rect;
| ^
This should allow the build for coverity to succeed again.
Fixes: adc776d0d7 ("crtc/kms: Pass on src and dst rects to primary plane assignments")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3686>
This implements the explicit sync protocol linux-drm-syncobj-v1. This
works by importing a DRM syncobj timeline and importing/exporting fds
to/from the sync points on the timeline corresponding to buffer acquire
and release. We take fds for sync points provided during a surface
commit and use them to delay transaction application, and fetch fds
from Cogl to signal when we are done using a particular buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300>
This adds the explicit sync wayland protocol to the list of build
dependencies.
This adds a copy of the linux-drm-syncobj protocol that we will use
privately for builds. This avoids the pain of requiring wayland-protocols
1.34 for distros. This commit can be reverted once we want to use
linux-drm-syncobj from the system wayland-protocols.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300>
This keeps an internal sync_fd for the latest work submitted to
the GPU. This can then be fetched with cogl_context_get_latest_sync_fd
for use. This is intended for use with linux-drm-syncobj-v1
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3300>
On big endian architectures the mapping of drm formats to cogl
formats is significantly trimmed compared to on little endian
architectures.
meta_wayland_init_shm tries a bunch of formats, including some
that just aren't mapped on e.g. s390x.
The code asserts the mapping will exist, however, leading to
crashes when Xwayland starts.
This commit makes failure to find a mapping non-fatal.
Suggested by Jonas Ådahl.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3672>
ClutterInputMethods content hint or purpose will be set again (even to the
same values) whenever a wayland client sends us a new content type/purpose.
Gtk appears to always set a content purpose on wl_text_input changes, so we
currently set and notify the "content-purpose" property on every change in a
gtk text field.
Since the OSK is gnome-shell listens to this property and re-generates its
entire layout when the content-purpose prop gets notified, this is currently
causing lag/freezes on every keypress in the OSK in gnome-shell.
So ensure to not notify these properties in case they're equal and set the
properties in the same way as we usually set them instead of going via
GObject.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3645>
When logging in from gdm to gnome, the main plane is deactivated, and
leads to the screen going blank before gnome is able to enable it
again.
Using the new CloseFB ioctl, allows to keep the gdm login screen
displayed until gnome-shell replace it.
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3659>
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>
