Implements the "prior window window geometry dimensions" as described in
the documentation of 'xdg_toplevel' request 'unset_maximized':
"If available and applicable, the compositor will include the window
geometry dimensions the window had prior to being maximized in the
configure event."
and 'unset_fullscreen':
"The compositor may include the previous window geometry dimensions in
the configure event, if applicable."
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/792.
If this call is available, we can turn libX11 IO errors (fatal by definition)
into something we can recover from. Try to dispose all X11 resources and close
the display instead, so the compositor can survive the event.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1447
If the MetaX11Display abruptly closed when X11 windows were present,
we would still try to deal with them while freezing/thawing for the
"fade out" animation.
At the bottom of that, the X server may be gone, just try to cope
with it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1447
We're going to enforce some invariants a bit stricter and will only
allow allocating if an actor is mapped, not only visible.
Since actors are only mapped if their parent is mapped and stages are
hidden by default, we need to show the stage to ensure the actors are
mapped before we allocate them. So do that and call clutter_actor_show()
on the stage before fake-allocating the test actors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Bug 448183 fixed an issue with _NET_WM_MOVERESIZE_WINDOW not moving a
window by basing the resize on the current (new) rectangle instead of
the original rectangle.
While this fixes the issue with _NET_WM_MOVERESIZE_WINDOW, this also
causes windows with a size increment to move when the resize also
implies a move, such windows might drift while resizing.
Make sure to use the current rectangle for non-interactive resizes only.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/543
The XSizeHints set by X11 clients give a hint to the window manager
about size increment, aspect ratio, base, minimum and maximum size, etc.
When an X11 client changes those values, there is a good chance that it
will affect the actual window size in some way, and mutter rightfully
queue a window resize in that case.
However, mutter does not check if any of the hints have actually changed
and unconditionally queue a window resize whenever a client changes its
WM_NORMAL_HINTS property.
That can be a problem when a zealous client such as xterm decides to
update its WM_NORMAL_HINTS property on resize, because in return mutter
will queue a non-user driven resize in the middle of user-driven events,
hence defeating the purpose of the META_MOVE_RESIZE_USER_ACTION flag.
To avoid that issue, make mutter a bit smarter and avoid queuing a
window resize if the XSizeHints haven't actually changed.
https://gitlab.gnome.org/GNOME/mutter/-/issues/543
On interactive resize, mutter calculates the difference in size based on
the pointer location and relies on window constraints to ensure the
minimum size is honored.
Wayland however does asynchronous window configuration, meaning that not
checking for size hints early enough may lead to the window moving as
the locations was initially computed on a size which will be invalidate
by the client eventually.
Make sure to respect the client size hint on update_resize() so that we
don't end up with a window moving unexpectedly when the client
eventually acked the configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1495
Many tablets have a native portrait mode panel, yet come with a keyboard dock,
where the device gets docked in landscape mode. To avoid the display being
on its side when mutter starts while the tablet is docked, we need to take
the accelerometer reported orientation into account even if there is a
tablet-mode-switch which indicates that the device is NOT in tablet-mode
(because it is docked).
Add special handling for the first time the "orientation-changed"
signal gets signalled by the orientation-manager, which happens after it
has successfully claimed the accelerometer with iio-sensor-proxy.
The added special handling of the initial "orientation-changed" signal
does a number of checks:
1. panel_orientation_managed is false because of the tablet-mode-switch and not
because of other reasons.
2. The device has a native portrait mode panel (and thus likely needs rotation
to display the image the right way up when docked).
If all these checks succeed then it continues with creating a new
monitors-config based on the orientation ignoring the panel_orientation_managed
value (for the initial/first "orientation-changed" signal only).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
The orientation reported by the orientation_manager may have changed while
panel_orientation_managed was false. So when panel_orientation_managed
changes to true we should re-check the orientation.
This fixes the orientation not being correct when e.g. taking a 360 degree
hinges 2-in-1 in clamshell mode (so landscape orientation) and then folding
it into tablet mode while holding it in portrait orientation.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Add support for the (mostly theoretical) case of an input-device
offering tablet-mode-switch functionality being unplugged.
This makes the has_tablet_switch handling identical to the has_touchscreen
handling, leading to more consistent code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Detect if a tablet-mode-switch device is already present when mutter
starts by checking for this from meta_seat_native_constructed. This
mirrors how we also set has_touchscreen from meta_seat_native_constructed.
This fixes tablet-mode-switches only being recognized when they are added
at runtime.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
Unconditionally setting has_touchscreen to check_touch_mode
when a new device gets added leads to has_touchscreen becoming
false when during runtime e.g. an USB keyboard gets plugged in.
Fix this by setting has_touchscreen to TRUE when check_touch_mode
is TRUE and leaving it alone otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
A first step towards abandoning the CoglObject type system: convert
CoglFramebuffer, CoglOffscreen and CoglOnscreen into GObjects.
CoglFramebuffer is turned into an abstract GObject, while the two others
are currently final. The "winsys" and "platform" are still sprinkled
'void *' in the the non-abstract type instances however.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1496
The spec states:
```
A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
and the parent surface is mapped. The order of which one happens
first is irrelevant. A sub-surface is hidden if the parent becomes hidden,
or if a NULL wl_buffer is applied. These rules apply recursively
through the tree of surfaces.
```
In the past we relied on Clutter actor behaviour to realize the recursive
part - which then broke in
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/664
when we changed the actor hierachy in regards to subsurfaces.
Explicitly encode the desired behaviour in `MetaWaylandSubsurface`, fixing
the issue and making it future proof.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1384
Aligning windows manually with other windows has become less important
since the advent of tiling. This decreases the usefulness of edge
resistance, which in fact many users perceive as lag nowadays.
Account for that by limiting resistance to screen and monitor edges by
default, and only include windows when the control key is pressed.
https://bugzilla.gnome.org/show_bug.cgi?id=679609
Commit 033f0d11bf added a fallback in case the tile monitor wasn't
set before, but didn't actually check for a previously set value.
As a result, the "fallback" is not set unconditionally, which may
differ from the expected monitor: The tile monitor is determined
by the pointer position, while the window's monitor is the one
where the biggest part of the window resides on.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1389
It's pointless to call into functions that produce information that will
end up nowhere, so lets not. This will generate less angst when doing
more intense data gathering and string generation in debug log calls.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1467
The timestamp sent with _NET_WM_FRAME_DRAWN should be in "high
resolution X server timestamps", meaning they should have the same scope
as the built in X11 32 bit unsigned integer timestamps, i.e. overflow at
the same time.
This was not done correctly when mutter had determined the X server used
the monotonic clock, where it'd just forward the monotonic clock,
confusing any client using _NET_WM_FRAME_DRAWN and friends.
Fix this by 1) splitting the timestamp conversiot into an X11 case and a
display server case, where the display server case simply clamps the
monotonic clock, as it is assumed Xwayland is always usign the monotonic
clock, and 2) if we're a X11 compositing manager, if the X server is
using the monotonic clock, apply the same semantics as the display
server case and always just clamp, or if not, calculate the offset every
10 seconds, and offset the monotonic clock timestamp with the calculated
X server timestamp offset.
This fixes an issue that would occur if mutter (or rather GNOME Shell)
would have been started before a X11 timestamp overflow, after the
overflow happened. In this case, GTK3 clients would get unclamped
timestamps, and get very confused, resulting in frames queued several
weeks into the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1494
Mutter sends a proximity-in event before the required tablet tool
resource is properly allocated on the client. This is violating the
Wayland protocol. Because libwayland ignores events for objects it
doesn't know yet, this is not noticeable in most applications. However,
if https://gitlab.freedesktop.org/wayland/wayland/-/issues/176 gets
fixed, these applications would likely crash immediately. Therefore this
PR removes the responsible code which, again, shouldn't have any effect
on client applications as they ignore this event anyway.
Relevant part of the spec:
This event can be received when the tool has moved from one surface to
another, or when the tool has come back into proximity above the
surface.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1427
When we resize a window we send it configure requests with size
suggestion. Some clients, e.g. gnome-terminal will limit its size to a
discrete set given the font size resulting in the size often not being
respected completely, but used as a hint to find a size as large as
possible but not larger than the configured size.
When doing an interactive resize dragging the right or top side of a
window, this caused issues with the configured window size not matching
the one used by the client, as the configured position wouldn't be
correct for the actual size. Fix this by offsetting the position given
the size mismatch offset, making the position again in sync with the
size.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1447https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1477
Mutter still relies heavily on singletons such as its MetaBackend.
For that, the backend implementation has a meta_init_backend() function
which is called at startup from meta_init(), which creates the desired
backend and sets the singleton which is returned by meta_get_backend().
Unfortunately, that means that the backend is never actually freed, and
all the code from the backend finalize function never actually get
called.
Add a meta_release_backend() to free the backend singleton.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1438
The input settings constructor installs callback functions on device
added/remove and tool-changed.
However, on dispose, those signals are not disconnected, meaning that on
teardown, once the devices get removed eventually, the callback will
still fire and call the callback with freed data, causing a crash.
Make sure we clear the signals on devices on dispose, to avoid the crash
on teardown.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1438
A boring one, with the exception that row and column needed to be
swapped. For the sake of consistency, the variable names were also
synchronized with the values they hold, so e.g. xy → yx, etc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix already is a typedef to graphene_matrix_t. This commit
simply drops the CoglMatrix type, and align parameters. There is
no functional change here, it's simply a find-and-replace commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Ideally, we would use Graphene to do that, however as of now Graphene
lacks these APIs so we still need these helpers. Since we're preparing
to get rid of CoglMatrix, move them to a separate file, and rename them
with the 'cogl_graphene' prefix.
Since I'm already touching the world with this change, I'm also renaming
cogl_matrix_transform_point() to cogl_graphene_matrix_project_point(),
as per XXX comment, to make it consistent with the transform/projection
semantics in place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
During seat initialization, we process early libinput events (adding all known
devices) before the seat gets a stage assigned. This causes warnings when trying
to handle the corresponding CLUTTER_DEVICE_ADDED events, as they are sent
stageless.
As it is definitely too soon to have those events sent meaningfully, filter
those events out and instead handle the CLUTTER_DEVICE_ADDED emission for all
known devices after the seat receives an stage. This makes the events guaranteed
to be emitted early in initialization, but not so soon that they can't be
handled yet.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1472
Mutter itself is versioned now, so passing the version information
to the plugin is redunant now: The version is already determined by
linking to a particular API version (gnome-shell) or by installing
to a versioned plugin path (external plugins).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1473
A Meta.WaylandClient() object has a GSubprocessLauncher object
passed externally. Currently this object is kept while the
WaylandClient object exists, but is is only needed until the call
to spawn is made.
This patch frees that GSubprocessLauncher just after that call,
thus freeing those resources.
Fix https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1462
This reverts the commits 372d73e275 and 1d20045247 - the special
case for alpha-less textures could only happen on Wayland, but now
the opaque region is also set in those cases.
This commit saves us some allocations, simplifies the logic a bit and
makes sure culling uses the same opaque region as our painting paths.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463
Wayland clients using buffers without alpha channel are not expected to
set an opaque region. However, we rely on the opaque region for the fast
painting path in `MetaShapedTexture`.
Thus, make sure to always set an opaque region internally in those cases.
For X11 clients, wo do so already.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1463
Just like we used to before 30809665d8.
Because in some cases `clip_region` is able to shave off an extra pixel
from the edge of the redraw rectangle(s). And not shaving that off was
making the background rendering inconsistent with shaped-texture, causing
occasional off-by-one artefacts. Now both shaped-texture and
background-content agree on the clip region again that doesn't happen.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1443https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1464
This is essentially a revert of
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/326. This commit
had the unintended side effect that the built sources are actually
rebuilt for every individual user of libmutter_dep. With there being more
tests and generated files, the number of targets to build is increasing
squarely.
Not doing this reduces the number of targets from 2044 to 874, thus
saving man hours and CI burnt cycles in the long run. There's the slight
risk of reintroducing the random build breaks, but mutter is essentially
doing as suggested at https://github.com/mesonbuild/meson/issues/1084
(the only difference being addressed in the previous commit), so meson
ought to behave as expected.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1458
We only update the last device from actual input interaction here,
avoid this pair of events. This is specially nasty with
CLUTTER_DEVICE_REMOVED, since the device we're notifying upon will be
disposed soon after emission.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1460
Like it's done for the pointer in other places. Without a stage assigned,
some bits (like IM handling) may end up with events ignored, and misbehave.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1413
The Meta.WaylandClient constructor receives a GSubprocessLauncher
as a parameter, and stores it internally. Unfortunately, its
refcount value isn't increased, which results in the object being
released twice.
This patch fixes this bug.
Fix https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1454
When a MetaBarrier is first created it allocates a backend
impl object which does the actual heavy lifting.
Unfortunately, that backend object is never freed.
This commit ensures the implementation gets freed when
the barrier object is freed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1451
meta_barrier_destroy is responsible for removing the extra
reference added in meta_barrier_constructed.
Unfortunately, it fails to do this because of a misplaced early
return statement.
This commit removes the spurious return.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1449
This is already taken care of in meta_backend_monitors_changed(), called
from the same code paths that emit ::monitors-changed-internal. It is
better to leave this up to backend internals.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1448
We only did this if we weren't currently doing an interactive resize,
but since the finish_move_resize() is not the actual interactive resize
but the acknowledgment of the configure event that was emitted as a
result, we shouldn't limit ourself to the same flags used during resize.
This fixes temporarly "stuck" position of attached modal dialogs while
they are being resized.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1163https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1446
In X, buttons 1, 2, 3 are left, middle, right. In evdev, the order is
BTN_LEFT, BTN_RIGHT, BTN_MIDDLE. So setting a scroll button to 2 gave us a
middle button in the X session and a right button in a wayland session.
Fix that by hard-coding the LMR buttons handling.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1433
Even when a direct client buffer has a compatible format, stride and
modifier for direct scanout, drmModePageFlip() may still fail sometimes.
From testing, it has been observed that it may seemingly randomly fail
with ENOSPC, where all subsequent attempts later on the same CRTC
failing with EBUSY.
Handle this by falling back to flipping after having composited a full
frame again.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1410
If there is no laptop panel (for example on a desktop PC or a virtual
machine), attempting to put a NULL monitor in the list of matches
will just make mapping_helper_apply() crash.
Mitigates: https://gitlab.gnome.org/GNOME/mutter/-/issues/1414
Signed-off-by: Simon McVittie <smcv@debian.org>
It's enabled by default when using the i915 driver, but disabled
everywhere else until it can be made reliably an improvement. Until
then, for anyone want to force-enable it, add the string
'dma-buf-screen-sharing' to the experimental features list in GSettings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
Seems DMA buffer based interprocess buffer sharing is more broken than
not, so for now only enable it when using the i915 driver.
For example vmwgfx, qxl and radeon, it results in mmap() failing to mmap the
memory region. Other drivers, e.g. amdgpu will function, but may hit
very slow memory download paths, resulting in worse performance.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1442
We only want the panel autorotation to happen if the laptop has an
accelerometer, and is in tablet mode. Regular laptop mode should
lock the orientation, and let it be configured manually.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
So far, we've expected this signal to not happen whenever autorotation
shouldn't apply (no accelerometer is a strong reason). In future commits
we'll add further checks to this policy, so prevent autorotation to
change the display configuration if the MetaOrientationManager signal
happens but it should be ignored.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
Instead of having everyone check net.hadess.SensorProxy themselves, have
this all controlled by the MetaOrientationManager, and proxied everywhere
else via a readonly property in org.gnome.Mutter.DisplayConfig.
We want to attach more complex policies here, and it seems better to
centralize the handling of the autorotation feature rather than
implementing policy changes all over the place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1311
We used to pick the "best" output for each builtin/size/edid categories,
and then pick the "best" (in that order) of those for each input device.
This is most often enough, but is prone to wrong results in some corner
cases (eg. 2 outputs with the exact same dimensions).
Change this to a score mechanism that doesn't leave outputs out. The
weights are the same, but the score is accumulated if an output matches
multiple categories. All outputs are evaluated and sorted by score, and
input devices with the best matches are applied first (as they already
did).
This should break the tie if eg. there's 2 outputs with similar dimensions,
but one of them has some EDID match in addition. The output with multiple
matches will score higher up, while it might have been entirely discarded
with the previous implementation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1175https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1202
The work at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/239
intended to make integrated devices optionally mappable to other outputs
(in order to allow fix mishandling from our heuristics, or to quickly reach
things in other monitor without changing devices).
This was missed in that plan, we do allow cycling outputs, but we still did
prevent it from doing anything for integrated devices. Fix that, and change
output cycling so we don't allow a "NULL" EDID for integrated devices, this
makes those go through the MetaInputMapper (resulting in one output listed
twice), instead of mapping to the full stage.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1186https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1201
The cursor tracker may give us a valid position, and a
valid cursor sprite, and yet the cursor can be hidden,
meaning we must hide the cursor on the stream as well.
Remove cursor from stream buffer if it's hidden.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Scanouts are taken away after painting. However, when we're
streaming, what we actually want is to capture whatever is
going to end up on screen - and that includes the scanout
if there's any.
Add a before-paint watch that only records new frames if a
scanout is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
When there's a direct scanout set in the stage view, we
have to use it instead of the view's regular onscreen
framebuffer.
Use the new CoglScanout API to implement blitting to the
stream framebuffer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
This will be used when screencasting monitors so that if
there's scanout in place, it'll still be possible to blit
it to a PipeWire-owned framebuffer, and stream it.
Add a new 'blit_to_framebuffer' vfunc to CoglScanout, and
implement it in MetaDrmBufferGbm.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1421
Just because X11/XI uses a particular terminology doesn't mean we
have to use the same terms in our own API. The replacement terms
are in line with gtk@1c856a208, which seems a better precedent
for consistency.
Follow-up to commit 17417a82a5.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
Using opaque painting paths can have a big impact on painting performance.
In order to easily validate whether we use the opaque paths, add a opaque
(green) or blended (purple) overlay over painted areas if the
`META_DEBUG_PAINT_OPAQUE_REGION` `MetaDebugPaintFlag` is set.
You can do so in `lg` via:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
This can be helpful for application developers, as previously it was not
trivial to check whether e.g. Wayland or X11 opaque regions where
properly set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
Analogous to `ClutterDrawDebugFlag` but intended for concepts that
are not present in Clutter, such as Wayland/X11 opaque regions.
Also add the first flag for the later.
To set the flag, run:
`Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)`
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1372
This is no longer directly related to DBus messages, but our own event
queue. Change the wording and use CLUTTER_PRIORITY_EVENTS to make it
bolder, even though it's the same than G_PRIORITY_DEFAULT.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
We set an idle to coalesce multiple IM events together, as the protocol
requires us to send them in one frame, and unfortunately there is no
idea about whether more IM events are upcoming.
One good hint though are key events generated from the IM, we want to
apply all IM changes before the key event is processed, so make it sure
that the .done event is flushed before the key event is handled.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
The clutter_input_focus_filter_key_event() function has been made
a more generic filter_event(). Besides its old role about letting
key events go through the IM, it will also process the IM events
that are possibly injected as a result.
Users have been updated to these changes.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1286
When in the overview culling via `self->clip_region` is unavailable.
The region is `NULL` because the paint call has not originated from a
`WindowGroup`, because the overview does not use `WindowGroup`.
So the main wallpaper was being painted in full while in the overview.
That's a waste of effort because `redraw_clip` is going to be used to
stencil/scissor out only the parts that are changing. We don't need to
paint *most* of the wallpaper, only the parts behind anything changing.
For the overview this reduces GPU power usage (intel_gpu_top) roughly
10% and reduces render times almost as much.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
`meta_background_content_paint_content` was mixing two different
coordinate systems in `actor_pixel_rect`. It was initialized with
actor-local coordinates and then `if (self->clip_region)` would be
treated as stage coordinates. This worked because `self->clip_region`
was only non-NULL outside of the overview where both coordinate systems
were the same. So it always got the right answer, possibly by accident.
In order to enhance the function however we will need to know which
coordinate system we're working in, so now we make it explicit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1363
There's no need to update the outputs recursively in case the actor gets
mapped or unmapped. That's because mapping happens recursively itself,
so if a window with multiple subsurfaces is shown, all subsurfaces will
receive a "notify::mapped" signal.
Since this was the only remaining user of
meta_wayland_surface_update_outputs_recursively(), we can now remove
that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1358
Since we now listen to the "stage-views-on-changed" signal (which
"catches" all the changes we want) on MetaWaylandActorSurfaces for
updating the wl_outputs the surface is on, we no longer need to call
meta_wayland_surface_update_outputs_recursively() on all geometry
changes, so remove that signal handler.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1358
ClutterActors new "stage-views-changed" signal fits pretty well for the
updating of wl_outputs a MetaWaylandActorSurface is on: With that signal
we get notified if the surface moved to a different CRTC, of which every
output has at least one.
So start listening to that signal, which fixes a bug where the wl_output
of a surface changes, but its allocation remains the same (which means
no signals triggering an update of the outputs will be emitted) and no
enter/leave events for the new wl_outputs are sent to the client. This
can happen when a monitor is hotplugged but the new allocation is
exactly the same as the old one even though it's on a different monitor.
Since the "stage-views-on-changed" signal will also get emitted when a
parent actor of the surface is moved, this means we can now remove the
call to meta_wayland_surface_update_outputs_recursively() on window
position changes or the completion of window-effects.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1358
QXL doesn't support mmap():ing a DMA buffer allocated in mutter inside
the PipeWire stream consumer process. To make screen casting work again
on QXL, disable DMA buffer based screen casting for QXL.
Eventually, it should be the client that renegotiates the supported
buffer types, but until then we need this list.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1318
The X server, including Xwayland, can be compiled with different X11
extensions enabled at build time.
When an X11 extension is built in the X server, it's usually also
enabled at run time. Users can chose to disable those extensions at run
time using the X server command line option "-extension".
However, in the case of Xwayland, it is spawned automatically by the
Wayland compositor, and the command line options are not configurable
by users.
Add a new setting to disable a selected set of X extension in Xwayland
at startup, without needing to rebuild Xwayland.
Of course, if Xwayland is not built with a given extension support in
the first place (which is the default for the security extension for
example), that option has no effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1405
Delay the addition and removal of devices using ClutterDeviceEvent's so that
they are processed following the libinput event order, and that we don't
have to flush the events on removal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
When a device is removed from the seat the events that this device may have
emitted just before being removed might still be in the stage events queue,
this may lead a to a crash because:
Once the device is removed, we dispose it and the staling event is
kept in queue and sent for processing at next loop.
During event processing we ask the backend to update the last device
with the disposed device
The device is disposed once the events referencing it, are free'd
The actual last device emission happens in an idle, but at this point
the device may have been free'd, and in any case will be still disposed
and so not providing useful informations.
To avoid this, once a device has been added/removed from the seat, we queue
ClutterDeviceEvent events to inform the stack that the device state has
changed, preserving the order with the other actual generated device events.
In this way it can't happen that we emit another event before that the
device has been added or after that it has been removed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345
When removing a device that has been just marked as the last in use, we may
try to notify that a NULL device is the last one.
This is not supported, as both update_last_device() and the clients of the
"::last-device-changed" signal are assuming that the last device is always
a valid ClutterInputDevice.
So let's avoid erroring, and stop the idle when clearing the current device.
Related to: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
A GAppInfo is not guaranteed to have a filename or an application (or
rather a desktop ID). Add a check for application_id to be non-NULL
before trying to call sn_launcher_set_application_id, which would crash
otherwise.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1392
PipeWire reuses buffers, and buffer metadatas, when streaming. When
the cursor is moved to outside the stream, the cursor meta also needs
to be updated, otherwise it'll use the cursor position of whatever is
in the buffer.
Don't bail out when cursor is outside the stream, and ensure to record
a metadata-only frame. This only applies to metadata streams.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1417
If we returned early in one of the checks but already assigned the
surface role, we'd later run into a double-free and crash. Just do
the checks at the beginning.
Also add a missing return statement that was left out in commit
88ff196fe3 and tighten the parent surface check.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1415
The spec allows `parent_resource` to be `NULL`, requiring the parent
surface to get specified by some other protocol. Send a protocol error
with some meaningful explanation instead of crashing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1408
Currently, the maximum size for a mouse pointer bitmap for screen
casting is 64x64 pixels.
However, this limit is hit way too often as it is way too low and
results in crashes in either gnome-remote-desktop or mutter.
For example: The a11y settings in g-c-c allow setting a larger pointer
bitmap in order to increase the visibility of the mouse pointer.
With the current limit of 64x64 pixels it is not possible to use the
larger variants of the default mouse pointer bitmap, without
experiencing any crash.
Another way to hit the limit is when display scaling is used or some
game uses a custom (large) mouse pointer bitmap.
The VNC backend in gnome-remote-desktop does not seem to have a maximum
pointer bitmap size.
The RDP backend on the other hand has a maximum pointer bitmap size at
384x384.
Use this size (384x384) as maximum size instead of the current 64x64
size for mouse pointer bitmaps to avoid crashes in mutter and
gnome-remote-desktop and to ensure that bigger mouse pointer bitmaps
can be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1414
It is linear config manager created when ensuring configuration.
However, the switch config is not set as LINEAR, but left as UNKNOWN.
This leads switch mode OSD always shows "Join Displays" icon, rather
than the next icon which is "External Only" after connect an external
display and press Super+P once at first time since mutter starts.
This patch moves switch config setting into
meta_monitor_config_manager_create_linear() (and the sibling functions)
to well prepare the monitors config and avoid missing settings.
This is a regression introduced by 149e4d6934.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1362
Clients can set minimum and maximum to identical values to indicate a
fixed-size window. A compositor can ignore these requests and thus a client
has to ensure these limits.
To support clients that do not ensure these size limits by themselves and
to skip unnecessary function calls, we will prevent resizing requests by
the client if a fixed-size has been requested.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1331
We're moving towards not supporting stand-alone application style
clutter stages, meaning the stage tests use will be reused instead of
recreated. To make this feasable, tests must clean up after themself.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
meta_run() is still left intact and does the same as before; the new
functions are only intended to be used by tests, as they may need to set
things up after starting up. Doing so linearly in the test case is much
easier than adding callbacks, so meta_run() is split up to make this
possible.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
The delete event was used for signalling the close button was clicked on
clutter windows. Being a compositor we should never see these, unless
we're running nested. Remove the plumbing of the DELETE event and just
directly call meta_quit() when we see it, if we're running nested.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
We checked if we were using the usig the X11 backend to decide when to
deal with a11y event posting - in order to make the clutter code less
windowing system dependent, make this check a check whether we're a
display server or not, in contrast to a window/compositing manager
client. This is made into a vfunc ot ClutterBackendClass, implemented by
MetaClutterBackendNative and MetaClutterBackendX11.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
Test that if a timeline got its frame clock from a parent of the
associated actor, if that actor moves across the stage so that the stage
views changes and thus the would be picked frame clock too, this is
noticed by the timeline so that it also changes to the correct frame
clock.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
Timelines where the frame clock was picked from a parent of the
associated actor didn't get notified about any stage views changes, as
it only listened on the associated actor. If that actor didn't actually
get its stage views changed (because it went from empty to empty), we'd
end up with a stale frame clock, leading to crashes.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
Flip flop resize, which is the result of respecting ConfigureNotify
makes test annoyingly racy, as one cannot do
clutter_actor_set_size (stage, 1024, 768);
wait_for_paint (stage);
g_assert_assert (clutter_actor_get_width (stage) == 1024);
The reason for this is any lingering ConfigureNotify event that might
arrive in an inconvenient time in response to some earlier resize.
In order to not risk breaking any current behavior in the X11 CM case
(running as a compositing window manager), only avoid changing the stage
size in response to ConfigureNotify when running nested.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
This aims to make sure a view and its resources are destroyed when it
should. Using references might keep certain components (e.g frame clock)
alive for too long.
We currently don't take any long lived references to the stage view
anywhere, so this doesn't matter in practice, but this may change, and
will be used by a to be added test case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1404
Just as wl_shm, hook up the Wayland DMA-BUF protocol to the 64 bit half
point pixel formats too. This makes it possible for Wayland EGL clients
to use 64 bit pixel EGL configurations.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
Now that cogl understands them, hook wl_shm up so they can be used.
This also bumps the wayland-server version dependency to 1.17.90, which
corresponds to the master branch of wayland. The new formats will be
available in 1.18.0.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
Without doing this, we'd use the same sprite that was last set by
mutter, most likely a leftptr cursor, and fail to update when e.g.
moving the pointer above a text entry and the displayed cursor updated
to a cursor position marker.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
The displayed cursor is the one displayed on the screen, e.g. via the
hardware cursor plane, by Xorg, or using the stage overlay.
When screen recording under X11, we don't get a stream of pointer and
cursor updates, as they might be grabbed by some other client. Because
of this, the cursor tracker or cursor renderer are not kept up to date
with positional and cursor state.
To be able to use the stage overlays when recording, we need to be able
to update the overlay without updating the displayed cursor, as we
shouldn't update the X server with cursor state we just retrieved from
it.
Thus, to achieve this, create a separate overlay cursor pointer. When
being a display server, they are always the same, but when using X11,
during screen recording, the overlay one will be polled at a fixed
interval to get a somewhat up to date state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Always force-track the cursor position (so that the X11 backend can keep
it up to date), and if the cursor wasn't part of the sampled
framebuffer when reading pixels into CPU memory, draw it in an extra
pass using cairo after the fact. The cairo based cursor painting only
happens on the X11 backend, as we otherwise inhibit the hw cursor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
On X11 we won't always receive cursor positions, as some other client
might have grabbed the pointer (e.g. for implementing a popup menu). To
make screen casting show a somewhat correct cursor position, we need to
actively poll the X server about the current cursor position.
We only really want to do this when screen casting or taking a
screenshot, so add an API that forces the cursor tracker to track the
cursor position.
On the native backend this is a no-op as we by default always track the
cursor position anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Only when the cursor isn't handled by the backend is the overlay made
visible. This is intended to be used when painting the stage to an
offscreen using clutter_stage_paint_to_(frame)buffer() in a way where
the cursor is always included.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
Detect displays marked as 'non-desktop' by the kernel and skip them when
creating the outputs. Mutter is not able to render images that are shown
properly on those devices anyway.
This avoids lighting up attached VR HMDs and showing the GDM login
screen between the eyes in a VR HMD instead of on the monitor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1393
Allowing code from inside mutter to create a child process and
delegate on it some of its tasks is something very useful. This can
be done easily with the g_subprocess and g_subprocess_launcher classes
already available in GLib and GObject.
Unfortunately, although the child process can be a graphical program,
currently it is not possible for the inner code to identify the
windows created by the child in a secure manner (this is: being able
to ensure that a malicious program won't be able to trick the inner
code into thinking it is a child process launched by it).
Under X11 this is not a problem because any program has full control
over their windows, but under Wayland it is a different story: a
program can't neither force their window to be kept at the top (like a
docker program does) or at the bottom (like a program for desktop icons
does), nor hide it from the list of windows. This means that it is not
possible for a "classic", non-priviledged program, to fulfill these
tasks, and it can be done only from code inside mutter (like a
gnome-shell extension).
This is a non desirable situation, because an extension runs in the
same main loop than the whole desktop itself, which means that a
complex extension can need to do too much work inside the main loop,
and freeze the whole desktop for too much time. Also, it is important
to note that javascript doesn't have access to fork(), or threads,
which means that, at most, all the parallel computing that can do is
those available in the _async calls in GLib/GObject.
Also, having to create an extension for any priviledged graphical
element is an stopper for a lot of programmers who already know
GTK+ but doesn't know Clutter.
This patch wants to offer a solution to this problem, by offering a
new class that allows to launch a trusted child process from inside
mutter, and make it to use an specific UNIX socket to communicate
with the compositor. It also allows to check whether an specific
MetaWindow was created by one of this trusted child processes or not.
This allows to create extensions that launch a child process, and
when that process creates a window, the extension can confirm in a
secure way that the window really belongs to that process
launched by it, so it can give to that window "superpowers" like
being kept at the bottom of the desktop, not being listed in the
list of windows or shown in the Activities panel... Also, in future
versions, it could easily implement protocol extensions that only
could be used by these trusted child processes.
Several examples of the usefulness of this are that, with it, it
is possible to write programs that implements:
- desktop icons
- a dock
- a top or bottom bar
...
all in a secure manner, avoiding insecure programs to do the same.
In fact, even if the same code is launched manually, it won't have
those privileges, only the specific process launched from inside
mutter.
Since this is only needed under Wayland, it won't work under X11.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/741
Intended to be used to pass state from screen cast clients down the
line. The first use case will be a boolean whether a screen cast is a
plain recording or not, e.g. letting the Shell decide whether to use a
red dot as the icon, or the generic "sharing" symbol.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1377
GLib will now be linking against sysprof-capture-4.a. To support that,
sysprof had to remove the GLib dependency from sysprof-capture-4 which
had the side-effect of breaking ABi.
This bumps the dependency and includes a fallback to compile just the
libsysprof-capture-4.a using a subproject wrap.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1352
Commit 510cbef15a changed the logic in `handle_update()` for X11 window
actors to return early if the surface is not an X11 surface.
That works fine for plain Xorg, but on Xwayland, the surface is actually
a Wayland surface, therefore the function returns early before updating
the drop shadows of server-side decorations for X11 windows.
Change the test logic to restore drops shadows with Xwayland windows.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1384
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1358
The memory selection source was only providing the "text/plain" or the
"text/plain;charset=utf-8" mimetype, but not "STRING" or "UTF8_STRING",
which some X11 clients, like wine, are looking for. This was breaking
pasting from the clipboard in wine applications.
Fix this by adding those targets when they are missing and the selection
source provides the corresponding mimetypes.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1369
Wine destroys its old selection window immediately before creating a new
selection. This would trigger restoring the clipboard, which would
overwrite the new selection with the old one. The selection window
however can also be destroyed as part of the shutdown process of
applications, such as Chromium for example. In those cases we want the
clipboard to be restored after the selection window has been destroyed.
Solve this by not immediately restoring the clipboard but instead using
a timeout which can be canceled by any new selection owner, such as in
the Wine case.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1338https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1369
The new "id" properties for the MetaCrtc* and MetaOuput* objects are 64-bit
values, so take care to pass 64-bit values when calling g_object_new.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1343.
When using its EGLStream-based presentation path with the proprietary NVIDIA
driver, mutter will use a different function to process page flips -
custom_egl_stream_page_flip. If that fails due to an EBUSY error, it will
attempt to retry the flip. However, when retrying, it unconditionally uses the
libdrm-based path. In practice, this causes a segfault when attempting to
access plane_assignments->fb_id, since plane_assignments will be NULL in the
EGLStream case. The issue can be reproduced reliably by VT-switching away from
GNOME and back again while an EGL application is running.
This patch has mutter also use the custom page flip function when retrying the
failed flip.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1375
Instead of blindly hoping that `$INCLUDE` contains the parent directory
of `gsettings-desktop-schemas`.
Because `gsettings-desktop-schemas.pc` says:
```
Cflags: -I/SOME/DIRECTORY/gsettings-desktop-schemas
```
Which means to include the version that Meson has configured you need
to drop the directory prefix and only `#include <gdesktop-enums.h>`.
This fixes a build failure with local installs triggered by 775ec67a44
but it's also the right thing to do™.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1370
During animation or other things that cause multiple frames in a row
being painted, we might skip recording frames if the max framerate is
reached.
Doing so means we might end up skipping the last frame in a series,
ending with the last frame we sent was not the last one, making things
appear to get stuck sometimes.
Handle this by creating a timeout if we ever throttle, and at the time
the timeout callback is triggered, make sure we eventually send an up to
date frame.
This is handle differently depending on the source type. A monitor
source type reports 1x1 pixel damage on each view its monitor overlaps,
while a window source type simply records a frame from the surface
directly, except without recording a timestamp, so that timestamps
always refer to when damage actually happened.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
Now that we don't use the record function to early out depending on
implicit state (don't record pixels if only cursor moved for example),
let it simply report an error when it fails, as we should no longer ever
return without pixels if nothing failed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
Both do more or less the same but with different methods - one puts
pixels into a buffer using the CPU, the other puts pixels into a buffer
using the GPU.
However, they are behaving slightly different, which they shouldn't.
Lets first address the misleading disconnect in naming, and later we'll
make them behave more similarly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1361
That was obviously always the intention, but it didn't work when the
display was scaled. My 3840x2160 monitor with a 3840x2160 texture was
being rendered with LINEAR filtering.
It seems the `force_bilinear` flag was TRUE when it should be FALSE.
Because a texture area that's an integer fraction of the texture
resolution is still a perfect match when that integer is the monitor
scale. We were also getting:
`meta_actor_painting_untransformed (fb, W, H, W, H, NULL, NULL) == FALSE`
when the display was scaled. Because the second W,H was not the real
sampling resolution. So with both of those issues fixed we now get
NEAREST filtering when the texture resolution matches the resolution it's
physically being rendered at.
Note: The background texture actually wasn't equal to the physical monitor
resolution prior to January 2020 (76240e24f7). So it wasn't possible to do
this before then. Since then however, the texture resolution is always
equal to the physical monitor resolution.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1346
It doesn't take all children - subsurfaces in this case - into
account, thus creating glitches if subsurfaces extend outside
of the toplevel surface.
Further more it doesn't seem to serve any special purpose - it was
added in f7315c9a36, a pretty big commit, and no discussion was
started about the code in question. So it was likely just overlooked
in the review process.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/873
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1316
gnome-shell displays workspace previews at one tenth scale. That's a
few binary orders of magnitude so even using a LINEAR filter was
resulting in visible jaggies. Now we apply mipmapping so they appear
smooth.
As an added bonus, the mipmaps used occupy roughly 1% the memory of
the original image (0.1 x 0.1 = 0.01) so they actually fit into GPU/CPU
caches now and rendering performance is improved. There's no need to
traverse the original texture which at 4K resolution occupies 33MB,
only a 331KB mipmap.
In my case this reduces the render time for the overview by ~10%.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1416https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347
The frame clock owner should be able to explicitly destroy (i.e. make
defunct) a frame clock, e.g. when a stage view is destructed. This is so
that other objects can keep reference to its without it being left
around even after stopped being usable.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Currently there is a point in between hot plug, and when the stage view
list is up to date. The check also tests for this behaviour; would this
ever change, the test should be adapted to deal with this too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Replace the default master clock with multiple frame clocks, each
driving its own stage view. As each stage view represents one CRTC, this
means we draw each CRTC with its own designated frame clock,
disconnected from all the others.
For example this means we when using the native backend will never need
to wait for one monitor to vsync before painting another, so e.g. having
a 144 Hz monitor next to a 60 Hz monitor, things including both Wayland
and X11 applications and shell UI will be able to render at the
corresponding monitor refresh rate.
This also changes a warning about missed frames when sending
_NETWM_FRAME_TIMINGS messages to a debug log entry, as it's expected
that we'll start missing frames e.g. when a X11 window (via Xwayland) is
exclusively within a stage view that was not painted, while another one
was, still increasing the global frame clock.
Addititonally, this also requires the X11 window actor to schedule
timeouts for _NET_WM_FRAME_DRAWN/_NET_WM_FRAME_TIMINGS event emitting,
if the actor wasn't on any stage views, as now we'll only get the frame
callbacks on actors when they actually were painted, while in the past,
we'd invoke that vfunc when anything was painted.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/903
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This also changes the view construction path used by the renderer view
to use the new 'add_view()' function, meaning we have a common entry
point for views into the renderer, which will be useful later on.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Before we'd create the view in init(), then continue poking at it in
realize(). Move all of the screen stage view initialization to
realize(), as that's when we have all the dependent state available.
This is possible since there is nothing needing it until realizing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The repaint callbacks are not tied to repaint, thus a bit misleading.
What the functionality in the pre/post-paint callbacks here cares about
is when actually painting; the non-painting related parts has already
moved out to a *-update signal.
This also renames the related MetaWindowActorClass vfuncs, to align with
naming convention of the signals that it listens to.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Instead of going via MetaCompositor to know about when we updated
(confusingly named post-paint), use the new stage signal directly.
Note that this doesn't change the time frame callbacks are dispatched;
it's still not tied to actual painting even though it seemed so before
given the function names.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The clutter "thread" repaint callback are not tied to painting, but
indirectly to updating. What the cursor renderer cares about is when we
actually painted, as this is related to the OpenGL fallback paths.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We'd emit multiple "presented" signals per frame, one for "sync" and one
for "completion". Only the latter were ever used, and removing the
differentiation eases the avoidance of cogl onscreen framebuffer frame
callback details leaking into clutter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The vfunc was not tied to "paint", but was used by MetaWindowActorX11
as part of the "update" mechanisms. In order to make that more clear,
special case it in MetaWindowActorX11 by type checking the surface
actor, handling the case without MetaSurfacActor abstraction.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The synchronization must happen no matter the painting, as it in itself
might result in reported damage, making the stage actually painted. Thus
move it out of the "pre-paint" handler, to something explicitly not tied
to the painting itself - ClutterStage::before-update.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Instead of the 'pre-paint' signal on MetaCompositor, rely directly on
the 'before-update' signal on the stage. A reason for this is that the
callback should not only invoked in connection to painting, but updating
in general. Currently the 'pre-paint' signal is emitted no matter
whether there were any painting or not, but that's both misleading and
will go away.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The mutexes was used by ClutterTexture's async upload and to match GDK's
mutexes on X11. GDK's X11 connection does not share anything with
Clutter's, we don't have the Gdk Clutter backend left, and we have
already removed ClutterTexture, so lets remove these mutexes as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
A frame clock dispatch doesn't necessarily result in a frame drawn,
meaning we'll end up in the idle state. However, it may be the case that
something still requires another frame, and will in that case have
requested one to be scheduled. In order to not dead lock, try to
reschedule directly if requested after dispatching, if we ended up in
the idle state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The native backend had a plain counter, and the X11 backend used the
CoglOnscreen of the screen; change it into a plain counter in
ClutterStageCogl. This also moves the global frame count setting to the
frame info constuctor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We currently have mutter set a global frame counter on the frame info in
the native backend, but in order to do this from clutter, change the
frame info construction from being implicitly done so when swapping
buffers to having the caller create the frame info and passing that to
the swap buffers call.
While this commit doesn't introduce any other changes than the API, the
intention is later to have the caller be able to pass it's own state
(e.g. the global frame count) along with the frame info.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We had time unit conversion helpers (e.g. us2ms(), ns2us(), etc) in
multiple places. Clean that up by moving them all to a common file. That
file is clutter-private.h, as it's accessible by both from clutter/ and
src/.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Currently unused, but it's intention is to use as a initial refresh rate
for a with the stage view associated frame clock. It defaults to 60 Hz
if nothing sets it, but the native backend sets it to the associated
CRTCs current mode's refresh rate.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Without an associated actor, or explicit frame clock set, in the future
a timeline will not know how to progress, as there will be no singe
frame clock to assume is the main one. Thus, deprecate the construction
of timelines without either an actor or frame clock set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The MetaLater functionality needs to make sure an update is scheduled so
that it can run its callbacks etc. This used a ClutterTimeline (which is
an object more or less meant to drive animations markers, frames etc)
just to keep the master frame clock running. We're moving away from a
single master clock, so just schedule updates directly instead, with the
newly exposed API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
We'd check if there was any queued redraw on the stage, but this is
inappropriate for two reasons:
1) A monitor and area screen cast source only cares about damage on a
subset of the stage.
2) The global pending-redraw is going away when paint scheduling will be
more view centric.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The timestamp comes from the GSource, meaning it's a more accurate
representation of when the frame started to be dispatched compared to
getting the current time in any callback.
Currently unused.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
In certain scenarios, the frame clock needs to handle present feedback
long before the assumed presentation time happens. To avoid scheduling
the next frame to soon, avoid scheduling one if we were presented half a
frame interval within the last expected presentation time.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This adds a current unused, apart from tests, frame clock. It just
reschedules given a refresh rate, based on presentation time feedback.
The aiming for it is to be used with a single frame listener (stage
views) that will notify when a frame is presented. It does not aim to
handle multiple frame listeners, instead, it's assumed that different
frame listeners will use their own frame clocks.
Also add a test that verifies that the basic functionality works.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
When a transition is created for the allocation change, it will delay
the new allocation box getting set depending on transition details.
This, however, means that e.g. the 'needs_allocation' flag never gets
cleared if a transition is created, causing other parts of the code to
get confused thinking it didn't pass through a layout step before paint.
Fix this by calling clutter_actor_allocate_internal() with the current
allocation box if a transition was created, so that we'll properly clear
'needs_allocation' flag.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1345
41130b08eb added a fix for culling subsurfaces with geometry scale.
Unfortunately it only did so for the opaque regions, not for clip and
unobscured regions, as the effect was hidden by bug that was only
fixed by 3187fe8ebc.
Apply the same fix to clip and unobscured regions and use the chance
to move most of the slightly hackish geometry scale related code
into a single place.
We need to scale slightly differently in the two cases, indicated by
the new `ScalePerspectiveType` enum, as the scale is dependent on the
perspective - once from outside, once from inside of the scaled actor.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1312
Since we now always return a resource scale, we can remove the boolean
return value from clutter_actor_get_resource_scale() and
_clutter_actor_get_real_resource_scale(), and instead simply return the
scale.
While at it, also remove the underscore from the
_clutter_actor_get_real_resource_scale() private API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
Add private API to ClutterBackend to set a fallback resource scale
available to Clutter. This API will be used for "guessing" the
resource-scale of ClutterActors in case the actor is not attached to a
stage or not properly positioned yet.
We set this value from inside mutters MetaRenderer while creating new
stage-views for each logical monitor. This makes it possible to set the
fallback scale to the scale of the primary monitor, which is the monitor
where most ClutterActors are going to be positioned.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
The portal API requires a screencast session only for absolution motion
with remote desktop, other methods including relative motion do not
require a screencast session.
There is no reason to be more strict than the API actually is, check for
a screencast session only when required, like for absolute motion events
and touch events.
Tested with https://gitlab.gnome.org/snippets/1122
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1307
There are a couple of places in gnome-shell where we aren't interested
in which workspace is active, but whether a given workspace is active.
Of course it's easy to use the former to determine the latter, but we
can offer a convenience property on the workspace itself almost for
free, so let's do that.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1336
These tests were written (and copy-pasted) before ClutterActor
had an actual background-color property. As a preparation to
the removal of ClutterRectangle, replace all these rectangles
with plain actors and background colors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
The property is deprecated and the current implementation simply
redirects it to ClutterActor::background-color, so remove it.
Also update the tests to set the background color directly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
It is deprecated in favor of the 'z-position' property, and
the implementation itself redirects to the z-position, so
just drop it and replace all get|set_depth calls to their
z-position counterparts.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1332
We were setting the pipeline colour to all white (1.0, 1.0, 1.0, 1.0)
and so the default layer combine function multiplied each pixel
(R, G, B, A) by all ones. Obviously multiplying by one four times per
pixel is a waste of effort so we remove the colour setting *and* set
the layer combine function to a trivial shader that will ignore whatever
the current pipeline colour is set to. So now we do **zero** multiplies
per pixel.
On an i7-7700 at UHD 3840x2160 this results in 5% faster render times
and 10% lower power usage (says intel_gpu_top). The benefit is probably
much higher for virtual machines though, as they're no longer being
asked to do CPU-based math on every pixel of a window.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1331
The previous commit removed checks for intermediate focus states which
would make tests randomly fail, because of their time dependence. What
can be tested however is that if there is no other window available that
would accept the focus, that the focus remains at 'none', after the
focused window has been closed. This newly introduced test checks the
focus directly after closing the window (and syncing) and after the time
it would have taken for the queue to finish. The first check has a
similar timing issue as the removed focus checks in the other tests, but
the test will never accidentally fail, because regardless of whether the
queue has finished or not, the focus is always expected to be 'none'.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1329
While c3d13203 ensured that the test-client has actually closed the
window before testing for the focus change, it also made another timing
related issue with the tests more likely to happen. Serveral tests
assert that the focus is set to 'none' after the focussed window has
been closed when the window below does not accept focus. This however
can never be reliably tested, because closing the window triggers
timeout based iteration of a queue of default focus candidate windows.
This starts after the window has been closed and might finish before the
clients have finished synchronizing. This issue is more likely to
trigger the shorter the queue is and the more test clients there are
that could delay the synchronization.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1329
This avoids some issues which could happen on some setups[0] due to
meta-native-renderer.c:dummy_power_save_page_flip →
meta_onscreen_native_swap_drm_fb implicitly turning of the primary
plane (by destroying the KMS framebuffer assigned to it):
* drmModeObjectSetProperty could return an "Invalid argument" error
between setting a non-empty cursor with drmModeSetCursor(2) and
enabling the primary plane again:
Failed to DPMS: Failed to set connector 69 property 2: Invalid argument
(This was harmless other than the error message, as we always re-set
a mode on the CRTC after setting the DPMS property to on, which
enables the primary plane and implicitly sets the DRM property to on)
* drmModeSetCursor(2) could return an "Invalid argument" error between
setting the DPMS property to on and enabling the primary plane again:
Failed to set hardware cursor (drmModeSetCursor failed: Invalid argument), using OpenGL from now on
[0] E.g. with the amdgpu DC display code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1240
In commit 4c1fde9d MetaCullable related code was moved out of
MetaShapedTexture into MetaSurfaceActor. While generally desirable,
this removed drawing optimizations in MetaShapedTexture for partial
redraws. The common case for fully obscured actors was still supposed
to work, but it was now discovered that it actually did not.
This commit revert parts of 4c1fde9d: it reintroduces clipping
to MetaShapedTexture but leaves all culling and actor related logic
in MetaSurfaceActor.
Thanks to Daniel van Vugt for uncovering the issue.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/850
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1295https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1326
When trying to find a default focus window, the code iterates through a
queue of candidates with a timeout between each candidate. If the window
the current timeout is waiting for gets destroyed, this process just
stops instead of trying the next window in the queue.
This issue was made more likely to be triggered with the previous change
to the closed-transient-no-input-parents-queued-default-focus-destroyed
test due to the introduction of a wait, which can introduce a
delay between the two destroy commands.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1325
Some tests were not waiting for the test client to actually issue
destroy commands before checking their effect on the window focus.
Similarly when mutter is supposed to change the focus based on a delay
by sending a WM_TAKE_FOCUS to the client, this also could fail without
synchronization with the client before checking the result.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1325
We delegate the answer through CoglDriverVtable::is_hardware_accelerated
since this is properly a property of the renderer, and not something the
cogl core should know about. The answer given for the nop driver is
admittedly arbitrary, yes it's infinitely fast but no there's not any
"hardware" making it so.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
Event delivery with grabbing popups stay essentially the same within
the grabbing client, we still must honor the implicit grab as long as
there is one.
This is however not the case, the popup_grab_focus() function ignores
the button state. The popup_grab_button() function will already indirectly
re-sync the focus surface after the last button is released, so checking
for button state in popup_grab_focus() is sufficient to make the implicit
grab honored with popup grabs involved.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1275https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1270
When a touch sequence was rejected, we'd update the event timestamps of
incoming touch events to help with implementing grabs. This was done by
sending a ClientMessage with a counter, and comparing the counter to
decide whether we're seing a replayed event or not.
This had the unforseen consequence that we would potentially end up
destroying all actors including the stage, since, when mutter receives a
ClientMessage event, it would assume that it's a WM_PROTOCOLS event, and
handle it as such. The problem with this approach is that it would
ignore fact that there might be other ClientMessage types sent to it,
for example the touch synchronization one. What could happen is that the
touch count value would match up with the value of the WM_DELETE_WINDOW
atom, clutter would treat this as WM_PROTOCOLS:WM_DELETE_WINDOW, which
it'd translate to clutter_actor_destroy(stage).
Destroying the stage in such a way is not expected, and caused wierd
crashes in different places depending on what was going on.
This commit make sure we only treat WM_PROTOCOLS client messages as
WM_PROTOCOLS client messages effectively avoiding the issue.
This fixes crashes such as:
#0 meta_window_get_buffer_rect (window=0x0, rect=rect@entry=0x7ffd7fc62e40) at core/window.c:4396
#1 0x00007f1e2634837f in get_top_visible_window_actor (compositor=0x297d700, compositor=0x297d700) at compositor/compositor.c:1059
#2 meta_compositor_sync_stack (compositor=0x297d700, stack=<optimized out>, stack@entry=0x26e3140) at compositor/compositor.c:1176
#3 0x00007f1e263757ac in meta_stack_tracker_sync_stack (tracker=0x297dbc0) at core/stack-tracker.c:871
#4 0x00007f1e26375899 in stack_tracker_sync_stack_later (data=<optimized out>) at core/stack-tracker.c:881
#5 0x00007f1e26376914 in run_repaint_laters (laters_list=0x7f1e2663b7d8 <laters+24>) at core/util.c:809
#6 run_all_repaint_laters (data=<optimized out>) at core/util.c:826
#7 0x00007f1e26b18325 in _clutter_run_repaint_functions (flags=flags@entry=CLUTTER_REPAINT_FLAGS_PRE_PAINT) at clutter-main.c:3448
#8 0x00007f1e26b18fc5 in master_clock_update_stages (master_clock=0x32d6a80, stages=0x4e5a740) at clutter-master-clock-default.c:437
#9 clutter_clock_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at clutter-master-clock-default.c:567
#10 0x00007f1e27e48049 in g_main_dispatch (context=0x225b8d0) at gmain.c:3175
#11 g_main_context_dispatch (context=context@entry=0x225b8d0) at gmain.c:3828
#12 0x00007f1e27e483a8 in g_main_context_iterate (context=0x225b8d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3901
#13 0x00007f1e27e4867a in g_main_loop_run (loop=0x24e29f0) at gmain.c:4097
#14 0x00007f1e2636a3dc in meta_run () at core/main.c:666
#15 0x000000000040219c in main (argc=1, argv=0x7ffd7fc63238) at ../src/main.c:534
and
#0 0x00007f93943c1f25 in raise () at /usr/lib/libc.so.6
#1 0x00007f93943ab897 in abort () at /usr/lib/libc.so.6
#2 0x00007f9393e1e062 in g_assertion_message (domain=<optimized out>, file=<optimized out>, line=<optimized out>, func=0x7f93933e6860 <__func__.116322> "meta_x11_get_stage_window",
#3 0x00007f9393e4ab1d in g_assertion_message_expr ()
#4 0x00007f939338ecd7 in meta_x11_get_stage_window (stage=<optimized out>) at ../mutter/src/backends/x11/meta-stage-x11.c:923
#5 0x00007f939339e599 in meta_backend_x11_cm_translate_device_event (x11=<optimized out>, device_event=0x55bc8bcfd6b0) at ../mutter/src/backends/x11/cm/meta-backend-x11-cm.c:381
#6 0x00007f939339f2e2 in meta_backend_x11_translate_device_event (device_event=0x55bc8bcfd6b0, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:179
#7 0x00007f939339f2e2 in translate_device_event (device_event=0x55bc8bcfd6b0, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:208
#8 0x00007f939339f2e2 in maybe_spoof_event_as_stage_event (input_event=0x55bc8bcfd6b0, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:284
#9 0x00007f939339f2e2 in handle_input_event (event=0x7fff62d60490, x11=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:309
#10 0x00007f939339f2e2 in handle_host_xevent (event=0x7fff62d60490, backend=0x55bc89dd5220) at ../mutter/src/backends/x11/meta-backend-x11.c:413
#11 0x00007f939339f2e2 in x_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at ../mutter/src/backends/x11/meta-backend-x11.c:467
#12 0x00007f9393e6c39e in g_main_dispatch (context=0x55bc89dd03e0) at ../glib/glib/gmain.c:3179
#13 0x00007f9393e6c39e in g_main_context_dispatch (context=context@entry=0x55bc89dd03e0) at ../glib/glib/gmain.c:3844
#14 0x00007f9393e6e1b1 in g_main_context_iterate (context=0x55bc89dd03e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/glib/gmain.c:3917
#15 0x00007f9393e6f0c3 in g_main_loop_run (loop=0x55bc8a042640) at ../glib/glib/gmain.c:4111
#16 0x00007f9393369a0c in meta_run () at ../mutter/src/core/main.c:676
#17 0x000055bc880f2426 in main (argc=<optimized out>, argv=<optimized out>) at ../gnome-shell/src/main.c:552
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/338
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/951https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1317
Make the clutter_input_device_get_actor() API public and remove
clutter_input_device_get_pointer_actor() in favour of the new function.
This allows also getting the "pointer" actor for a given touch sequence,
not only for real pointer input devices like mice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
