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>

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>

This abstracts away directly dealing with DRM syncobjs. Explicit
sync code can simply create a MetaDrmTimeline and request an fd at
a particular sync point.

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 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>

Check that the container registry in user repositories is
enabled, and issue a more descriptive error around it. Lifted
from Tracker.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3681>

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: adc776d0 ("crtc/kms: Pass on src and dst rects to primary plane assignments")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3686>

As we are using a GParamSpecUint64 for that property
which makes it fail under 32bits platforms

Fixes: 6efd4a22 ("cogl/cleanup: Use construct-only properties for
CoglBuffer")
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/3408

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3683>

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>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3687>

This corresponds to the values in the code. The second comment is
correct.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3671>

The stride of the dumb buffer isn't necessarily 4 * width even if the
bytes per pixel is 4, so lets not make that assumption.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=2267951
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3666>

When the compositor inserts two waits in a frame, such as f606a442,
the second insertion shouldn't break the ring's state machine as easily
as it does. We can instead merge the two GL waits into one by simply moving
the GL fence to the latest insertion. Each insertion still does its own X11
sync though.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3384
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3685>

`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>

Fixes: 63a55895 ("cogl: Generate a GType for PixelFormat")
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/3413

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3690>

When preparing a frame for scanout on a secondary GPU, calling
meta_drm_buffer_gbm_ensure_fb_id for the primary GPU device is
unnecessary and potentially harmful.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3389
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3674>

Preparation for later changes, no functional change intended.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3689>

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>

The timestamp query is currently always created for the primary GPU, so
it doesn't cover any later secondary GPU work.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3070
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3689>

Jonas Ådahl authored Apr 14, 2024 and Robert Mader committed Apr 15, 2024

We had missed to actually return the cached texture, so do that.

Also add a test.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3432
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3702>

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>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3703>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3703>

Use GList *l and for loop for iterating, autopointers and autolists
for memory management, and a function instead of a macro for a
condition.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3703>

This fixes that with scale-monitor-framebuffer disabled, windows were always
configured with bounds using physical instead of logical pixels.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3269



Co-authored-by: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3698>

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>

In every other device and circumstance, we update the logical focus
(i.e. the surface that would be focused, if no other circumstances
applied) but let the MetaWaylandInput figure out the surface that
should be effectively focused, if at all. This is where we apply the
actual compositor state (e.g. grabs) and result in an effective focus
window.

The only exception to this is `meta_wayland_seat_set_input_focus()`
where the logical focus for keyboards and related devices is set, but
also applied as the effective surface.

We should do the same as everywhere else, and let MetaWaylandInput
focus determine whether the logical focus is also the effective focus.
These replaced set_focus() internal calls will happen through the
default MetaWaylandEventInterface.focus implementation in MetaWaylandSeat.

This resulted in keyboard focus being set on windows in circumstances
it ought not to, like in the overview. Actual key events were never
sent in these circumstances, but changes to modifier state could.

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3704>

This makes sure the ColorDevice can initialize successfully even if the
display doesn't have an EDID.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3394
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3673>

When the monitors change meta_window_update_for_monitors_changed is
called which is responsible for updating window->monitor. It however can
go through the entire window placement and constraint machinery before
it's able to do so. In this period window->monitor points to the old
MetaMonitor where the monitor number doesn't reflect the index into the
MonitorManager anymore.

Avoid relying on the window->monitor->number and go through the Monitor
directly.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3402
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3691>

It means it can be included in places that assume cogl and everything it
involves shouldn't be included, e.g. meta-renderer-native-gles3.c.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

Want to include it without including all of clutter and cogl.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

The purpose is to not include all of clutter and cogl.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

The Nvidia driver will return ENOSYS if any flags are used. Bug filed
upstream on the NVIDIA forums.

https://forums.developer.nvidia.com/t/gbm-surface-create-fails-if-flags-0/279951

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

As mentioned in the OES_EGL_image_external spec, there is no implicit
sync between the EGLImage producer and consumer. And in this code path
we don't have meta_drm_buffer_gbm_new_lock_front on the primary GPU to
do it for us either. So synchronization has to be done manually or else
the secondary GPU is likely to get an unfinished image.

This problem has only been observed when the secondary GPU is using the
Nvidia proprietary driver.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

This is a critical part of any OpenGL program. Mesa allowed us to get
away without it and provided a sane default of the full buffer, but
Nvidia seems to default to an empty/zero viewport so would refuse to
paint any pixels.

In the OpenGL ES 2.0 spec this is ambiguous:

> In the initial state, w and h are set to the width and height,
> respectively, of the window into which the GL is to do its rendering.

because the first "window" used is EGL_NO_SURFACE in
init_secondary_gpu_data_gpu. It has no width or height.

In the OpenGL ES 3.0 spec the ambiguity is somewhat resolved:

> If the default framebuffer is bound but no default framebuffer is
> associated with the GL context (see chapter 4), then w and h are
> initially set to zero.

but not entirely resolved because neither spec says whether
EGL_NO_SURFACE should be treated as zero dimensions (Nvidia) or ignored
and not counted as the first "window" (Mesa).

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

The EGL context can only import and blit an EGLImage if the
backing DMA buffer has a format modifier combination that is advertised
as supported and not marked as "external_only".

When the context can't blit the imported image, we can still paint using
it GL_OES_EGL_image_external using the texture target
GL_TEXTURE_EXTERNAL_OES.

However, treat drivers who doesn't support modifiers at all as if they
do support blitting, if the modifier is 'linear', to avoid regressions.

[jadahl: Make shader path a fallback to allow hardware to utilize copy
engines via blitting]

Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6221
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2247
Related: https://launchpad.net/bugs/1970291

now only falls back if modifiers are supported, and they mark linear as
export only.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

check-code-style was complaining about this.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

In the rare event that hotplugs destroy and then create a new EGLContext
with the exactly the same ID, this ensures we will forget the old program
which presumably wouldn't work in the new context. It will be recreated.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

Because that egl_surface is only used for secondary GPU copying, which
isn't relevant to primary GPU copies.

This is a partial revert of 41bfabad which is no longer required since
the previous commits have enabled secondary GPU copy support for nvidia-drm.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2551
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3304>

Such as with MODE_EGL_DEVICE.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3436
Fixes: 40950f99 ("drm-buffer-gbm: Do not call ensure_fb_id from...")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3708>

Right now we store touch serials on their according MetaWaylandTouchInfo
entries. These entries are gone as soon as the touchpoint ended though, and
it's not unlikely that clients will respond to that touch-end event after we
removed the touchpoint.

In this case we currently can't match the client provided serial to any of
our known touch sequences, which causes xdg_popup grabs that get requested
shortly after the touch-end to fail.

Let's be a bit more gentle on clients here and store the latest touch-down
serial on the MetaWaylandTouch, so that it continues to be around after the
touch-end and we can match the serial of the xdg_popup_grab() as expected.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2946>

This is only called from a single place inside ClutterStage code,
drop this public internal function, and repick in place.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3696>

Instead of doing that in clutter-main.c code, move it together
with the rest of picking calls to ClutterStage.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3696>

Avoid open-coding the process of figuring out the affected devices
on view changes and repick on those, in exchange for a ClutterStage
method to do this altogether.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3696>

It's now only called within it, inside other higher-level accessors
to update picking based on actor/view/event changes. This can now be
made a private call.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3696>

The release_points array holds pointers to MetaWaylandSyncPoint objects.

Fixes leaking references (and ultimately the underlying memory) for the
array elements.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3442
Fixes: e8b890ab ("wayland: Implement linux-drm-syncobj-v1")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3710>

Previously the function would exit early, never changing the out value
which is usually passed in uninitialized. This would however only happen
in the presence of another issue leading to the properties being
undefined. We can still be a bit more defensive against this though.

Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6558
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>

When updating the input region we check whether the input shape reported
by XShape matches the bounding region of a window to determine when it
was not set by the client. We would then use a NULL input region instead
which always matches the full size of the window. The code however was
using the client rect for this comparison, which does not include the
window frame. Since d991961a the frame is considered part of the input
region.

This meant that for SSD windows where the input region would match the
bounding region, we would not detect that and fail to set the input
region to NULL, but instead set it to the reported input shape.

Usually this would not be the case due to the GTK frame window having
shadows and a resize region, but in the presence of an issue that causes
GTK to wrongly detect _GTK_FRAME_EXTENTS as not supported, GTK would not
draw shadows or set an input shape. And due to GTK not updating its
input shape, there would be no further calls to
meta_window_x11_update_input_region() after the initial one.
The input region would therefore remain at the fixed size from the
initial call. This was causing windows to become click-through outside
of the region corresponding to their initial size after being resized.

Fixes: d991961a ("x11: Use input region from frame window for decorated windows")
Related: https://gitlab.gnome.org/GNOME/gtk/-/issues/6558
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3404
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>

d991961a changed this code from client rect to buffer rect to account
for the fact that for SSD windows the decorations are now included in
the bounding region, but it kept the variable name as client_area and
the comment was also still referring to the client rect.

Fixes: d991961a ("x11: Use input region from frame window for decorated windows")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3697>

It's a bit unclear whether "should be shown" takes ability to actually
immediately show into account. Make this clear in a function doc
comment.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

Can be used to wait for a window to be "shown", meaning it'll be added
to the stack and will be part of the next frame (assuming it's actually
not obscured etc).

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

This is emitted when a client painted and committed new surface content.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

In most cases, we just want to fail the test if dispatching fails, so
add a helper that does that.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

This allows tests to check whether a state is set or not at any given
time.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

This, in contrast to meta_window_should_be_showing() reports whether a
window should be showing despite not being showable. This is useful to
know the intended visibility state that should happen in the immediate
future.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

Instead of initializing to 'suspended', which will send the `SUSPENDED`
xdg_toplevel state, set it to hidden at first. If the window is placed
on an inactive workspace, it'll eventually enter the 'suspended' state,
but will have had some time in non-suspended state to get map, even if
not visibly.

This fixes inital suspended state when mapping a window maximized.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3229
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3475>

The current code checking keyboard serials for popup/grab
validation is a bit simple, tracking one key press exclusively.
This may break expectations if a client uses a serial
corresponding to a previous key that is still pressed.

Keep track of the serials corresponding to all pressed keys,
and ensure these are reset across focus changes, since the
validity of those serials is already outdated. The code does
still keep track of a single (last) key release serial, since
the validity lifetime is somewhat underdefined with those if
we keep track of multiple keys simultaneously.

Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3267
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3644>

The precondition checks in meta_selection_source_memory_new can return
NULL if the mimetype is NULL but callers expect the error to be set when
NULL is returned.

Let's just make sure we never call it with a NULL mimetype.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>

When there is a new owner but there is no matching mime type we clear
the saved mimetype and the saved clipboard but an outstanding async
meta_selection_transfer_async can set the saved clipboard.

Abort the async transfer when we have a new owner.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3678>

This call is meant to replace meta_wayland_keyboard_get_focus_client(),
since we will always have a MetaWaylandSeat with an input focus (or not),
but we may or may not have a MetaWaylandKeyboard.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3707>

The concept of "input focus" will exist	regardless of a	MetaWaylandKeyboard
being available	or not,	use the	seat's focus for that.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3707>

The concept of "input focus" will exist regardless of a MetaWaylandKeyboard
being available or not, use the seat's focus for that.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3707>

All its users did not necessarily depend on a MetaWaylandKeyboard
existing, so were ported to using the MetaWaylandSeat global input
focus. This may now be dropped.

Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3707>

Update NEWS.