New protocol that allows a client to require that a previously flagged
content update must be presented before a content update can be applied.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3355>
The cogl_scanout_get_dst_rect() fell back on the buffer dimensions as
the destination rectangle when nothing was explicitly set. This,
however, is not necessarily correct. For example, if a buffer is larger
the CRTC resolution, but the surface is scaled to exactly match the CRTC view,
the expected destination size should match the CRTC resolution, not the
buffer dimension, which would be the case if no explicit destination was
set.
In meta_wayland_try_aquire_scanout() we're in a good position to
determine the destination rect in the CRTC primary plane, since we have
all the prerequisits, i.e. that the surface effectively covers the whole
CRTC, the actor allocation box (the non-black border part), the scale
and transform of the view.
This tweaks the CoglScanout API a bit to make it explicit that the
dst_rect must be unconditionally provided, and removes the fallback to
the buffer dimension as the destination rectangle, which sometimes
resulted in a destination rectangle being larger than the primary plane
itself, resulting in clipping and incorrect scaling.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3773
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4147>
The "dst_rect" calculated is in "CRTC space", meaning the bounding box
used for calculating it should be the view layout dimension, scaled by
the view scale and transform by the view transform. Previously it was
only transformed, not scaled. While fixing this, rename the variables to
make it a bit more clear what coordinate space they are expected to be
in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4147>
Allow scale-aware Xwayland clients to scale by an integer scale
themselves, instead of letting them render them at 1x scale and then
scaling up the texture, making it look blurry.
When monitor framebuffers are scaled, this special cases Xwayland and
sends output regions in a way that Xwayland think everything is N times
as large as the logical region, where N is the ceil of the max monitor
scale.
This is done by introducing a "stage" vs "protocol" coordinate space for
X11, where the "protocol" coordinate space is "stage" multiplied by a
scaling factor.
Xwayland thus will have its own "effective scale", sent via
wl_output.scale. The effective Xwayland scale is also used for the
internal MetaWaylandSurface scale internally, unless there is a viewport
dst size set on the same surface, in which case the scale is still set
to 1, to not interfere with wp_viewport semantics.
We're guarding this behind a new experimental feature
"xwayland-native-scaling", which can only come into effect when enabled
together with "scale-monitor-framebuffer".
[v2]:
Move stage_to_protocol/protocol_to_stage to generic window class.
This means parts that aren't aware of any windowing system specific
logic, only that coordinates originate from there for a given window,
can still get their coordinates properly handled.
In particular, this means coordinates from IBus that originates from the
client, can be scaled properly when that client is using X11.
Also make them properly introspected.
[v3]:
Split up coordinate transform API.
Make it one that takes a MtkRectangle, and another that takes a point.
This means the rounding strategy becames explicit when transforming a
point, while when it's a rectangle, it's still always "grow".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3567>
Toplevels get the main monitor from their MetaWindow and have no main
monitor when the toplevel is not mapped.
Subsurfaces get the main monitor from their parent surface.
DnD and cursors get the main monitor from the current cursor position no
matter if the cursor is actually being shown or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3941>
The main monitor is role dependent. For a toplevel this comes from the
MetaWindow main monitor, for a subsurface from the parent surface, for
pointer and dnd from the cursor position.
The next commit will use meta_wayland_surface_set_main_monitor in the
different roles to keep the property up-to-date.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3941>
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>
