And return early from `swap_buffers_with_damage` if the error would have
led to flipping a NULL buffer.
This is also the perfect time to remove the `egl_context_changed` parameter
and move `_cogl_winsys_egl_ensure_current` closer to the code that actually
needs it.
Related: https://bugs.launchpad.net/bugs/2069565
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3817>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
So that swap failure messages are not also followed by:
meta_stage_native_redraw_view: runtime check failed: (!META_IS_CRTC_KMS (crtc))
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3817>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
It won't be used until later when we flip, and in fact assigning
it early could have led to its own assertion failing on the next frame
in the unlikely event that we return with "Failed to ensure KMS FB ID...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3891>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
`update_secondary_gpu_state_post_swap_buffers` decides what our front
buffer object will be. There is only one answer. So return it as the
function result instead of making the caller figure it out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3830>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
It's always equal to `onscreen_native->next_frame` and we can't eliminate
that copy so easily. Removing the parameter removes all ambiguity about
where the next frame will come from.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3829>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
Let the ClutterFrame (or rather MetaFrameNative) own both the scanout
object and the framebuffer object, and let the frame itself live for as
long as it's needed. This allows to place fields that is related to a
single frame together, aiming to help reasoning about the lifetime of
the fields that were previously directly stored in MetaOnscreenNative.
Also take the opportunity to rename "current" to "presenting", to make
it clearer that frame's buffer is what is currently presenting to the
user.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3799>
Signed-off-by: Mingi Sung <sungmg@saltyming.net>
When the screen is scaled and we are recording/sharing the screen we may
end up crash as per trying to create a 0-sized texture due to missing
ceiling of the texture size.
This is similar to what was fixed in commit 4d4e8e5862 and the same
fix was included in commit 422ee4515, but hidden under a compilation fix
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3978>
When triple buffering, `meta_onscreen_native_prepare_frame` for the next
frame is called before `notify_view_crtc_presented` for the previous frame.
So our booleans were unfortunately still TRUE in the second prepare_frame,
resulting in two frames with the same property updates.
When double buffering, having roughly one frame interval between
`meta_onscreen_native_prepare_frame` and `notify_view_crtc_presented`
meant that property updates signalled between the swap and presentation
wouldn't get attached to a KMS update, and would be forgotten when
`notify_view_crtc_presented` resets the flags to FALSE.
To solve these we now keep a separate flag and counter per property,
tracking invalidation and pending updates respectively. The latter is a
counter rather than a boolean in support of triple buffering where two
updates may be pending concurrently (next and posted).
Origin: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3912
(cherry picked from commit a04d90d9e7)
This is usually an indication of a failed drop operation if the
drop site didn't request any target. Check for this specifically
on XDnD button release, so that we can cancel the DnD operation
right away.
Inspired on a fix from Jonas Ådahl.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3821>
(cherry picked from commit ef3de1e58e)
We were relying on the drag source surface to keep receiving events
thanks to it being implicitly grabbed by the button press. This
broke at some point, making the Xdnd drag source unable to keep
directing the DnD operation as it is expected by X11 clients.
To fix this, make the Xdnd MetaWaylandEventInterface stick itself
to the drag source surface keeping the focus of the device driving
the DnD operation, so that the X11 client can still handle events
from it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3511
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3821>
(cherry picked from commit fd1d8c778b)
Using GL_BGRA8_EXT as internalformat for TexSubImage2D was not allowed
in the EXT_texture_format_BGRA8888 extension. This changed recently:
https://registry.khronos.org/OpenGL/extensions/EXT/EXT_texture_format_BGRA8888.txt
1.4, 23/06/2024 Erik Faye-Lund: Add GL_BGRA8_EXT for ES 2.0 and later.
Mesa already supports this which is why 7f943613a8 ("cogl: Use sized
internal renderable formats") worked as intended. Technically spec
compliant and our CI had an up-to-date driver.
So while this is no bug, it's still not great because older drivers will
generate GL errors. This commit changes this specific format back to an
unsized internal format which means we could, in theory, get less than
8bpc framebuffers.
We can try to revert this commit when newer driver versions have
propagated far enough.
Fixes: 7f943613a8 ("cogl: Use sized internal renderable formats")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3954>
(cherry picked from commit 45dcfeb0cc)
There is one define for the format (GL_BGRA_EXT) and one for the
internal format (GL_BGRA8_EXT). Use them appropriately.
This also adds defines to consistenly not use the _EXT postfix.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
(cherry picked from commit c3eb01e547)
The opaque fp16 Cogl format variants need a required format that is
already premultiplied whereas the fp16 formats with an alpha channel can
be either straight or premult.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3914>
(cherry picked from commit d820fe030a)
The OpenGL specs say rounding is preferred, but not required. Let's
avoid that uncertainty by choosing a test value that rounds and truncates
to the same integer either way. Only green needs fixing since our red,
blue and alpha values already follow this rule.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3903>
(cherry picked from commit 7df6b5c4ed)
Because if the current theme has exceeded the dimensions of
`DRM_CAP_CURSOR_WIDTH/HEIGHT` then the warning is just going to repeat
every time the cursor changes. We still fall back to software cursors
just fine so it's not important to repeat the warning.
Also the theme cursor size is not "Invalid" so we change the message to
match that of 47 main.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3597
Simply to make it clear that the renamed function is specific to a
particular X11 initialization mode (mandatory Xwayland), put that in the
name, so that it's easier to understand when this function is relevant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
This means that for X11 sessions we'll do it before any windows are
mapped, and before any plugin implementation is started. Doing it before
a plugin is started is important, because things that the plugin does
during startup can have consequences on how compositing on Xorg works.
For the Xwayland case, we'll do it relatively in the setup phase. It
appears to have been harmless to do it later in the post-opened signal,
but there is no harm in doing it as one of the earlier steps.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3089
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3329>
This gives greater control to the callers on the place where a grab is being
activated, this may make a difference in the handling of crossing events
triggered through it, e.g. by having callers rely on having already obtained
a ClutterGrab prior to handling the resulting effects.
The "input only" grab has also been turned inactive by default, in order to
to have the ClutterGrab pointer available for checks at the MetaWaylandEventHandler
focus changing methods triggered through grab activation.
(cherry-picked from commit 8e5f3a1f83)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3874>
When cloning an actor we were applying a global scale to it, based on
the size of the clone itself and of the cloned actor.
This implied that the transformed size of the clone was not the one that
was set, but it was taking taking in account the actor scaling too.
So in practice we were scaling it twice.
While this had no visual implications it indeed was causing troubles
when a ClutterClone was reactive because in such case only the scaled
area of the scaled clone was considered reactive.
Assume you had an actor of 100x100 pixels, scaling it to a clone of
50x50 pixels:
- The scale applied to the clone was 0.5
- The transformed size of the clone was: 25x25 pixels
- The clone was reactive only in that sub-area
To avoid this, never touch the clone transformation matrix, but only
transform it at paint time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2959>
(cherry picked from commit 44c0c311ba)
The two dialog creation virtual functions returned by these functions have to
be unreferenced by the caller (and are actually unreferenced in other places in
the code).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3790>
(cherry picked from commit 4134d12789)
If the titlebar of a window has been moved above the screen by a user
via an unconstrained move, then any constrained user resize following
this move will cause the window to jump below the top of the screen or
cause other glitchy behavior.
This commit removes the constraint that the titlebar of a window must be
below the top of the screen for any resize that is both (1) triggered by
a user and (2) is a resize that affects only the left, right, or bottom
edges of the window. This allows users to move a window partially above
the screen and then resize the window to be wider or resize the bottom
edge of the window to make it taller or shorter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1206
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3764>
(cherry picked from commit 5ba364a947)
Right now the unmapped signal doesn't always fire which means we didn't
see a surface that's being unmapped in these code paths before. In
particular the resource, window and role can be gone. Handle those
cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3783>
(cherry picked from commit 3e7b1d9cbd)
When mutter creates a dma-buf buffer for screencasting, the buffers
stride will, among other attributes, also be defined.
However, mutter currently only sets the buffer stride, when actually
recording a frame, but not when adding it.
This behaviour disallows screencast consumers (clients) to already
import the respective buffer (i.e. for Vulkan creating a VkImage for the
dma-buf image), as the stride is not yet communicated to the client.
Since the stride won't change after adding the respective buffer,
directly set the buffer stride, when adding the PipeWire buffer. This
allows screencast consumers (clients) to do optimizations in their
encoding paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3827>
(cherry picked from commit 0dd4080509)
