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>
Until this surface or its parent is finalized.
This makes sure that any `MetaWaylandSubsurfacePlacementOp` referencing
this surface for sibling will be applied as intended.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3737>
Fix an obvious copy paste error that slipped through the cracks.
Fortunately it doesn't have a visual impact for well behaving clients
but only makes us not hit direct-scanout paths, assuming no other bugs
in the stack.
Fixes: f21762ea6e (wayland: Add support for preferred_buffer_scale/transform)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3717>
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>
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>
Turns out there is a better solution: Almost always, MetaWindow already has
an idea on which monitor it will be, even if it isn't positioned yet. Since
the last commit we're now using that monitor for setting the
highest-output-scale of the window, so this fallback is no longer necessary.
While we could keep this fallback around and also return a valid scale in
case the surface is not even mapped yet, this means we report fractional
scale twice for new surfaces: Once from
wp_fractional_scale_manager::get_fractional_scale() (here we'll enter the
fallback), and a second time (this time with correct scale) right after
creating the MetaWindow.
Note that wp_fractional_scale_v1 doesn't specify that a preferred_scale
event must be sent immediately after
wp_fractional_scale_manager::get_fractional_scale(), so we can safely remove
the fallback.
This reverts commit 8cfbdb4313edbd7748fb21769d37bf5c35692042.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3598>
Currently, we blindly apply the transformation matrices of all parent
actors when calculating the absolute coordinates. This means if this
function is called while the window actor containing the surface is in
the middle of a transition (e.g. window open animation), it may return
incorrect values. As this function is used for calculating pointer
confinement bounds for a specific surface, this will result in incorrect
bounds value being used if pointer constraints are applied by the
application at the same time the window is created and the mouse is
inside the surface's bounds when it's created.
Fix this by only applying transformation matrices up to the window actor
of the surface and then calculating the absolute coordinates by adding
the position of the window actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3585>
If we don't have a monitor for a surface - e.g. because the surface is
not mapped yet - return the highest scale of all outputs. This makes us
send a preferred scale before a client draws its first frame. The highest
scale is always correct in single monitor cases and arguably a good
option otherwise as scaling down usually looks better than scaling up.
Note that this is currently only used by the fractional scale protocol,
but will also be used for the core `send_preferred_scale()` once we
implement it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3217>
Until now we only supported direct scanout to the primary plane if the
buffer size perfectly matched the display size.
Since display controllers usually support scaling and cropping buffers
highly efficiently, try to let them do the job. This is usually helpful
if wp_viewporter is used by the client or Mutter uses fractional
scaling.
This has several advantages:
- Games (e.g. SDL2 based ones) can almost always hit direct scanout
paths in fullscreen mode. Notably when fractional scaling is used or
the game renders in a non-native resolution (or both).
- Video players using YUV buffer formats and wp_viewporter can easily
hit direct scanout paths, making displaying video very power
efficient as the 3D engine is not used at all.
Note that this still only uses the primary plane, no overlay or underlay
planes, making this change comparatively low risk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
This allows us to pass on the related data from CoglScanouts.
If dst_rect does not match the mode, we assume that not covered areas
are opaque black - usually black bars around a centered surface.
While such driver behaviour does not appear to be documented (well) yet,
it seems to be followed by all known existing drivers and is used in a
similar way in ChromeOS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3177>
There doesn't seem to be a good reason to keep this code in
`MetaWaylandSurface`. Moving it to `MetaWaylandBuffer` cleans things
up and will allow us to tread buffers differently depending on their
type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3559>
A surface commit may change the buffer scale but not attach a new
buffer. In that case, the size of the previously attached buffer needs
to be consistent with the new buffer scale.
Fixes: 7649e2f3abd5 ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
meta_wayland_surface_get_buffer_width/height uses the currently applied
buffer, which may have a different size.
Fixes: 7649e2f3abd5 ("wayland/surface: Move buffer size check to meta_wayland_surface_commit")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3466>
Multiple reasons:
* More consistent with the protocol spec language.
* Ensures the size is checked and the protocol error sent from a
protocol processing context, instead of whatever context
meta_wayland_surface_commit might get called from.
* The latter implies that surface->resource is guaranteed to be valid.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3211
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3463>
In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
Stop taking a ClutterEvent and pass the essentials here (x/y/evtime),
we don't have a ClutterEvent handy in all places that we call this
API, and it feels awkward to create one just for calling this vmethod.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
To be able to later support more complex YUV formats, we need to make
sure that MetaShapedTexture (the one who will actually render the
texture) can use the MetaMultiTexture class.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Daniel van Vugt <daniel.van.vugt@canonical.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
Implement the stable rounding algorithm as described in the discussions
for the fractional-scale-v1 protocol.
This adds an override of the ClutterActor::apply_transform vfunc for
MetaSurfaceActorWayland that ensures the size and position of the
contents of the surface are rounded according to the stable rounding
algorithm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
Otherwise binding new wl_output's might try to send enter to the
destroyed resource. Fixes the following crash:
#0 wl_resource_get_client at ../src/wayland-server.c:801
#1 handle_output_bound at ../src/wayland/meta-wayland-surface.c:1287
#3 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3812
#6 ffi_call_unix64 at ../src/x86/unix64.S:104
#7 ffi_call_int at ../src/x86/ffi64.c:673
#8 ffi_call at ../src/x86/ffi64.c:710
#9 wl_closure_invoke at ../src/connection.c:1025
#10 wl_client_connection_data at ../src/wayland-server.c:438
#11 wl_event_loop_dispatch at ../src/event-loop.c:1027
#12 wayland_event_source_dispatch at ../src/wayland/meta-wayland.c:125
#15 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#17 meta_context_run_main_loop at ../src/core/meta-context.c:482
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2196527
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2992>
The intention when the offset request was added to protocol was
that the attach request in a new enough protocol version should
require dx/dy to be zero, but ignore them otherwise.
The current code checks for 0, but then overwrites the existing
dx/dy with it, which renders an earlier wl_surface_offset() call
ineffective.
Fixes: #2622
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2843>
