When a device is added, libei does not allow adding additional regions
for that particular device, as it is already advertised to the EI
client.
As a result, mutter currently effectively only adds the first region to
a device, but not the others.
This makes input in multi monitor sessions only possible on one monitor,
as the EI client cannot look up the other regions, since they were not
advertised to it.
Fix this situation by not adding and resuming the device, when a shared
device is used.
Instead, for shared devices, always add all regions first, and then
after that, add and resume the device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
Use the previously added API to release acquired mapping ids, when the
corresponding stream is destroyed.
Otherwise, the remote desktop session would maintain a whole bunch of
unused mapping ids, as their corresponding streams are already
destroyed, but maybe not the session.
Such situation would be a remote multimonitor session, where the amount
of used virtual monitors changes multiple times during the session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
The remote desktop session currently provides a mechanism to acquire
mapping ids.
However, when they are not used anymore, they currently cannot be
removed and thus just linger around.
So, add an API to release these acquired ids.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3273>
Avoid passing the MetaSeatImpl, since it may be potentially null at
MetaSeatNative construction time. An example of this triggering issues
are mousekeys, since those work on an emulated pointer device created
indirectly after a keyboard device is added (and the right settings are
enabled) at a time that the MetaSeatImpl is still being created, so the
MetaSeatNative cannot yet have a reference to it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2869
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3278>
These objects already have a pointer to the ClutterSeat that has a
pointer to the MetaSeatImpl in its native implementation. This data
may be considered pretty much immutable (a pointer to the seat is
held, and the native implementation will shut down the implementation
thread within ClutterSeat finalization.
Avoids some awkward code, since the MetaInputDeviceNative needs to
be aware of the Clutter object implementation and the implementation
object.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3278>
vc4's implementation of `drmModeAtomicCommit` seems to require a few
milliseconds advanced notice or else it will miss the frame deadline.
That's too high for our deadline evasion threshold which is measured
in microseconds. Let's stop trying to use deadline timers on vc4 to
avoid this conflict without having to disable atomic KMS.
Suggested-by: Jonas Ådahl <jadahl@gmail.com>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2953
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3279>
When CLUTTER_ENABLE_DEBUG is not defined, then CLUTTER_NOTE is defined
as an empty block of code. As a result of that, jitter_us is in that
situation unused, and a compiler warning about this unused variable
appears.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3275>
It's the 10 bit equivalent to NV12 and uses the same layout as P016, i.e.
16 bit components with the lowest 6 bits set to 0 (padding), allowing us
to use 16 bit "subformats".
Thus adding support is quite trivial as we can reuse the NV12 shader.
The format is widely supported in decoding and display hardware (on Intel
since Kaby Lake), as well as modern codecs (AV1, VP9, HEVC) and has
visible quality advantages over NV12.
Note that the additional colors are lost if composited to a 8 bit RGB
framebuffer. Switching between direct scanout and compositing can thus
cause quality differences. This is no new phenomena, however, as the
same is the case already for e.g. GL clients using 10 bit formats -
including video players.
Also note that P012 and P016 could trivially added as well - it's not
done here as they are uncommen and thus hard to test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
These shaders can be used for similar formats with other component
sizes since the values are represented as floats. So whether the source
value was stored in 8bit, 10bit or 16bit doesn't matter - the driver
will covert it for us.
Thus use a Weston-inspired, more general naming scheme.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
They are needed as "subformats" for higher bit YCbCr formats, such as
P010, and we don't plan to use or expose them otherwise. Thus don't
implement any conversion or packing features.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3244>
Realizing a cursor will assume view related state objects are valid so
they can mark them as dirty. This assumption broke when there were a
scale changed that happened with multiple CRTCs, as we'd create view
object by view object as we realized the texture. Realizing the texture
would trigger a signal that had the handler assuming the validity of all
view objects, but if we only had gotten to the first, the second view
would not be there yet, thus we'd be doing a NULL pointer dereference.
Creating the view objects first, then handling the updating avoids this
problem by making the already done assumption valid on hotplugs.
The test case added tests exactly this series of events, and uses a
virtual monitor as a cheap trick to make the KMS CRTC based view the
first one, and an arbitrary view the second that previously had its view
object initialized too late.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3012
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
The cursor surface is decided by the "current" surface; if that alone
changed (e.g. current surface was destroyed), we didn't update the
cursor, meaning it either got stuck, or got hidden if the client exited
completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3262>
It's hard to tell why turning on HDR mode failed without these log
messages. It could be missing support in the sink (EDID/DisplayID) or
missing support in the driver/display hardware (connector properties) or
just a failure turning it on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3251>
Or else `glXQueryDrawable` will fail per the `GLX_EXT_buffer_age` spec:
> If querying GLX_BACK_BUFFER_AGE_EXT and <draw> is not bound to
> the calling thread's current context a GLXBadDrawable error is
> generated.
This mistake went unnoticed until `mtk_x11_error_trap_push` was introduced
(55e3b2e519) because for some reason it is incapable of trapping
`glXQueryDrawable`. Prior to that it seems
`cogl_onscreen_glx_get_buffer_age` would trap and so always returned zero.
This means we're reenabling clipped redraws on X11 here for the first
time in a long time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3255>
Apart from a few edge cases we can avoid walking the tree and transform
to the ancestor coordinate space by multiplying the actor stage-relative
matrix with the inverse of the ancestor's stage-relative matrix.
Since the stage-relative matrices are cached, this reduces the number of
matrix multiplications we do in many situations considerably.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3259>
This used to be the HW device that triggered the crossing (i.e.
the mouse moving the pointer, etc), or the logical device if the
crossing event happened through other means than input device
events, e.g. relayouts.
The move to ClutterEvent constructors went a bit too far in
the simplifications and broke these expectations for input-generated
crossing events.
Make this event constructor behave like the other events: receive
a source device, and figure out the corresponding logical device from
there. Also pass the source device as it'd be expected, in the
input-induced crossing event generation paths.
Fixes: a8c62251f8 ("clutter: Port stage crossing events to new constructors")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2981
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3256>
When the actor gets a new "main" surface assigned, it adds the
new surface to the stack of surface actors, but forgets to remove
the old one.
This stale pointer in the array may cause invalid reads and crashes
after the assigned surface is disposed, e.g. when destroying the
MetaWindowActor tries to disconnect signals from all accounted
surface actors.
Fixes: 9a2c8b2592 ("window: Add suspend state")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3252>
Commit 3bfcb6d1 fixed the check for tiling via keybindings, but
ignored a subtle edge case when tiling with the pointer: The
monitor used for tiling is the monitor with the pointer, which
is not necessarily the one that contains the largest part of the
window.
That is, the correct monitor to check against depends on the
context where the function is called. We can either figure
it out automatically via the current window drag, or make it
a parameter.
The latter is clearer, because the callers already decide which
monitor to use for tiling anyway.
Fixes: 3bfcb6d1b9 ("window: Fix portrait orientation check for tiling")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3248>
These snippets are retrieved anew every time a window is resized. But
callers never modify them, they're effectively read-only so cache them
at the place of creation.
This is required to convince the pipeline hash that each reuse of the
same snippet really is the same snippet and so the pipeline is unchanged.
`CoglPipelineSnippetList` only does shallow comparisons and there's no
need right now to reimplement it as a deep comparison.
This eliminates the log message:
> Over 50 separate %s have been generated which is very unusual,
> so something is probably wrong!
which isn't actually a leak but more a warning about wasting time.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6958
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3224>
GInitable initialization is failable, currently, it may fail before error
traps are initialized, but error traps would be invariably deinitialized on
finalize() of the failed object. This results in an assert hit, on top of the
original failure to initialize the backend.
The libX11 error handlers are a pure client-side construct, and not a server
request, they just need XInitThreads() called to set up the library-side locks
protecting access to the global variable. This is done beforehand already at
meta_backend_x11_init(), so initialize the error traps around that time too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3242>
Commit 9c3b130f67 changed slightly destruction order to handle use-after-free
situations, but missed a small new one introduced by the order change: The
MetaX11Display may schedule callbacks through MetaLaters, which depend on the
MetaCompositor, which is now freed before the MetaX11Display.
Since there is no winning move here, make the MetaX11Display aware of this
by avoiding to remove the callback if the MetaCompositor is already gone.
The MetaLaters infrastructure is already fully freed at this point (incl. the
data it contained), so this shouldn't be a leak.
Fixes: 9c3b130f67 ("display: Fix destruction order")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3247>
Use work area from the monitor that the window is currently on to
determine if tiling should be allowed.
Window tiling is disabled for monitors with portrait orientation, but
the work area we use to detect portrait orientation is taken from the
monitor that currently has the mouse pointer.
This works fine for edge tiling using the mouse, but this is broken when
using keybindings for window tiling because your mouse pointer could be
on a different monitor that has horizontal orientation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3199>
While adjusting the monitor layout of my docked laptop, mutter got a
segfault while attempting to dereference the frame_info struct. This
happened on gnome-shell 44.4-1.fc38.
cogl_onscreen_peek_head_frame_info() just forwards the call to
g_queue_peek_head() which returns NULL in the event that the queue is
empty. If finish_frame_result_feedback() is expected to always be called
with a non-empty queue there's still a bug somewhere, but regardless
this API can legitimately return NULL so it should be checked for prior
to dereferencing.
Fixes: 61801a713a ("onscreen/native: Avoid freezing the frame clock on failed cursor commits")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3229>
If we are making an update that only disables CRTCs, we would not
actually post it, but just drop it then post nothing, as it wasn't ever
added to the mode set update hash table. This resulted in hotplugs where
we loose the all the connectors we had, where we want to disable all
CRTCs and enable nothing, to fail to disable said CRTCs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3073>
This removes the implicit dependency on `display->stack_tracker`
existing and being valid in `on_stack_changed()` because
now it is the stack-tracker's responsibility to subscribe
to the "changed" signal of the stack and handle the changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3202>
The _NET_WM protocol, written before the birth of XInput 2.x, does have
no notion of different input devices whatsoever. Anyways, in a X11 session
it is safe to assume this refers about the Virtual Core Pointer since
every input device by default drives it (incl. touchscreens through the
"pointer emulating sequence", and styli).
This assumption falls apart in a Wayland session with non-pointer input,
since we do actually distinguish between all the distinct pointer devices
and touchpoints, and do not let them emulate mouse input.
We do need to specify a device/sequence there to drive the window
move/resize operation. The _NET_WM_MOVERESIZE message just gives us the
x/y root coordinates the resize was started from, so work from there
into guessing what is the most likely device/sequence that did trigger
the request on the client side.
Conversely, on Wayland we do not need to check for possible race
conditions in the pressed button states since we have larger guarantees
about not missing these events if we checked for the button modifier
mask beforehand, so make that race condition check specific to the
X11 sessions.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2836
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3059>
The stage has the knowledge about input that is ongoing over it
(incl. things like styli and touchpoints). Add an iterator API
for these devices/touchpoints, so they can be used for calculations
and heuristics in other places of the code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3059>
There can be events which don't not have source devices set on them, because
they are not backed by real hardware and rather generated by us, for example
IM events coming from the shell's OSK.
So don't assume all events have a source device in
update_pointer_visibility_from_event() and rather ignore those without one,
as we are only interested in events coming from "real hardware" here.
This fixes an issue where the mouse pointer would appear on devices without
any input from actual mice/touchpads on OSK key presses.
Fixes: 6aa42d6dad
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3236>
So far, we expected all events to have input devices set on them, IM events
lost theirs with commit 6aa42d6dad. This somewhat made sense, because IM
events are not backed by any actual device, they are generated by us in
response to eg. an OSK key press.
To fullfil the assumption that all devices at least have a logical input
device set, pass the seat to the clutter_event_im_new() constructor and then
set the device to the logical keyboard device. The source_device we leave
empty, since there is no actual physical device that this event came from.
Fixes: 6aa42d6dad
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3236>
The assertion for !implicit_grab_cancelled in the
`grab_actor == old_grab_actor` case of
clutter_stage_notify_grab_on_pointer_entry() is meant to do a simple
sanity-check to ensure the grab machinery is working as intended: During a
seat grab, all input gets delivered to the tree inside the grab, and all
implicit grabs outside of that tree are cancelled.
When a new seat grab on the same actor as the existing one happens, we run
through the cancellation machinery for implicit grabs anyway, so we might as
well check that the assumption mentioned above holds true: By asserting that
no implicit grabs were cancelled, we know that no implicit grabs exist
outside of the existing seat grab tree.
This assertion is slightly over-eager though due to the way we set
implicit_grab_cancelled: We initialize it to TRUE in the
entry->press_count > 0 case and then only set it to FALSE once we find an
implicit grab that may remain active. If there are no implicit grabs though
(while entry->press_count is still >0), we never set implicit_grab_cancelled
to FALSE, triggering the assertion in question even though no implicit grabs
got cancelled.
There's two possible solutions for this: Either dropping the assertion, or
refactoring it so it observes the situation where the implicit grabs were
already undone. This commit implements the latter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2700
Fixes: debbd88f8c ("clutter/stage: Cancel parts of implicit grabs when ClutterGrabs happen")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3216>
When we call get_grab_info() to get the sequence, device and coordinates for
a touch window drag, as the device we use the device from the
MetaWaylandPointer, assuming that it's set to the core pointer.
In the case where there is no pointer device present on the seat (so no
mouse nor touchpad), the wayland pointer remains disabled though, and
pointer->device is NULL.
This means touch window dragging on hardware without pointer devices
present is broken (because MetaWindowDrag assumes that there's a valid
device passed in meta_window_drag_begin()). Fix it by taking the core
pointer directly from ClutterSeat instead of going the extra detour through
MetaWaylandPointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3238>
If meta_eis_viewport_get_position() returned FALSE, the variable
'has_position' would be initialized. This variable represents
exactly the return value of meta_eis_viewport_get_position(),
so just assign it to the variable directly.
Spotted by Coverity.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3237>
CLUTTER_SCROLL_SOURCE_UNKNOWN only generates continuous scroll events
and no discrete scroll events.
As a result, scrolling only works in applications, that support high
resolution scroll wheels, like GTK4 applications.
GTK3 applications, on the other hand, don't support high resolution
scroll wheel events, and such scrolling does not work in these
applications.
Fix this issue by using the scroll source CLUTTER_SCROLL_SOURCE_WHEEL.
Since commit 92a90774a4 ([0]),
CLUTTER_SCROLL_SOURCE_WHEEL generates discrete events to ensure that
scrolling in legacy applications still works.
[0]: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2664
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3235>
We need to trigger a mode set when power-save changes to 'on' if it's
purely about power saving, but when they arrive as part of a hotplug
event, we'll handle all that later, in the monitors-changed handling,
that contains the new configuration.
This avoids a crash that happens due to the mode set being queued on now
disabled connectors.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2985
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3233>
We can change power save mode for two reasons: gsd-power told us to, or
we saw a hotplug event. Sometimes it's useful to be able to make the
distinction to why a power save mode changed, so add a reason to the
signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3233>
If the deadline timer is disabled (like on nvidia-drm or when
`MUTTER_DEBUG_KMS_THREAD_TYPE=user`), then we need to call
`meta_kms_device_set_needs_flush` on every cursor movement. But some were
getting skipped if they coincided with page flips, which resulted in some
cursor movements failing to schedule the frame clock. This resulted in
unnecessary levels of frame skips when using lower frequency input devices
which are less likely to provide another event within the same frame period.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3002
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3210>
Add a pair of calls to ensure the error trap infrastructure
survives for the MetaBackend. This will help on later commits that
largely operate on the MetaBackendX11 Display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230>
Keep a per-display list of error traps, so we don't mix them
together, and possibly deem unintended error traps outdated.
This means init/deinit calls are now stackable, and need to
happen evenly. In order to honor this, move the MetaX11Display
error trap destrution to finalize.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230>
We currently have a bit of a disaster area wrt X11 error handling,
with all of Cogl/Clutter/Mutter offering implementations with different
expectations and different degrees of integration with other error
handlers.
It makes more sense to have a single X11 error handling implementation
that is used in all those places. Mtk seems like the reasonable place
to have this kind of general API, so adopt the more advanced code
at src/x11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3230>
This forces not using the seat_proxy. But still allows the use of
session_proxy.
On tests, headless mode is explicitly set and it might not be available a
systemd session. To avoid test failing on this situation skip using
meta_launcher wich uses session_proxy and seat_proxy.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3093>
If we're a input-only remote desktop session, create libei regions on an
absolute pointer device corresponding to all logical monitors. This
allows absolute pointer motions without screen casting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
Sometimes it makes no sense to have a shared pointer device, for example
when they have no set region occupying the global stage coordinate
space. This applies to for example window screen cast based pointer
device regions - they are always local to the window, and have no
position.
We do need shared absolute devices in some cases though, primarily
multi-head remote desktop, where it must be possible to keep a button
reliably pressed when crossing monitors that have their own
corresponding regions.
To handle this, outsource all this policy to the one who drives the
emulated input devices. Remote desktop sessions where the screen casts
correspond to specific monitors (physical or virtual), we need to make
sure they map to the stage coordinate space, while for window screencast
or area screencasts, we create standalone absolute pointer devices with
a single region each.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
We already have the remote desktop session ID, and we'll soon need the
actual remote desktop session in the screen cast session, so pass it on
construction.
The old screen cast type is set implicitly instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
A MetaEisViewport represents an absolute region backend by e.g. a
pointer device. There are two kinds: a standalone viewport, which
corresponds to a viewport that has no neighbours, and a non-standalone,
which represents a region of a global coordinate space.
The reason for having non-standalone viewports is to allow to mirror the
logical monitor layout of a desktop, while the standalone are meant to
represent things that are not part of the logical monitor layout.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
How EIS will be used depends on its context, meaning we'll have multiple
EIS contexts that expose different things. To prepare for this remove
the global socket since that won't work with multiple contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3228>
This fixes a compiler warning:
```
src/x11/events.c:523:1: warning: ‘get_event_name’ defined but not used [-Wunused-function]
523 | get_event_name (MetaX11Display *x11_display,
| ^~~~~~~~~~~~~~
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3223>
This used to be the behavior, until commit 5d35138df0 changed the meaning
of the return value of MetaCursorRendererClass::update_cursor(). This
made the user of pure-overlay cursors (singular, MetaWaylandTabletTool)
miss their overlays.
Change the return value, so that it matches the desired behavior of
a backend-less overlay-only cursor renderer.
Fixes: 5d35138df0 ("cursor-renderer: Make 'handled_by_backend' state 'needs_overlay'")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3218>
We react on changes to has_hw_cursor, but always try to inhibit if
there is no cursor sprite. While this looks like a reasonable optimization
with the typical situation of one cursor renderer, it may fall into
inhibiting twice without knowing to unwind, e.g.:
1. has_hw_cursor: TRUE, cursor_sprite: !=NULL -> inhibit
2. has_hw_cursor: FALSE, cursor_sprite: NULL -> inhibit
3. has_hw_cursor: TRUE, cursor_sprite: !=NULL -> uninhibit, but once
And this may also result in the CLUTTER_PAINT_FLAG_NO_CURSORS flag
staying on for Tablet cursors, that (so far) always use overlay paths.
This results in invisible tablet cursors after using the mouse at
least once.
Fixes: e52641c4b6 ("cursor-renderer/native: Replace HW cursor with KMS cursor manager")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3218>
Under strange timings, the GTK frames client may implicitly queue
relayouts that end up disagreeing with the latest frame size as
given by Mutter, this results in GTK calling XResizeWindow, and
Mutter plain out ignoring the resulting XConfigureRequestEvent
received.
This however makes GTK think there's pending resize operations,
so at the next resize it will freeze the window, until enough
resizes happened to thaw it again. This is seen as temporary
loss of frame-sync ness (e.g. frozen frame, and other weird
behavior).
In order to make GTK happy and balanced, reply to this
XConfigureRequest, even if just to ignore it in a more polite
way (we simply re-apply the size Mutter thinks the frame should
have, not GTK), this results in the right amount of
ConfigureNotify received on the frames client side, and the
surface to be thawed more timely, while enforcing the size as
managed by Mutter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2837
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3189>
This is meant for compatibility purposes with the shell extensions
avoiding to break a bunch of them in the last minute and we would
drop it in the GNOME 46 release.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
Currently, Meta/Cogl/Clutter makes use of cairo_rectangle_int_t despite
the existance of MetaRectangle.
In order to make MetaRectangle usable in Cogl/Clutter as well, Mtk would
provide such base types that are shared across the various private
libraries
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3128>
This used to be the case before the refactor at commit 43cee4b6b6,
use_clipped_redraw would be unset before the larger check if has_buffer_age
was set, but clutter_damage_history_is_age_valid() was FALSE. This got
replaced by a check just on the latter, which will also be FALSE if
has_buffer_age is not present.
We have other means to achieve clipped redraws, so this slight change
culled all of them.
Fixes: 43cee4b6b6 ("stage-impl: Do clipped redraws when drawing offscreen")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2771
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3221>
This is at best pointless, since the relayout will change pointer
picking conditions, and buggy at worst, since the actor being
relayout is not at an state that it can be asked during picking.
This specifically fixes warnings like:
Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesDisplay>:0x5601dd557050] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspacesView_WorkspacesView>:0x5601edcf6aa0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_Workspace>:0x5601ee163dc0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_WorkspaceBackground>:0x5601ee1c85b0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<ClutterActor>:0x5601ee4db280] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_windowPreview_WindowPreview>:0x5601ee1840c0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_Workspace>:0x5601ebe1d1b0] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<Gjs_ui_workspace_WorkspaceBackground>:0x5601edbd3420] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<ClutterActor>:0x5601ee3cd630] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<StLabel>:0x5601ee685730] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<ClutterText>:0x5601ed5b5f20] is on because it needs an allocation.
When trying to dismiss the overview with a 3fg touchpad gesture
while the pointer is over a window clone.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6935
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3220>
This changes how state is tracked by introducing an explicit state. We
need this since we use asynchronous calls to the out of process
component that handles actual inhibitation, including idleness.
This means if inhibitations changes rapidly, we might end up with an
incorrect state if we e.g. try to uninhibit while we're currently trying
to inhibit.
This is done by adding a state variable that accounts for the pending
state, as well as the active state, with a function that looks at the
current conditions to derive what state we should be in, and what state
we are in, to decide what the next action should be.
For example, if we're trying to inhibit, but now wants to uninhibit,
we'll wait for the inhibit call to complete, recheck what we want, which
would result in an async uninhibit call being made.
Fixes: 388b534062 ("wayland: Implement idle inhibit protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3219>
This fixes the following
1. Minimize window; minimize animation starts
2. Do something that immediately destroys the animated actor (e.g. terminate)
3. This triggered the timeline of the animation to emit a "stopped"
signal while all transitions of the actor were destroyed
Previously we'd implicitly animate the scale again (set_scale(..)) which
created a new transition The hash table iterator didn't like this and
abort():ed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3213>
The 'suspend state' is meant to track whether a window is likely to be
visible any time soon. The hueristics for this are as follows:
* If a window is hidden, it will enter the 'hidden' state.
* If a window is visible, and unobscured, it will enter the 'active'
state.
* If a window is visible, but obscured by another window, it will enter
the 'hidden' state.
* If there is a mapped clone of a window, it will enter the 'active'
state.
* If the window has been in the 'hidden' state for 3 seconds, it will
enter the 'suspended' state.
This will eventually be communicated to Wayland clients so that they can
change their behaviour to e.g. save power.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
This are called when a clone directly attaches to an actor. While not
reliable to know whether a particular actor is cloned or not, one can at
least this way get notified about whether an actor in particular is
cloned.
This can be useful for e.g. the MetaWindowActor, as it's what's most
likely cloned, e.g. for alt-tab views etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
Adds va_marshallers to the ClutterStage signals. This allows for better
stack traces to be retrieved when profiling. Additionally, since the
generic marshaller was using GBoxedCopy/GBoxedFree functions for the
GValue usage, the previous code was acquiring a global reader/writer
lock in GObject via g_boxed_free() usage.
With G_SIGNAL_TYPE_STATIC_SCOPE, the generated marshallers can avoid
the additional copy/free on the instance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3204>
Previously it transformed a physical CRTC coordinate to a logical desktop
coordinate. But current and future users of the function all require
conversion from logical coordinates to physical coordinates. We would have
had to always invert the transform parameter which is a waste of time when
we can instead just invert the function behaviour.
We also simplify the parameters to show both the point coordinate and the
area dimensions are potentially transformed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3180>
Same reasoning holds than with touchpad gesture events in the
previous commit, this will be the first event seen from a specific
device and will require early handling, or crashes may follow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3198>
With commit be3bca01a7 in place, we now possibly skip early calls
to clutter_stage_repick_device() happening early during initialization.
These were also indirectly the ones that eventually ended up in
the first call to clutter_stage_pick_and_update_device() actually
initializing the PointerDeviceEntry.
With this no longer happening, we may end up with no PointerDeviceEntry
implicitly set up after initialization, which may fail if the first
event received from the seat pointer does not in fact trigger the
clutter_stage_pick_and_update_device() call necessary to make things
work from there on.
And this does indeed happen on touchpads, since the first input event
obtained after CLUTTER_DEVICE_ADDED is CLUTTER_TOUCHPAD_* instead
of CLUTTER_MOTION. This finds an unset PointerDeviceEntry and crashes
since the pointer device does still have no "presence" on the stage.
Fix this by making CLUTTER_TOUCHPAD_* events also trigger a
device update, so the fist event handled does always trigger the
necessary device update.
Fixes: be3bca01a7 ("clutter: Check that pointer has coordinates prior to repick")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2978
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3198>
This data is commonplace enough that it makes sense to keep it
as generic event data. Make these fields take a hard refcount, like
the private data used to do, and drop these fields from the
ClutterEventPrivate struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3190>
When creating a new stream, check if the preferred format is
different from the default (COGL_PIXEL_FORMAT_BGRX_8888). If
it is, then also include it in the list of potential formats
for the stream.
COGL_PIXEL_FORMAT_BGRX_8888 is still passed around as it's
both the default, and the fallback for when things go wrong.
When creating buffers, use the negotiated SPA format instead
of a hardcoded value. We leave it to PipeWire to figure out
what's the best format, since clients may not support the
preferred format of the stream.
Due to how chaotic things got, this commit also cleans up
the create_pipewire_stream() to use an auxiliary array of
SPA formats, which is then iterated on in order to generate
the format pods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
Freeing the window opaque region rather than the frame one when was
leaking the frame opaque region and wrongly setting the window opaque
region to NULL.
Fixes: 82b2b7688 ("core: Add infrastructure to keep window frames' opaque regions")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3188>
This is something the compositor could now track by itself, instead of
being pushed through events. It also makes more sense to do this directly
when the grabbing conditions change, as opposed to the next event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
Except for the tests that launches `mutter`, use a custom shell
implementation. It's roughly a copy of default.c with some cleanups on
top. A custom shell allows for a bit more freedom when doing testy
things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3185>
The device/sequence may not currently have a set of coordinates to return.
We correctly leave the out values uninitialized, but don't tell the upper
layers in any way.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3183>
F39 has been branched, so we can use it as base of our CI image
and reduce the number of custom built components.
This will also help if gjs adds support for import maps and
gnome-shell bumps its gjs dependency to use it, as F39
already includes the new mozjs version that gjs now uses.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3173>
Meson stopped using polkit for automatic priviledge elevation, and
will no longer attempt any priviledge elevation when not running
interactively.
Running the entire install command as root used to be problematic
in the past, as it could result in ownership changes of files in
the build directory that would result in build failures later,
but the aforementioned change leaves us with little choice.
Presumably those issues have been fixed, let's hope that's true.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3173>
This splits culling into two different phases to move unobscured region
culling to pre-paint to fix#2680. This is needed as direct scanout
skips the paint phase altogether, but the pre-paint phase always runs as
it's used for selecting the direct scanout surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3127>
We have a mechanism to trigger repick after animations on
clutter_actor_set_final_state(), but this will not happen if
animations are disabled.
In this case, shell transitions and other typically animatable
changes on the transform of actors will not naturally trigger
a pointer repick when those get instantly changed to the final
state, possibly preserving the cached state and missing the
just popped in actor altogether.
Trigger an instant repick on animation-less transform changes,
so that these situations are also handled correctly, and the
pointer drops the cached state and is able to find the new
actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3168>
The clutter_seat_handle_event_post() function wants to handle
CLUTTER_DEVICE_ADDED/REMOVED to perform signal emission, but
checks (and asserts) that every event going through it has a
source device.
This is no longer quite true for IM events (they are attached
to the ClutterSeat's keyboard, not a HW device), so the assert
can now fire off (of course undesiredly).
But anyways, for events built through
clutter_event_device_notification_new() (the ones this function
is interested in, after all), it is already a precondition check
that the device is proper at the time of creating the event, so
asserting for it here is redundant.
We can drop this overly generic assert, this is already ensured
for the events that matter, anyways.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3167>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
In test situations we sometimes do not create a libinput context, so
our check on dispose to see if we need closing the input thread is off
if META_SEAT_NATIVE_FLAG_NO_LIBINPUT was provided.
Check the input thread existing instead, since that is the thing we
want to undo here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Same reasoning than gnome-shell@dbc9ebc6abc8 applies, it may be
useful to run a pipeline with matching branches in the other
project, without necessarily opening a merge request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
All ClutterEvent users have been changed to use getter methods
instead of direct field access. We may now make the ClutterEvent
union/structs entirely opaque by moving the definitions out of
public headers.
All future usage of ClutterEvent data should be done through
getter methods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Move the string construction bits in the event logging happening in
MetaSeatImpl to a clutter_event_describe() call, so that it has more
freedom in fiddling with ClutterEvent internals, and may be potentially
reused in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Add methods, and change the API of some rarely used methods, in order
to make all event info currently held/necessary accessible through
ClutterEvent getters, instead of direct field access.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
The full decomposed modifier state is pretty much unused, relying
in keymap signals/properties to track latched modifiers state instead.
The events can be simplified without having this information, and if
it were ever needed in the future, it would be nicer that it had a
dedicated struct and didn't increase the number of arguments in
ClutterEvent constructors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Since the full decomposed modifier state is unused, and only the
effective modifier mask matters to users, the new constructors take
just this effective modifier mask. This means this helper went
unused in the port to the new constructors, so can be now dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Since the full decomposed modifier state is unused, and only the
effective modifier mask matters to users, the new constructors take
just this effective modifier mask. This means this helper went
unused in the port to the new constructors, so can be now dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
We need to change at least event flags in the event we reinject after
it was let through by the IM, in order to avoid doubly handling.
Create a full event copy from the original event parameters.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Avoid peeking in the stage for loosely related actors, since the same
event could be handled by different actors across the picking stack.
This getter is also unused, so there's wiggle room here for changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
These constructors take all the necessary arguments to build the
event from the get go, so the callers are not left up with the task
of setting up the event struct data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
This is done from the backend X11 connection, but needs directing at times
from the frontend X11 connection. Commit 5a8509f895 added a XEvent
argument presumably for possible future expansions that did never come.
Since this function is nothing about events, drop the XEvent argument and
make the name a little bit more ad-hoc (according to what it does, at
least).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Despite the attempt to make this a generic interface, this was
pretty much used only by the X11 backend, and now it ported away
from it.
This now stands unused and may be removed, in favor of backends
each creating and injecting events as they please.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
This is about the only reason now to go through the ClutterBackend
translate_event vmethod. We can do that directly, and stop requiring the
generic vmethod that is actually just used for X11 events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
There's no need for an XEvent filter, since this is already code close enough
to MetaBackendX11 XEvent handling and always required anyways. Make the a11y
configuration checks happen directly from MetaBackendX11 event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
We are pretty much guaranteed that the first event will be handled after
the cogl renderer has been set up. We can avoid the loop through
ClutterBackend vmethods and X11 event filters, and call this directly
from the code that is already close to the MetaClutterBackendX11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
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>
It is a bit backwards that events contain information about
the stage they are being handled by. It makes more sense to
specify in the ClutterEvent handling entrypoint the stage
that will handle the event.
As a first step, add this ClutterStage argument, even though
the information is still carried through the event in order to
keep satisfying calls to the getter function.
This entrypoint has been also renamed to clutter_stage_handle_event(),
so that its ownership/namespace is clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Nowadays, all our MapNotify event handling happens already prior to
the MetaCompositorX11 handling of XEvents. It does not make sense to
channel these events again through the backend, at best all it could
lead to is double handling of the same events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Because `meson dist` will fail in that case:
```
Dist currently only works with Git or Mercurial repos
```
Being away from the git repo would only happen on non-marge CI runs of
'deploy' and only if the MR contains meson changes. So the bug went
unnoticed when introduced in !3083 because it didn't contain meson changes.
To fix it we just revert one line of !3083.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2908
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3126>
These "features" are somewhat less featured, it's becoming too ugly
to handle all of them with a single API call. The clear outlier are
buttons, so move them to a separate function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3005>
queue_update() in a previous iteration was called in two situations:
* A page flip was already pending, meaning if we would commit an
update, it'd fail with EBUSY.
* A update was marked as "always-defer" meaning it should only be
processed from the deadline callback (would there be one). These were
used for cursor-only updates.
In the latter, we had to arm the deadline timer when queuing a new
update, if it wasn't armed already, while in the former, we would
currently idle, waiting for the page flip callback. At that callback
would the deadline timer be re-armed again.
Since we're only handling the former now, we'll never need to arm the
timer again, so remove code doing so. The code removed were never
actually executed anymore, after the "always-defer" flag on updates was
removed.
Fixes: 27ed069766 ("kms/impl-device: Add deadline based KMS commit scheduling")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3150>
Primary plane updates were forgetting to do this in OnscreenNative, but
rather than do it for each post there we should simply do it for each
post.
This fixes cursor stutter in the fallback path (not using deadline timers)
where needs_flush_crtcs would remain populated but CRTC_NEEDS_FLUSH would
never be emitted, because handle_flush hadn't been called for the last
post.
This is safe as the current use of scheduled flushing is only for cursor
updates, and since cursor updates happen on the same thread as processing,
and due to the fact that we always use the most up to date cursor position
when flushing, we never risk leaving an old cursor state unflushed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3138>
Implement importing of multi-plane formats. For now, only support
importing planes individually using "sub-formats". This is the most
commonly driver-supported approach in the moment, used by other
Wayland compositors as well.
In the future we will additionally want to support importing the formats
directly and let the drivers handle conversion internally.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
So they can be derived from the DRM format as well.
While updating the users, ensure we don't announce support for
DRM formats in zwp_linux_dmabuf_v1 if the MetaMultiTextureFormat is
INVALID. This will be used for YUV subformats in following commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
In future commits, we want to be able to handle more complex textures,
such as video frames which are encoded in a YUV-pixel format and have
multiple planes (which each map to a separate texture).
To accomplish this, we introduce a new object `MetaMultiTexture`: this
object can deal with more complex formats by handling multiple
`CoglTexture`s.
It supports shaders for pixel format conversion from YUV to RGBA, as
well as blending. While custom bleding is currently only required for
YUV formats, we also implement it for RGB ones. This allows us to
simplify code in other places and will be needed in the future once
we want to support blending between different color spaces.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
When we see a mode set, the cursor manager will update all the cursor
planes so they are set correctly as part of the mode set. KMS updates
are always per-device, and what was wrong was that it didn't filter out
CRTCs on devices that wasn't part of the mode set.
Reported-by: Michel Dänzer <mdaenzer@redhat.com>
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3130>
It turns out that gnome-shell's toolbox image is still broken
after commit 86b77f65e7.
Toolbox' entry point ensures that the calling user exists inside
the container, and makes their home available inside the container.
There are two ways the `useradd` command in our image may interfere
with that:
- by default, useradd uses the smallest available UID in the
normal user range (usually 1000); this is highly likely to
clash with the host user UID
- if the host's /home is a symlink (for instance to /var/home
on Silverblue), then toolbox recreates that layout inside the
container; it cannot do that if /home is already a non-empty
directory
Luckily we can address both issues without affecting the ability
to build and run tests as user: We can simply create the `meta-user`
with a UID and home directory that are unlikely to clash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3134>
Measurements above 100% were originally allowed to show when frame skipping
was occurring so you didn't have to also check the frame rate. But that
also resulted in arbitrarily high jitter values being reported when
returning from idle. And those are frequent enough to look like a bug or
untrustworthy so let's not do that anymore.
Taking the remainder of a high jitter value is still a meaningful jitter
value.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2906
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3123>
clutter_frame_clock_compute_max_render_time_us clamps to the refresh
interval anyway, so the only effect a higher recorded maximum can have
is to delay it falling below the refresh interval again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3090>
Instead of separate pairs of short- and long-term maxima for each
measured step of the frame update process.
This should result in the render time estimate rising less often:
Previously it did whenever the measurement of any of at least 3 out of
4 steps reached a new maximum, even if that didn't result in a new
maximum for the whole update duration. Now it's only in the latter
case.
This should also result in a lower render time estimate (and thus
input→output latency) in general, since the variability of
measurements for each 3/4 steps doesn't always add up anymore. The flip
side of this is that it might result in missing a display refresh cycle
more often.
v2:
* Fix coding style in maybe_update_longterm_max_duration_us.
(Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3090>
It returns non-0 if there are any hints in the WM_NORMAL_HINTS
property, 0 if there are none.
Fixes the mouse cursor changing to the resize shape over the decorations
of non-resizable windows.
Fixes: c7b3d8c607 ("frames: Push error traps around various X11 calls")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3096>
With libdecor, window moving/resizing only works with
the pointer, not with touch.
The meta_wayland_pointer_can_grab_surface checks for subsurfaces,
but the meta_wayland_touch_find_grab_sequence does not.
Add a similar subsurface check to
meta_wayland_touch_find_grab_sequence.
Closes: GNOME/mutter#2872
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3125>
Removing duplication, making it easier to add new formats and ensuring
that the native backend and Wayland clients can use the same formats.
Also improve related build files so the Wayland backend can be build
without the native backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
1. Move into the new 'common' folder and build for Wayland as well
so we will be able to share the code in follow-up commits.
2. Rename to cogl-drm-formats to make it more obvious that the format
map is more than an utility these days.
3. Drop the unused CoglTextureComponents part (see also previous
commit).
4. Move the map to the header, simplifying some future use-cases.
5. Sync formats with MetaWaylandBuffer and MetaWaylandDmaBufBuffer and
also use newly introduced opaque formats where appropriate.
This avoids duplicated code, ensures that new drm-formats added to
the dmabuf protocol have an adequate representation in Cogl from which
information like alpha support can be easily derived and finally
ensures we don't crash if the mappings got out of sync.
6. Remove some likely untested formats. In case some of these are
actually needed on certain hardware, we can test whether we got
the correct mapping by also adding support for the corresponding
wl_shm_format in MetaWaylandBuffer by extending the gradient test in
https://gitlab.freedesktop.org/jadahl/wayland-test-clients
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
The default cogl blend string is
`RGBA = ADD (SRC_COLOR, DST_COLOR*(1-SRC_COLOR[A]))` which is alpha
blending with premult fragment results. We do not clear the src
framebuffer and even if we did set alpha to 1 in the src fb, the
resulting alpha would be 1 and we want to check the alpha of the
fragment color.
Just turn off any kind of blending instead and write out the fragment
color to the fb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
To obtain a float between 0 and 1 we have to devide the integer by the
highest possible value instead of the number of values.
Fixes off by one errors in the tests on some hardware/driver
combinations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
So we can properly handle matching DRM and WL_SHM formats in a unified
manner.
Add extensive testing between these and existing pre-multiplied alpha
formats, i.e. all formats we support on Wayland.
Note that unfortunately for some format combinations the value in the
alpha channel is not cleared as expected, likely because of fast-paths
in Cogl. If both source and destination format is opaque, it always
works, however. This thereby includes all cases where they are the same.
Co-Authored-By: Jonas Ådahl <jadahl@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
On GLES2 reading and writing some Cogl formats is not supported
natively. In those cases we use another format to do the reading and
writing. When the internal format and the temporary format differ in
premultiplication, Cogl tries to adjust for it.
Opaque Cogl formats don't have the premult bit set but our internal
format is a premult format. Cogl tries to adjust for it but completely
misses that the opaque format doesn't have an alpha channel and it
should not do so at all.
So skip the premult adjusting when the Cogl format has no alpha channel.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3065>
We can schedule an update from the cursor manager, but that doesn't mean
there will be an actual plane assignment changed at the time of the
update processing, since for example we might have "touched" a CRTC, but
already left it before the processing started, meaning we have nothing
to change after all.
Add a test case that checks that this works properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This removes the old hardware cursor management code and outsources it
to MetaKmsCursorManager. What the native cursor renderer still does,
however, is the preprocessing i.e. rotating/scaling cursor that wouldn't
otherwise be fit for a cursor plane.
The cursor DRM buffers are instead of being per cursor sprite now per
CRTC, meaning we don't need to stop doing hardware cursors if part of
the cursor is on an output that doesn't support it. This is why the
whole scale/transform code changed from being per GPU to per CRTC.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It can be quite slow to set up the test environment inside the VM, as
well as outside, leaving very little time for the test itself. While
it'd be nice to not run the mock env etc outside the VM, let's just bump
the timeout for now, to avoid unnecessary timeout failures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
If we turn of a CRTC, we might have invalidated the cursor manager for
the same CRTC, but that should not mean a cursor plane is assigned when
turning off the CRTC.
Add a test case for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This new manager object intends to take over management of the cursor
plane from the native cursor renderer. It's API is intended to be used
from the main thread, except for the _in_input() function, but mainly
operates in the KMS context, i.e. the KMS thread.
It makes use of an "update filter" that is called before each
MetaKmsUpdate is turned into a atomic KMS commit or a set of legacy
drmMode*() API calls. When the cursor position has been invalidated,
it'll assign the cursor plane in the filter callback, using an as up to
date as possible pointer position as the source for the cursor plane
position.
Cursor updates from the input thread schedules updates for the affected
CRTCs which will cause the filter to be run, potentially for cursor-only
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This adds some plumbing to get the "default" paint flags for regular
stage painting, where one either wants to paint the overlay, or not.
If inhibited, the 'no-cursors' paint flag is used, otherwise the 'none'
flag. This will be used to allow having a per stage view hw cursor
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This makes it possible to post KMS updates that will always defer until
just before the scanout deadline. This is useful to allow queuing cursor
updates where we don't want to post them to KMS immediately, but rather
wait until as late as possible to get lower latency.
We cannot delay primary plane compositions however, and this is due to
how the kernel may prioritize GPU work - not until a pipeline gets
attached to a atomic commit will it in some drivers get bumped to high
priority. This means we still need to post any update that depends on
OpenGL pipelines as soon as possible.
To avoid working on compositing, then getting stomped on the feet by the
deadline scheduler, the deadline timer is disarmed whenever there is a
frame currently being painted. This will still allow new cursor updates
to arrive during composition, but will delay the actual KMS commit until
the primary plane update has been posted.
Still, even for cursor-only we still need higher than default timing
capabilities, thus the deadline scheduler depends on the KMS thread
getting real-time scheduling priority. When the thread isn't realtime
scheduled, the KMS thread instead asks the main thread to "flush" the
commit as part of the regular frame update. A flushing update means one
that isn't set to always defer and has a latching CRTC.
The verbose KMS debug logging makes the processing take too long, making
us more likely to miss the deadline. Avoid this by increasing the
evasion length when debug logging is enabled. Not the best, but better
than changing the behavior completely.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This is helpful when we add callbacks that should be dispatched in the
KMS impl thread.
This invalidates an assumption about callbacks not being in the impl
context, so some asserts for that are also removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This signal is emitted before terminating the thread, but also when
resetting the thread type. This is to allow thread implementations to
make sure they have no stale pending callbacks to any old main contexts.
This commit "terminates" the impl thread even if there is no actual
thread; this is to trigger the "reset" signal, also when switching from
a user thread to a kernel thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means we can add COGL_TRACE*() instrumentation that is grouped
correctly in sysprof. If kernel threading is enabled, they will end up
in a "Compositor (KMS thread)" group (ignoring translations).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Real time scheduling is needed for better control of when we commit
updates to the kernel, so add a property to MetaThread that, if the
thread implementation uses a kernel thread and not a user thread, RTKit
is asked to make the thread real time scheduled using the maximum
priority allowed.
Currently RTKit doesn't support the GetAll() D-Bus properties method, so
some fall back code is added, as GDBusProxy depends on GetAll() working
to make the cached properties up to date. Once
https://github.com/heftig/rtkit/pull/30 lands and becomes widely
available in distributions, the work around can be dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Also add an API to inhibit the kernel thread from being used, and make
MetaRenderDeviceEglStream inhibit the kernel thread from being used if
it's active.
The reason for this is that the MetaRenderDeviceEGlStream is used when
using EGLStreams instead of KMS for page flipping. This means the actual
page flipping happens as a side effect of using EGL/OpenGL, which can't
easily be done off thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This will be necessary in order to default to 'kernel' and then switch
to 'user' if the thread instance can no longer be properly multi
threaded.
To avoid having the same thread impl creating and destroying
GMainContext's, this also means always creating a GMainContext for the
thread-impl. When running in user-thread mode, the GMainContext is
wrapped in a wrapper source and dispatched as part of the real main
thread GMainContext, and when in kernel-thread mode, it runs
independently in the dedicated thread.
This has the consequence that the wrapper source will always have the
priority of the highest impl context GSource, but only after it has
dispatched once. Would we need it earlier than that, we either need a
way to introspect existing sources in a GMainContext and their
priorities, or manually track known sources in MetaThreadImpl.
The wrapper source will never be below 0, as that'd mean it could reach
INT_MAX priority if it had no more sources attached to it, meaning it'd
never be dispatched again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While doing this, rename the old synchronous functions to more clearly
communicate that they expect to actually process the update during the
call, not just post it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While the default when passing NULL will be the main context of the main
thread, make it possible to specify another main context, so that
result handlers can be invoked on the right thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Callbacks could be queued to be invoked either on the impl side or the
main thread side of the thread; change this to take a GMainContext,
which effectively means a callback can be queued to be invoked on any
thread that has a GMainLoop running on its own GMainContext.
Flushing is made to handle flushing callbacks synchronously on all
threads. This works by keeping a hash table of queued callbacks per
thread (GMainContext); when flushing (from the main thread), callbacks
on the main thread context is flushed, followed by synchronization with
all the other threads.
meta_thread_flush_callbacks() is changed to no longer return the number
of dispatched callbacks; it becomes much harder when there are N queues
spread across multiple threads. Since it wasn't used for anything, just
drop the counting, making life slightly easier.
Feedback to thread tasks are however always queued on the callers
thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means each test is run 4 times:
* with atomic mode setting using a kernel thread,
* with atomic mode setting using a user thread,
* with legacy mode setting using a kernel thread, and
* with legacy mode setting using a user thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This isn't a problem for user space threads, as there are no race
conditions, but when kernel thread support is introduced, we must make
sure that e.g. the main loop is actually running before quitting it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This uses the queue that was introduced when migrating impl task
management from MetaThread to MetaThreadImpl, with the exception that
it's now fully used as an actual queue. It now has a GSource that sits
on the right GMainContext that is dispatched whenever there are tasks to
execute.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It's the impl side that wants to add impl side idle sources, or fd
sources, etc, so make it part of MetaThreadImpl.
This changes things to be GAsyncQueue based. While things are still
technically single threaded, the GAsyncQueue type is used as later we'll
introduce queuing tasks asynchronously, then eventually queuing across
thread barriers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It currently does exactly what MetaKms and MetaKmsImpl did regarding the
context separation, which is to isolate what may eventually run on a KMS
thread into a separate unit. It works somewhat like a "user thread",
i.e. not a real thread, but will eventually learn how to spawn a
"kernel thread", but provide the same API from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Remote desktop version 2 added a new method ConnectToEIS .
ConnectToEIS allows clients to requests a file descriptor from the
compositor which can then be used directly from libei.
Once established, the communication between compositor and application
is direct, without the need to go through the portal process(es).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Accessibility should be handled on the receiving end, if needed. Make
sure this is the case by listening on some signals, verifying they are
only triggered if we're not capturing input.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
When a relative pointer motion gets constrained (e.g. a monitor edge or
barrier), save the constrained relative motion delta too.
This will later be used to send the remaining motion delta to input
capture clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
An input only grab is a ClutterGrab on the stage that doesn't have an
explicit actor associated with it. This is useful for cases where event
should be captured as if focus was stolen to some mysterious place that
doesn't have anything in the scene graph that represents it.
Internally, it's implemented using a 0x0 sized actor attached directly
to the stage, and a clutter action that consumes the events. An
input-only grab takes a handler, user data and a destroy function for
the user data. These are handed to the ClutterAction, which handles the
actual event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Adding a barrier and later enabling the input capture session will
create MetaBarrier instances for each added input capture barrier.
The barriers are created as "sticky" which means that when a pointer
hits the barrier, it'll stick to the point of entry, until it's
released.
The input capture session is also turned into a state machine with
explicit state, to more easily track things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This allows for a sticky barrier to hold the pointer until it is
released, but the owner of the barrier doesn't need a barrier event to
release it. It will be used to implement input capturing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
A sticky barrier means that a pointer in motion intersecting a barrier
doesn't move once having hit it. The intention with this is to allow an
input capture clients to continue a motion once a barrier is hit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This API aims to provide a way for users to capture input devices under
certain conditions, for example when a pointer crosses a specified
barrier.
So far only part of the API is implemented, specifially the session
management as well as zone advertisement, where a zone refers to a
region in the compositor which edges will eventually be made available
for barrier placement.
So far the remote access handle is created while the session is enable,
despite the input capturing isn't actually active yet. This will change
in the future once it can actually become active.
v2: Remove absolute/relative pointer, keep only pointer (ofourdan)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
A 2D actorless paint volume can't ever need `enlarge_for_effects` because
it has no depth. Clamping to the pixel boundary is sufficient in this case
and avoids extending volumes on the edge of the view into the next view.
Which then avoids unnecessary secondary monitor updates.
Paint volumes correctly become actorless where `clutter_actor_finish_layout`
calls `_clutter_paint_volume_transform_relative`.
Relates to: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6819
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3112>
This was a temporary fix until there was a better crossing event
delivery mechanism that accounted for actor changes beneath the pointer.
We nowadays have that, and don't seem to need this extra kick to get
crossing events triggered (and cursor changes, etc) when windows appear
or disappear under the pointer.
This commit is effectively a revert of commit
a64dba4d7a.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6808
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3104>
With window_is_terminal gone, "strict" and "smart" focus mode have no
behavioural difference. Let's broaden the scope of strict focus mode,
such that windows never automatically focus unless they are an ancestor
to the transient.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
As noted in the comments of window_is_terminal, this is a hack. This
code has not been touched for the better part of a decade. App res_class
tends to differ between Wayland and X11, so it is likely that none of
these apps have been recognised as terminals under Wayland ever. Also,
there are reports that strict focus mode also does not work under X11,
likely due to changes in these terminal apps over the years resulting
in different res_class than those manually specified in here. Let's remove
this hack and change strict focus mode accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
Instead of using `clutter_actor_get_resource_scale()`, we now deduce the
intended buffer scale from the window by dividing the unscaled size by
the final actor size. This is more correct as while the return value of
`clutter_actor_get_resource_scale()` depends only on the monitor where
the surface resides, the actual scale of the surface is determined
solely by the application itself. `get_resource_scale` will differ from
the actual buffer scale if the application only supports 100% scaling
(Xwayland), or is performing scaling with wp_viewporter (clients using
fractional_scale_v1).
This also fixes a mismatch between the calculated buffer sizes between
`meta_window_actor_get_buffer_bounds` and
`meta_window_actor_blit_to_framebuffer` which causes broken
screencasting for Chromium 114 and later when using the native Ozone
Wayland backend.
Additionally, this commit also changes
`meta_window_actor_blit_to_framebuffer` from using a simple translation
to using an inverted matrix transformation of the transformation matrix
between the parent of the window actor and the surface actor to ensure
maximum sharpness for fractionally scaled windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3053>
Previously, restarting mutter in an X11 session resulted in
the previously set color temperature not being applied.
Fix that by applying the color temperature right after
the org.gnome.SettingsDaemon.Color proxy has been created.
Furthermore, only call `update_all_gamma()` from `on_gsd_color_ready()`
when the temperature has actually changed. Otherwise there is no need
since the current temperature has already been (or will soon be) applied
to all ready color devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3008>
We'd get a re-entry like scenario when destroying the PipeWire stream
object, where PipeWire would call the stream process vfunc. When this
happened, we had already destroyed the stream, so don't try to dequeue
or anything, just do an early exit. Fixes the following crash in the
test case client:
#0 pw_stream_dequeue_buffer() in /usr/lib64/libpipewire-0.3.so.0.367.0
#1 on_stream_process() at ../src/tests/screen-cast-client.c:348
#2 do_call_process() in /usr/lib64/libpipewire-0.3.so.0.367.0
#3 flush_items() in /usr/lib64/spa-0.2/support/libspa-support.so
#4 loop_invoke() in /usr/lib64/spa-0.2/support/libspa-support.so
#5 impl_send_command.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#6 suspend_node.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#7 pw_impl_node_set_state() in /usr/lib64/libpipewire-0.3.so.0.367.0
#8 client_node_removed() in /usr/lib64/pipewire-0.3/libpipewire-module-client-node.so
#9 pw_proxy_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#10 pw_stream_disconnect() in /usr/lib64/libpipewire-0.3.so.0.367.0
#11 pw_stream_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#12 stream_free() at ../src/tests/screen-cast-client.c:530
#13 main() at ../src/tests/screen-cast-client.c:803
#14 __libc_start_call_main() at ../sysdeps/nptl/libc_start_call_main.h:58
#15 __libc_start_main() at ../csu/libc-start.c:360
#16 _start() in /home/jonas/Dev/gnome/mutter/build/src/tests/mutter-screen-cast-client
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3095>
Setting up the image with a custom default user broke gnome-shell's
toolbox images. While running tests as non-root user seems like a
good idea, keeping people's development environment working should
be figured out first.
This partially reverts commit 69cc65d15f.
Keep the image to have a local user and use it to run tests so that
we can ensure that permissions are respected
Co-authored-by: Florian Müllner <fmuellner@gnome.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3083>
If an actor's expand properties haven't been set explicitly, its
expand flags are computed by traversing its children.
However we currently also traverse into children when explicitly
setting "expand" to FALSE, because that is the default value and
the properties are only marked as explicitly-set when the value
actually changed.
Fix this, so propagating expand flags can be stopped without
hacks like
```c
g_object_set (actor, "x-expand", TRUE, NULL);
g_object_set (actor, "x-expand", FALSE, NULL);
``
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3088>
If the timelines don't get destroyed they keep references to frame
clocks. Later tests check for the destruction of those frame clocks and
then can fail if the frame clock is implemented slightly differenty.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3084>
In remote desktop sessions, streams can be created and destroyed
on-the-fly.
If a stream is gone, it is not necessarily an error.
So, don't treat that situation like an erroneous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2911>
As it is the only place where cogl depends directly on cairo minus
the whole cairo_region_t.
The motivation behind the removal of this helper is to reduce the usage
of cairo in libmutter is to potentially completely drop it in
certain places or replace it with pixman.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3079>
The previous logic didn't work correctly at least when priority-based
preeption wasn't supported by the DRM driver, such as in the case
of amdgpu. The call to glGetQueryObjecti64v would block on client
work which is already in progress (most likely for the next frame)
and delay notifying the ClutterFrameClock about presentation.
Conveniently, the Wayland transactions mechanism guarantees that all
fences of a dma-buf buffer are signalled before the buffer is
included in a frame, which means that dma-buf buffers are ready for
presentation when being directly scanned-out.
Direct scanout is only supported for dma-buf buffers too, which means
that all buffers going through direct scanout are effectively ready
and require no GPU rendering before presentation.
Assuming zero rendering time for dma-buf buffers going through direct
scanout simplifies the code and removes the need for
glGetQueryObjecti64v, thus avoiding the aforementioned issue where it
could block for longer than expected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3080>
This is expected for the common case of direct scanout of Wayland
buffers where transactions guarantee that all buffer fences are
signalled before a buffer is included in a frame.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3080>
Dispatch jitter is how much the dispatch interval has changed between
frames. It's a measure of sampling smoothness for events that are occurring
at a higher rate than the screen is refreshing:
* Mouse movement
* Clients rendering at swap interval zero
* Keyframe animation position
Zero jitter is ideal but will practically never happen, and a jitter value
of several thousand microseconds will be visible to the naked eye as stutter
even if you're maintaining a perfect frame rate.
To make the numbers easier to interpret we also log the jitter as a
percentage of the refresh interval.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3082>
This could happen when moving the cursor over GUIs that only redraw
in response to cursor movement. Mutter would experience alternating
cursor-only updates and page flips, and so the `max_render_time_allowed_us`
would jump between pessimised and optimised resulting in inconsistent
frame pacing.
Aside from fixing the smoothness problem this should also provide
lower latency cursor movement.
Fixes: https://launchpad.net/bugs/2023766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3074>
Depending on the ordering of the surface-associated resources
being destroyed, we may fall into the following situation:
- wl_surface is destroyed
- destruction notifications for the surface runs
- The MetaWaylandKeyboard attempts to synchronize the window
focus
- The MetaWindow is not destroyed yet, so the focused window
remains the same, and the MetaWaylandKeyboard keeps the same
focus MetaWaylandSurface.
- wl_surface finalizes destruction, MetaWaylandSurface now has
a NULL resource
- xdg_toplevel destructor kicks in, it unmanages the window
- The current focus window is again looked up, forced to look
a different window
- The MetaWaylandKeyboard focus now changes, tries to leave the
old surface, but it has a NULL resource already, and raises
a protocol error.
If the order is inverted, the window being unmanaged triggers a
focus change into a different window, the MetaWaylandKeyboard
triggers a focus change while the MetaWaylandSurface is still
intact, it succeeds, and the window gets properly destroyed.
In order to make this independent of the order, it makes sense
to make MetaWaylandKeyboard do like the other objects tracking
focus surfaces, and have it care of its own little parcel. The
surface destructor changed to simply unsetting the keyboard focus
to NULL (guaranteeing that the old focus is left while the surface
resource is still up), and leaving potential focus changes to
the xdg_toplevel_destructor->unmanage->update_focus paths.
Doing that alone is basically a revert of commit 228d681b, thus
is still subject to keyboard focus being lost after a popup is
destroyed. Change the approach to trigger the focus sync (and
new focus surface lookup) so it happens from xdg_popup_destructor
specifically to popups and alike xdg_toplevel.
Fixes: 228d681b ("wayland: Trigger full focus sync after keyboard focus surface is destroyed")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2853
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3077>
Current behavior pushes a window which receives focus to the start of
the MRU list on every workspace it is on. By focusing a sticky window
the default focus on all other workspaces changes as well. This is fine
for sticky windows explicitly marked as sticky by the user but if a
window is on a secondary output and workspaces are only on the primary
output the behavior is unexpected. Instead we want the window to be the
default focus only on the current workspace but also keep those windows
in a relative MRU order to each other on all workspaces.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2681
Fixes: 058981dc1 ("workspace: Focus the default window only if no window is focused")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2909>
This avoids use-after-free when handle_start() is called following
handle_stop() during the lifetime of the MetaProfiler. This happens
on repeated profiling sessions using Sysprof.
Fixes: e16d68372 ("profiler: Add API to register profiler threads")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3076>
We need to juggle with some things here to keep key event ordering
and accounting consistent.
The keyboard internal state changes (and maybe modifier event emission)
happening through meta_wayland_seat_update() should ideally happen
from the same key events that reach the client through wl_keyboard.key,
so that wl_keyboard.modifier events are emitted in the right relative
order to other key events.
In order to fix this, we need to decide at an earlier point whether
the event will get processed through IM (and maybe be reinjected),
thus ignored in wait of IM-postprocessed events.
This means we pay less attention to whether events are first-hand
hardware events for some things and go with the event that does
eventually reach to us (hardware or IM).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5890
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Given the presence of IMs and the different paths in event handling to reach
one of them, we cannot make guesses about whether should stick to the original
hardware-triggered event, or wait/prefer a second hand IM event that might or
might not arrive. We also have no say for other IM foci unrelated to wayland
(e.g. ClutterText) triggering the double event emission.
So go with it and maintain our own internal state for keys, we already kinda
do, but mainly for warning purposes, at the time of updating the
MetaWaylandKeyboard state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Currently, we let the same function handle key event filtering as they
are passed to the IM, and the IM events resulting in actions like text
commit or preedit changes.
Split these two aspects into filter/process functions, and port
ClutterText to it. MetaWaylandTextInput still handles everything in
a single place, but that will be split in later commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
This means initializing the pointer position in MetaSeatImpl
synchronously too, otherwise it's not guaranteed querying the seat state
will result in the expected position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3071>
I have a monitor which can report two preferred modes: 5120x1440@240
and 3840x1080@60. Since they are enumerated in this order by KMS,
init_output_modes would end up using 3840x1080@60 (and it was impossible
to select any 5120x1440 mode in the GNOME display settings).
Fix this by using meta_kms_connector_get_preferred_mode, which returns
the first KMS mode with DRM_MODE_TYPE_PREFERRED.
v2:
* Use meta_kms_connector_get_preferred_mode. (Jonas Ådahl)
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3055>
This will consist of device-added events, meaning before init finishes,
we can derive some state that depends on the set of input devices
available on startup, such as cursor visibility.
This avoids cursor visibility switching between hidden and visibility
during startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This opens up for a possibility to handle initial events (devices
discovered on startup) during initialization, meaning we can figure out
a more correct initial state that depends on available input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This is different from "warping" as it doesn't necessarily result in a
pointer motion event. This can be helpful during initializing so we can
avoid faked pointer events that would otherwise need to be special cased
to not appear as actual pointer movements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
glGetIntegerv() with GL_RED_BITS/GL_GREEN_BITS/GL_BLUE_BITS/etc. is not
supported with the GL core context, so there is no point in falling back
to that without supporting COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS,
as this will cause an GL error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
The function ensure_bits_initialized() in cogl-gl-framebuffer-fbo.c
checks for COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS whereas the same
in cogl-gl-framebuffer-back.c simply checks for the driver being
COGL_DRIVER_GL3.
Change the later to use the COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS
flag as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
Cogl's feature COGL_PRIVATE_FEATURE_QUERY_FRAMEBUFFER_BITS is required
to use the GL_FRAMEBUFFER_ATTACHMENT_* queries.
Unfortunately, the test for the availability of the private feature is
actually inverted in ensure_bits_initialized() which causes that whole
portion of code to be ignored, falling back to the glGetIntegerv()
method which isn't supported in core profiles.
As Mesa has recently started to be more strict about these, this causes
the CI tests to fail in mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3047>
The stage already maintains its own list of stage-views via
clutter_stage_peek_stage_views(), it's a bit superfluous to copy that list
around all the time into priv->stage_views of ClutterActor. Let's deal with
that by returning clutter_stage_peek_stage_views() when
clutter_actor_peek_stage_views() gets called for the stage.
In order to make sure ClutterActor::stage-views-changed still gets emitted
correctly for the stage, always emit that signal on the ClutterStage when
the stage views get invalidated. This now depends on the backend only
actually invalidating the views and calling
clutter_stage_clear_stage_views() when things have actually changed, but
that should be the case.
This needs a change in one of the stage-views tests, namely the one which
tests stage-view-changed emission on the stage: Here we now see an emission
of stage-views-changed, but that signal emission actually seems correct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
While we're now doing a fairly good job at not needing those matrices
all the time anymore, we still need it multiple times during every paint
cycle, so it definitely makes sense to introduce some caching here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
With commit 5a565b4258, we changed
clutter_actor_finish_layout() to be not only about updating stage views,
but also take care of updating the visible_paint_volume, for that we
started doing a full tree traversal of all mapped actors.
This can be quite a performance issue, apparently especially on certain
ARM devices, where the simple tree traversal can take as long as 2ms.
This is precious time we need to paint our next frame, so lets do a bit
more work to avoid those useless traversals.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/2459
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
We're using clutter_stage_schedule_update() now from ClutterActor to kick
off the stage updating machinery when a redraw needs to happen.
This introduced a bunch of unnecessary calls to
clutter_stage_schedule_update() and thus
clutter_stage_view_schedule_update() when multiple actors request redraws
during the same stage update cycle, which is a very common case.
Cut off all those unnecessary calls by bailing out in
clutter_stage_schedule_update() when updates are already queued.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
Using a list of heap allocated ClutterPaintVolumes adds quite a bit of
unnecessary overhead: It means for every single redraw clip we allocate a
list and a paint volume on the heap.
Let's avoid all those heap allocations by using a GArray with static
ClutterPaintVolumes instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
So far our logic for queueing redraws goes like this: Actor notices that it
needs to redraw -> actor tells stage that it needs to redraw via
clutter_stage_queue_actor_redraw() -> stage collects more and more redraws
into a QueueRedrawList before the actual stage update happens -> when
that happens, the stage collects the actual redraw clips from the actors via
clutter_actor_get_redraw_clip().
The logic behind this QueueRedrawList was that by storing a list of
redraw entries on the stage, way we can avoid traversing the whole actor
tree one more time to build the redraw clip before the stage update.
These days we have clutter_actor_finish_layout() though, which is basically
exactly that, a whole actor tree traversal that happens before every stage
update.
Since we have that now, we might as well get rid of the whole dance back and
forth between ClutterStage and ClutterActor, and simply merge the logic to
queue redraws into the finish-layout step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
If no actors have changed their positions and we're only repainting
because a window needs a repaint, the paint volumes of all actors
remain unchanged. There is no reason to redo those paint volumes on every
stage update.
So introduce caching and invalidation logic for the visible_paint_volume
that allows us to avoid a ton of matrix multiplications that right now
are happening for the whole mapped actor tree on every redraw.
Note that this removes two places where the visible paint volume is set
to an empty paint volume: This is a compromise so that we can keep
around the cached pv when hiding and showing an actor, it does "regress"
one case though: When hiding -> moving -> showing an actor, we'll now
include the old paint volume of the actor in the redraw clip on show (even
though redrawing that old region is not necessary, the actor was hidden
after all). This results in a bit of overpaint in this very specific case,
but for the sake of simplicity let's not care about that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
There were two issues with using the shape region to derive an input
region.
Firstly, the shape region is against the client rectangle, while the
surface actor needs it to be against the buffer rectangle. Fix this by
offsetting the shape region before passing it along.
Secondly, we can't just intersect the shape and input region, since that
leaves out the window decorations. Fix this by only intersecting the
input region covering the client part, and the shape region, and then
union that with the input region covering the rest.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3045>
When building mutter with -Ddebug=false, a warning appears, that
`ClutterStagePrivate *priv` is unused.
Simply remove this variable and directly use `stage->priv` in
`CLUTTER_NOTE` to get rid of this warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3046>
Don't try to handle things by threads enabling/disabling the main trace
context on-demand, just have a clear start/stop API. For the D-Bus API,
it becomes more straight forward, and for the persistent variant too, as
it avoids having to pass garbage input when it's known that arguments
will be discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Persistent profiling was started via an env var, but that's rather hard
to discover and remember without grepping; change to use a command line
argument.
The profiler is started early, even during (though late in)
configuration, but configuration should ideally be instant and pointless
to configure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Under X11 hiding the backend implies also unmapping the stage window, if
we do that after that we've closed the display we may end up in a
BadWindow error because such window seems to be destroyed together with
the compositor output parent (even though we are not notified about), so
to prevent this, reparent the backend window during compositor unmanage,
setting it back as a root window child.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2835
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3020>
Original commit message:
> ATM sending modifiers to clients prevents direct scanout for DRI3
> clients via Xwayland. Xwayland using the dma-buf feedback v4 Wayland
> protocol will solve that, but that might take a while yet to appear in
> the wild. Once that happens, this can be reverted.
>
> Direct scanout still works for native Wayland clients as well.
Xwayland got support for v4 in 23.1.0, thus let's reenable modifiers on
AMD.
This reverts commit 2f825f3a86.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3030>
We are now building and testing mutter as user, but the clone may happen
as root, before the docker image takes place.
This may create troubles to git, causing errors such as:
fatal: detected dubious ownership in repository at ...
And we can't fix this using safe.directory option because we have no
control on the system at this scope.
So, let's just handle the cloning manually so that the meta-user is
always the owner of the repository.
This fixes the dist job, but also other jobs that may fail because of
this reason.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3024>
Using the old replace syntax doesn't allow to extend dicts such as
variables or other values, but instead it replaces them.
So use a newer and safer syntax, given we don't need to replace any
parameter where used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3024>
We currently lock the capability of the MetaOrientationManager to emit
the ::orientation-changed signal, but otherwise keep reading the current
orientation and returning it if we are asked politely through
meta_orientation_manager_get_orientation().
This may bring issues e.g. around suspend/resume, since there may be other
parts of the code trying to get the current orientation without receiving
::orientation-changed signals, this may result in the display orientation
being effectively rotated, then stay locked after that.
In order to fix this, make the MetaOrientationManager return a fixed
orientation while locked, only updated after changes in the lock state.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2600
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3021>
This is missed, leaving the cursor renderer disconnected from the stage
updates that could trigger further frame callbacks on the cursor, leaving
some clients like Xwayland stuck with cursors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3025>
It's just closer to reality of an user session.
As per this:
- We need to bump the required CI template to use this feature.
- Use sudo in the actions that require it
- Replace pkexec with sudo (it wouldn't work otherwise)
- Ensure we don't rebuild during install not to break build dir
- Give permission to use /dev/kvm to our user (we do this during the
image creation because we don't have an user when $FDO_DISTRIBUTION_EXEC
happens)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3016>
We already test install as part of other jobs (such as
can-build-gnome-shell) and in general that's wrong because we may
add to the final install path artifacts that are required during tests,
hiding potential issues with meson test when those files are not
installed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3016>
It's not required and makes things hard to maintain, we can just rely on
the fact we're in a shell and just use `set -e` to prevent any
unexpected failure to go unnoticed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3016>
ClutterText paints selected text using the selection_paint()
function. This function has to main branches of execution:
when the position is in the selection bound, or not. In the
former, we are leaking the CoglPipeline created by copying
the default color pipeline.
Unref the copied pipeline after using it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3007>
For now, it goes the "easy" way of creating the root node and
immediately painting and destroying it. From now on, the main
root node is created only by ClutterStage itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3007>
We do in fact allow these combinations of configuration since the Settings
Wacom panel revamp. We no longer need to look up Wacom device features,
since this is allowed for all the devices that have these settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
We avoided setting the device matrix applying to the tablet tool (used if the
tablet is in absolute coordinates mode) if the device is configured for relative
motion, but forgot to apply the matrix if changing the device back to absolute
mode, this made the device seemingly forget its attached display until later
configuration changes.
In order to avoid the hassle of looking up the right display again on unrelated
configuration changes, make the matrix be always set on the device, but only
actually used in absolute coordinates mode. This makes the device able to
seamlessly switch between modes and remain mapped to the right display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
This was somewhat ineffective since it was applied after figuring out
the x/y absolute coordinates. Change the order (filter first, then
figure out abs coords), and use coordinates from the correct device
while at it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
Fix the following warnings reported by udevadm verify:
data/61-mutter.rules:2 Whitespace after comma is expected.
...
data/61-mutter.rules:116 Whitespace after comma is expected.
data/61-mutter.rules: udev rules check failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3011>
A window may become undecorated while the frame window is
frozen due to updates. In that case we would both miss a
reply for the frame window, and any other means to trigger
the window actor being thawed.
Check the frozen state after destroying the frame, so that
meta_window_x11_are_updates_frozen() may end up changing
opinion if the frame window was caught in this situation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2639
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2996>
`meta_surface_actor_is_obscured_on_stage_view` currently fails to
account for non-identity scaling of actor size (e.g. window actor
geometry scale or surface pixel alignment).
Fix this by using the new `meta_region_apply_matrix_transform_expand` to
calculate the unobscured region in stage coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
This allows MetaCullable to work with actors using arbitrary transforms
which will be needed for implementing surface pixel alignment for
fractional-scale-v1.
This also deletes meta_cullable_is_untransformed as it's no longer
necessary, and we can also stop manually scaling the region objects
while performing opaque region culling in surfaces since it's now
handled transparently by the new `meta_cullable_cull_out_children`
implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
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>
Always ensure that the MetaSurfaceContainerActorWayland is aligned to physical
pixel boundary in preparation for fractional-scale-v1 protocol support.
This introduces an override of ClutterActor::apply_transform vfunc for
MetaSurfaceContainerActorWayland that always ensures the actor content is aligned
to physical pixel boundary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
The template already does this at the end, so this step is
pointless in the best case.
When building the x86-64 image, we install additional packages
afterwards, so the repo metadata is downloaded again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3010>
The only consumer of this type of rect was the scissor clipping,
which was removed by the previous commit.
Remove window rects from CoglClipStack, and all dependent code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3006>
A failing allocation is non-fatal here, however if it fails later in a
lazy allocation triggered by `cogl_framebuffer_create_timestamp_query()`
we end up crashing. Thus force the allocation early, like we already do
in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3004>
While it's obviously good to trap possible errors from X calls, we are
mixing the Clutter error trap with the MetaX11Display one for these
calls.
This may result in situations where a X call within a Clutter error
trap fails, but it's actually handled in these sections using the
MetaX11Display error trap. This one will consider the serial out
of the "handled" parts and raise an error.
It is better to stay consistent here, and use the same error traps
than the rest of the X11 backend.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2796
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3002>
When the X11 display is actually XWayland there's no point to delay the
compositor selection, given that mutter itself is the compositor and
doing this may cause the first X11 client that starts not to receive the
right information (and in some cases misbehave).
Since some toolkits are not handling the compositor selection changes
properly at later times, let's make their life easier by just
initializing the selection as early as the other X11 properties, given
that in this case there's nothing to replace.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
Since c390f70edc ("backend: Set up and use ownership chains")
the type of the ClutterInputDevice object's "meta-input-settings-xdevice"
data is `DeviceHandle`, but that commit failed to change the one place
where the object data is queried. As a consequence, that part still
considers it to be an `XDevice`, so everything that uses the return
value of `device_ensure_xdevice()` works with invalid data. Furthermore,
`device_handle_free()` incorrectly uses the `user_data` as the argument
for `XCloseDevice()` leading to a double free.
Fixes: c390f70edc ("backend: Set up and use ownership chains")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2995>
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>
Otherwise drivers would be free to alter the buffer content. While no
driver is known to do so, it's probably good to make things explicit.
See also `import_simple_dmabuf()` in Weston.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2990>
The DMA buffer paths vs MemFd paths differ slightly in when content is
recorded. This was in some places done by trying to record but bail if
the dequeued buffer had the wrong type. This is problematic for two
reasons: we'd update the timestamp even if we refused to record, making
the follow-up attempt fail, and we'd dequeue and queue buffers that
didn't get any content, meaning the receiving end would see empty
buffers potentially with only cursor updates.
Fix this by keeping track if a stream is DMA buffer able or not, and
don't attempt to record at all in the places we would previously require
DMA buffers. This avoids both issues: we don't dequeue/queue pw_buffers
that we refuse to record to, and we won't update the recorded timestamp
when we didn't intend to record to begin with.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2783
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2987>
This aims to reduce the amount of pixels that have to be redrawed on the
screen on a clipped actor redraw in case using the union of two
different clips in a surface will substantially increase the redrawn
area.
This should not result in excessive memory consumption as callers of
`clutter_actor_queue_redraw_with_clip` are expected to ensure that the
redraw clip rectangles are adequately deduplicated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2965>
mutter-clutter is a private library that is only used by the shell and
not meant to be ABI/API compatible in between versions, so there's no
need to add padding to classes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2903>
Hides libdisplay-info under a build time default-off flag,
provides provision to parse essential edid parameters with
APIs provided by libdisplay-info. This implementaion increases
readibility, avoids code duplication and decreases complexity
of edid parsing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2642>
We are attempting to show windows that do not yet have a
surface/buffer, this makes GNOME Shell avoid transitions
for these windows.
Since on Wayland X11 windows are also Wayland surfaces,
this check is also valid for these, and is thus made more
generic to also cater for these windows.
Eventually, meta_window_update_visibility() is called
when the surface gets its buffer, so the window can be
neatly animated.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2611
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
This ATM triggers missed .commit events for the window in question,
to be addressed in Xwayland. Since the test does not seem to specifically
rely on this window being CSD, make it a regular window instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
Going for the default GL renderer is known to trigger rendering
artifacts using the NVidia proprietary driver. Since we don't have
too many expectatives about frames being flashy (not to the point
of mandating GL), resort to the cairo renderer in the mean time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2976>
Just like the HDR Metadata property the Colorspace property values only
indicate that the display driver supports signaling certain colorimetry.
It does not indidcate that the sink actually supports processing the
colorimetry. For this we have to look up the colorimetry support in the
EDID.
The default colorimetry is always supported. If we want bt.2020 we might
get either the RGB or YCC variant even if we ask for the RGB variant but
there is nothing we can do about it so let's just pretend it's a driver
issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2919>
If the used EGL backend supports it. In practice this should currently
only affect the nested backend.
Enabling modifiers can help with app development. An example is
`weston-simple-dmabuf-v4l`, which requires the linear modifier to be
available.
Note that Weston behaves similar already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2972>
This will be used to extract the resolution and refresh rate from
strings like "1920x1080@60.0" or "1280x720". This aims to replace the
use of the locale dependent sscanf() function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
This is needed by GNOME Shell to remove itself as a input method
implementation during its shutdown sequence. We can't do it ourself
later because at mutters own shutdowns equence, the GNOME Shell
Javascript context has by that time already been teared down.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2934>
This function gets called when a surface state transaction is applied.
Applying a transaction can get delayed, so the Wayland resource may have
already been destroyed when we get here. In that case we cannot send
events, so there's nothing to do.
v2:
* Drop code comment, expand commit log instead. (Jonas Ådahl)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2737
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2967>
Otherwise we'll have a cursor sprite backed by a surface that no longer
exist. This usually doesn't happen, but can happen in rare situations
related to pointer capability changes Wayland client cursor changes and
hotplugs.
Fixes the following crash:
#0 meta_wayland_buffer_get_resource() at ../src/wayland/meta-wayland-buffer.c:128
#1 realize_cursor_sprite_from_wl_buffer_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1649
#2 realize_cursor_sprite_for_gpu() at ../src/backends/native/meta-cursor-renderer-native.c:1869
#3 realize_cursor_sprite() at ../src/backends/native/meta-cursor-renderer-native.c:1887
#4 meta_cursor_renderer_native_update_cursor() at ../src/backends/native/meta-cursor-renderer-native.c:1100
#5 meta_cursor_renderer_update_cursor() at ../src/backends/meta-cursor-renderer.c:414
#6 meta_cursor_renderer_force_update() at ../src/backends/meta-cursor-renderer.c:449
#7 update_cursors() at ../src/backends/meta-backend.c:328
#8 meta_backend_monitors_changed() at ../src/backends/meta-backend.c:338
#9 meta_monitor_manager_notify_monitors_changed() at ../src/backends/meta-monitor-manager.c:3590
#10 meta_monitor_manager_rebuild() at ../src/backends/meta-monitor-manager.c:3678
#11 meta_monitor_manager_native_apply_monitors_config() at ../src/backends/native/meta-monitor-manager-native.c:343
#12 meta_monitor_manager_apply_monitors_config() at ../src/backends/meta-monitor-manager.c:706
#13 meta_monitor_manager_ensure_configured() at ../src/backends/meta-monitor-manager.c:779
#14 meta_monitor_manager_reconfigure() at ../src/backends/meta-monitor-manager.c:3738
#15 meta_monitor_manager_reload() at ../src/backends/meta-monitor-manager.c:3745
or the following on gnome-43:
#0 meta_wayland_surface_get_buffer at ../src/wayland/meta-wayland-surface.c:441
#1 meta_cursor_sprite_wayland_get_buffer at ../src/wayland/meta-cursor-sprite-wayland.c:83
#2 realize_cursor_sprite_from_wl_buffer_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1612
#3 realize_cursor_sprite_for_gpu at ../src/backends/native/meta-cursor-renderer-native.c:1836
#4 realize_cursor_sprite at ../src/backends/native/meta-cursor-renderer-native.c:1854
#5 meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1087
#6 meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:413
#7 meta_cursor_renderer_force_update at ../src/backends/meta-cursor-renderer.c:448
#8 update_cursors at ../src/backends/meta-backend.c:344
#9 meta_backend_monitors_changed at ../src/backends/meta-backend.c:354
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2185113
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2968>
Under certain conditions a stage-view update does not trigger a kms
update.
In such cases we still want the next update to run within the same
refresh cycle, as otherwise we'd waste the remaining time in the
current one.
At the same time we currently use the `after-update` signal for Wayland
frame events, which again may result in more "empty" updates -
creating an unthrottled feedback loop. This can trigger excessive
load both in the compositor as well as in clients.
Introduce a new GSource that is dispatched once per refresh cycle at
maximum per stage view and use it to emit frame events. Do so by
computing the time from when on we can be sure that an update resulting
from a client commit would certainly get scheduled to the next refresh
cycle.
Note: this only works on the native backend. Given that chances are
small that we hit the corresponding issue on e.g. the nested backend,
stick to the previous behavior there for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
It will be used to schedule Wayland frame events independently from both
update and presentation time, as the former may happen multiple times
frame and the later not at all.
For frame events we want a timing that is just late enough to ensure
that a following commit by a Wayland client will not get included into
the current frame any more.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2823>
When selecting the default focus window, is_focusable() was not
considering the new conditions for whether a window should be shown or
hidden that were added to meta_window_should_be_showing() in 39942974.
As a result the default focus window could end up a window already
hidden or hidden once meta_window_flush_calc_showing() is called by
meta_window_focus() when focusing the default window. This would cause
meta_window_focus() to fail, which is an issue if it prevents us from
unfocusing a window when it is getting unmanaged.
Fixes: 399429742 ("x11: Integrate frames client into Mutter")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2644
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2962>
create_and_send_dnd_offer() sets the compositor of the offer to the one
from the MetaWaylandDataSource. This then later gets used in
display_from_offer() when trying to get the context from the compositor.
meta_wayland_data_source_xwayland_new() however was not setting the
compositor, so this was causing crashes when dragging things from X11
windows on Wayland.
Fixes: 2731f0cda ("wayland: Setup and use ownership chains")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2723
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2956>
This ensures that applications are notified when a drag gets cancelled
because the user dropped or press ESC while in overview.
This fixes an issue with Chromium on Wayland refusing to acknowledge
wl_pointer::enter events after accidentally dropping a
Chromium-originated object in GNOME Shell overview.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2953>
Ensure the frame window is created at the right fullscreen state
before showing it and assigning it to the client window.
A peculiarity of this property on frame windows is that it is
typically single-handedly updated from the Mutter side, in synchronization
with client window state. It can only differ during creation, since
GTK still likes to apply its own state.
Also, the only relevant property seems to be _NET_WM_STATE_FULLSCREEN,
since the others are less relevant to the role of the frames client,
and get applied to the MetaWindow as a whole, instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2712
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2961>
After this got changed from gdk_x11_get_xatom_name() to XGetAtomName(),
this no longer returns a const char* and it now also needs to be freed.
Fixes: e66f4396e ("x11: Avoid GDK API in X11 selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
This was pointlessly being converted between atom and string and back,
which with the switch from gdk_x11_get_xatom_name() to XGetAtomName()
also introduced a leak for every XGetAtomName() call.
Fixes: e66f4396e ("x11: Avoid GDK API in X11 selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
The private format and type member variables were not being used by any
of the callers, so they can simply be removed. This also fixes a leak of
type which was introduced when switching from gdk_x11_get_xatom_name()
to XGetAtomName().
Fixes: e66f4396e ("x11: Avoid GDK API in X11 selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
After this got changed from gdk_x11_get_xatom_name() to XGetAtomName(),
this no longer returns a const char* and it now also needs to be freed.
Fixes: 014cde646 ("wayland: Do not use GDK functions on XDnD implementation")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
We might end up trying to apply a pending state late if it was delayed
by DMA buffers not being ready. Trying to discard the pending state from
the transaction when dismissing is hard, because we might be applying a
chain of transactions that would disqualify subsequent transactions if a
former one dismisses the popup, so lets just drop what the apply would
otherwise do, if we're not going to use it anyway.
This fixes the following crash:
0) meta_wayland_surface_get_window (surface=0x0)
1) meta_wayland_xdg_popup_apply_state (surface_role=0xf5ee80, pending=0xf662a0)
2) meta_wayland_surface_role_apply_state (surface_role=0xf5ee80, pending=0xf662a0)
3) meta_wayland_surface_apply_state (surface=0xf5e640, state=0xf662a0)
4) meta_wayland_transaction_apply (transaction=0xf56170, first_candidate=0x7fffffffcee8)
5) meta_wayland_transaction_maybe_apply_one (transaction=0xf56170, first_candidate=0x7fffffffcee8)
6) meta_wayland_transaction_maybe_apply (transaction=0xf56170)
7) meta_wayland_transaction_dma_buf_dispatch (buffer=0xf448a0, user_data=0xf56200)
8) meta_wayland_dma_buf_source_dispatch (base=0xf5f140, callback=0x0, user_data=0x0)
9) g_main_dispatch (context=0x41baa0)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
If the popup was dismissed (i.e. has no MetaWindow anymore), it'll also
have no parent surface. With no parent surface, we'd try to fetch a
transaction from NULL and crash, but if we don't try if we were
dismissed, we won't reach here anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
With the frames client, we do no longer handle events for the
frame window inside Mutter. This means we do not get events
"for free" to handle focus on a just clicked frame window.
This results in a background window not ending up focused if
clicked on its frame.
In order to fix this, make the passive button grab extend to
the frame window if a window has one. This brings back
focus-on-click behavior, while treating windows further as
a unitary surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2727
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
Pass the timestamp of the frame as the target timestamp of the
record. This makes the rudimentary frame throttling mechanism
inside MetaScreenCastStreamSrc work with the timing variability
that dynamic dispatch times introduced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Instead of always, unconditionally scheduling an idle callback for
frame recording, try to record a DMA-BUF only frame, and only if
that's not possible, schedule the idle callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
When a stream source subclass asks for a DMA-BUF only frame record,
it is legitimate to return FALSE in do_record_frame() - meaning that
a frame was not recorded - but not return an error - meaning nothing
actually failed.
This avoids spamming the journal with warnings on a legitimate case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Add meta_screen_cast_stream_src_maybe_record_frame_with_timestamp()
which operates on arbitrary timestamps; and make the current function
meta_screen_cast_stream_src_maybe_record_frame() just call into the
new variant, passing g_get_monotonic_time() as the timestamp.
This will be useful later we start using the target timestamp of the
frame for screencasting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
This is not yet used, but next commits will need to assign a frame
to the paint context whenever painting onscreens.
Assigning a frame to the paint context is a one-way operation, and
treats multiple assignments strictly as a programming error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
This change will export the damaged regions (when available) out
to the pipewire client. This change is currently specific to
virtual streams only (where I was able to test the change) and
maintains the current behavior for other screencast stream types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
This change allows clipped redraws for offscreen. The net
effect of this change is to preserve the original redraw clip when
possible (rather than overwriting it with the full view redraw) in
the paint context.
This eventually helps in retrieving the fine grained updated regions of
the frame since last redraw and sending it to the pipewire client
(as shown in a subsquent CL).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
Returning FALSE does not indicate an error, but a valid backlight
value of 0. Consumers expect a negative value to indicate no
backlight support, so return -1 in case of error, just like we
already do for invalid values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2947>
The window tracker is filtering XEvents manually as it only requires a
subset of the ones that Gdk listens to in the root window, and this is
nice, but we were restricting the set a bit too much because due to this
we were not notified when an xsettings manager was available, and thus
in case gsd-xsettings was launched after meta-window-tracker (a normal
scenario under X11), no xsetting was actually applied to the decoration
windows.
As per this, the default settings were used for everything and never
updated, until a restart of the window-tracker.
In order to be able to monitor the XSettings changes at startup, we also
need to select the StructureNotifyMask as gtk always do by default.
See also:
https://gitlab.gnome.org/GNOME/gtk/-/blob/4.11.1/gdk/x11/gdkscreen-x11.c#L947-950Fixes: #2580
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2948>
The anchor position calculations are somewhat unnecessarily complex
based on root coordinates of pointer and frame positions. This requires
tracking both things, and we don't always get it quite right with the
latter (e.g. window repositions, resizes or overshrinks, leaving the
anchor position visually outside the window).
In order to improve this, capture the window-relative coordinates
when starting the window drag, and ensure the window is always repositioned
in that position, relative to its current size.
This avoids these glitches when unmaximizing a window (e.g. dragged from
the bottom through super+button1 press), or moving windows between monitors
with different scales.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2730
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
Since we only track changes to window_drag->anchor_window_pos
during move operations through on_grab_window_size_changed(), this
rectangle is in essence the same than window_drag->initial_window_pos
all the time. Just use that and move away from the anchor_window_pos
rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
scan_visible_region() scans through each value of a uint8_t array and checks
whether that value is 255. Right now it always checks one value too much
though, resulting in a buffer overflow. Fix that by checking the array
bounds before actually accessing the array.
Found by running gnome-shell with address sanitizer and starting
GIMP.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2856>
Both Clutter and Cogl use g_return(_val)_if_fail() to safeguard
introspected API. Release builds were dropping these checks, which could
result in a much more crashy experience, especially when considering
extensions, but also due to bugs in the shell code itself.
This won't affect any major distro, because they all use "plain" builds.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2930>
Both GRAB_OP_KEYBOARD_MOVING and GRAB_OP_KEYBOARD_RESIZING_* are
defined as GRAB_OP_WINDOW_BASE with FLAG_KEYBOARD set, but the
latter have additional bits set to indicate the direction.
That is, the GRAB_OP_KEYBOARD_MOVING bitmask cannot be used to
differentiate between move- and resize operations. Instead,
check that no direction bits are set.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2684
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2908>
The unknown color space's only purpose is to signal that the current KMS
state has a unknown color space set. It is not one of the color spaces
that can be set. We already only try to set a color space if the default
color space is supported so we should use the default color space as a
fallback instead of the unknown color space.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2693
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2915>
With the move away from GTK3, and the indirect dependency on GTK4
grown in the GNOME Shell side, we've indirectly gotten a small sneaky
behavioral change: The GTK4 library will, right on dlopen, get
DESKTOP_AUTOSTART_ID for itself and delete it from the environment.
This happens before our own X11 session management code is
initialized, which confuses the hell out of it, into thinking
initialization is actually shutdown, gnome-session does not follow
along with this request, which leaves GNOME Shell into a confused
startup state where it never calls SmcSaveYourselfDone() and grinds
startup to a halt until gnome-session decides to move things forward.
In order to fix this, get the DESKTOP_AUTOSTART_ID before we lend
control to GNOME Shell bits and GTK4 is possibly initialized, and
feed it directly to our X11 session manager bits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2906>
We might get told to restore the old monitor configuration by the
monitor configuration prompt, in case the user pressed "revert" or
equivalent. This might be in response to a button press, and those
happen during frame clock dispatch. If we would restore an old
configuration during dispatch, it means we would reconfigure the
monitors including their stage views while dispatching, which means we'd
destroy the frame clock while it's dispatching.
Doing that causes problems, as the frame clock isn't expecting to be
destroyed mid-function. Specifically,
We'd enter
clutter_frame_clock_dispatch (clutter-frame-clock.c:811)
frame_clock_source_dispatch (clutter-frame-clock.c:839)
g_main_dispatch (gmain.c:3454)
g_main_context_dispatch (gmain.c:4172)
g_main_context_iterate.constprop.0 (gmain.c:4248)
g_main_loop_run (gmain.c:4448)
meta_context_run_main_loop (meta-context.c:482)
main (main.c:663)
which would first call
_clutter_process_event (clutter-main.c:920)
_clutter_stage_process_queued_events (clutter-stage.c:757)
handle_frame_clock_before_frame (clutter-stage-view.c:1150)
which would emit e.g. a button event all the way to a button press
handler, which would e.g. deny the new configuration:
restore_previous_config (meta-monitor-manager.c:1931)
confirm_configuration (meta-monitor-manager.c:2866)
meta_monitor_manager_confirm_configuration (meta-monitor-manager.c:2880)
meta_plugin_complete_display_change (meta-plugin.c:172)
That would then regenerate the monitor configuration and stage view
layout, which would destroy the old stage view and frame clock.
meta_stage_native_rebuild_views (meta-stage-native.c:68)
meta_backend_native_update_screen_size (meta-backend-native.c:457)
meta_backend_sync_screen_size (meta-backend.c:266)
meta_backend_monitors_changed (meta-backend.c:337)
meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:3595)
meta_monitor_manager_rebuild (meta-monitor-manager.c:3683)
meta_monitor_manager_native_apply_monitors_config (meta-monitor-manager-native.c:343)
meta_monitor_manager_apply_monitors_config (meta-monitor-manager.c:704)
After returning back to the original clutter_frame_clock_dispatch()
frame, various state in the frame clock will be gone and we'd crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
Commit 7e9d9c7eb9 added new API to replace GTK for accelerator
parsing.
Unfortunately there is another case in gnome-shell, where we have
to get the label from the logical binding name rather than the
modifier+keysym combination.
Add another small method to cover that use case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2899>
Normally, mutter implicitly allows a window being shown to take
focus. This is normally desired, except it steals input from
GNOME Shell self. Avoid focusing the just shown window in those
situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
When a X11 application is started, typically what happens is:
- A startup notification token is created, with a _TIME%d suffix
- The application being spawned receives it through the environment
- (dbus piping, maybe)
- The application replies the startup notification token, and
fetches the timestamp from it
- The application makes a _NET_ACTIVE_WINDOW client message request
with this timestamp
- Mutter handles this client request and activates/focuses the window
Prevent this last step if windows are not interactable (e.g. there is
a compositor grab) and ignore the focus request. This specifically
applies to X11 clients requesting focus themselves, and unlike previous
approaches, doesn't try to prevent focus changes that do come through
interaction with Mutter/GNOME Shell.
This should only break if applications do not observe _NET_ACTIVE_WINDOW
and perform XSetInputFocus on themselves, but in that case the X11
keyboard focus is stolen from our hands already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
This is the mask that lets us receive among other events the rather
important CreateNotify, that tells us about new winows. This has went by
rather unnoticed except for cases where multiple windows show up very
quickly directly after the frames client spawned, because the drag icon
surface cache eventually already did select that particular mask.
Make things more reliably by explicitly setting the mask for the events
we rely on to function.
This fixes flaky stacking tests that map multiple X11 windows in a row.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2894>
2d8fa26c8e ("core: Pass "frame action" grab operations as an
"unconstrained" grab op") changed the behaviour to treat non-grab
related window moving that has the "user action" flag set to still apply
the "constrain_titlebar_visible" constraint.
The fact that it wasn't applied before was relied upon by some
extensions. While it should arguably exist a better API that for such
extensions to use that have a bit more predictable behavior, until that
is so, restore the old semantics.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2891>
Linear sampling can influence the value of surrounding pixels beyond
the scaled framebuffer extents calculated during stage view rendering,
resulting in flickering graphical artifacts due to unaccounted pixel
changes. This is exhibited in xfreerdp and wlfreerdp at 150% display
scaling.
Fix this by ensuring that all pixels that may be affected by linear
scaling is included in the framebuffer redraw clip by padding the actor
redraw clip.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2771>
We have the drm/InfoFrame encoding and our MetaOutputHdrMetadata
encoding. Check that we can correctly convert between each other by
doing a encode/decode and decode/encode roundtrip and then checking for
equality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The existence of the KMS property just means that we can send an
InfoFrame but we also have to make sure the sink actually supports the
metadata type 1 and the selected transfer function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
Allows to prepare KMS updates to set the color space and HDR Static
Metadata on the output.
For some reason we need ALLOW_MODESET on commits which change the HDR
Static Metadata InfoFrame on AMDGPU. There is no technical reason why
one needs to mode set to send an InfoFrame and the driver should just
manage without ALLOW_MODESET. Until this is resolved in the kernel we
just prepare KMS updates which might mode set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The HDR Static Metadata InfoFrame contents are described in CTA-861.3
and the kernel maintains a representation of that in `struct
hdr_metadata_infoframe` in `include/uapi/drm/drm_mode.h`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The Colorspace property informs the display about the colorimetry of the
content. Only variants supported by the sink are exposed in the
property. The strings representing the color spaces are undocumented but
can be found in the `hdmi_colorspaces` list in
`drivers/gpu/drm/drm_connector.c` in the Linux kernel (v 6.2).
The HDR_OUTPUT_METADATA property is a blob with the InfoFrame content.
We have to query support for the different values in the struct from the
EDID/DisplayID ourselfs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
This adds a new 'experimental-hdr' string property to the MonitorManager
which can be changed from looking glass.
Currently when the string equals 'on', HDR (PQ, Rec2020) will be enabled
on all monitors which support it. In the future support for more
transfer functions and color spaces as well as HDR metadata can be
added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The color space and HDR metadata are eventually sent as metadata to the
display. The color space informs the display of the colorimetry of the
frames we produce, the HDR metadata informs the display of the transfer
function and additional mastering display colorimetry and luminance to
guide tone and gamut mapping.
The only color spaces we support right now are the default color space
and Rec bt.2020 which is typically used for HDR content. Other supported
color spaces can be added when needed.
The default color space corresponds to whatever colorimetry the display
has when no further changes are made to the calibration of the display.
The colorimetry is communicated to sources via EDID/DisplayID.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
A Wayland client repeatedly requesting activation of its surface using
the xdg-activation protocol would make mutter constantly update the
cursor.
To avoid needlessly updating the cursor back and forth between busy and
default, add a timeout to delay the update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
When a client (either Wayland or X11) is started, the window activation
will update the cursor to the "busy" cursor.
Mutter will then set the X11 cursor on the X11 root window to match that
so that X11 applications which do not explicitly set a cursor inherit
from that default (busy) cursor.
Updating the X11 cursor too often can hammer the X11 connection and
cause a deadlock with Xwayland.
Reload the X11 cursor in a later handler to avoid that issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
It's a common mistake that links to issues being resolved are not URLs,
and that Part-of was added manually by contributors. Make it clear what
the expectations are regarding this. Formalize on `Fixes:` for fixing
commit messages, and `Closes:` for closing issues while at it. Format
and alias for generating `Fixes:` tags come from mesa.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2847>
We relied on them being valid longer to keep track of used GPUs. If we
don't have the CRTC (or output) we don't have a way to fetch the pointer
to the MetaGpu that drives the associated monitor.
This avoids a crash when trying to fetch said pointer from what would be
the NULL MetaCrtc pointer.
Fixes: 08593ea872 ("onscreen/native: Hold ref to the output and CRTC until detached")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2667
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2887>
Ensure we preserve the fast zero-copy paths in Xwayland fullscreen
windows, instead of maybe rendering the client surface on top of the
frame surface, and providing the latter to the compositor.
To achieve this, additionally synchronize frame state when
recalculating features (e.g. after fullscreen/unfullscreen), and
account for this new condition when creating or destroying frames.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2797>
We no longer need gnome-desktop-3.0, and its dependency on gtk3 is
not desirable. Move to gnome-desktop-4 which actually does not
link to any GTK, conveniently for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
We were relying on gdk_cairo_region() to convert a cairo_region_t
into a path ready to fill/stroke in a cairo_t. This is a small
and detached helper that we can do ourselves, so put it together
with all other region helper functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
Do the few remaining things that GDK is doing for us:
- Open and close the X11 Display
- Set up a GSource on the Display FD to handle events
- Allocate and free the content of XGenericEventCookie,
to "unroll" the few XInput2 events that Mutter still
does handle.
And remove the GdkDisplay we've so long relied on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
From reading the comment in the top of the file, not for the first
time. Keep our own error handler and maintain our own list of
failable x11 sequences in MetaX11Display, so we can move away from
GTK's.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
These are done on the backend X11 connection, so it is unclear
what is the interplay through the borrowed global XSetErrorHandler()
that triggers issues for us here.
Anyways, better to be explicit, and use error traps the MetaBackendX11
style, in coherence with the rest of the things happening in that
display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
This is a X request that may result in errors, so it is better
to have covered by an error trap.
It is thus far not, explicitly at least, which means other less
lenient error traps might not like what happens here. Make the
error trap threeway between backend, x11 and cogl happen less
by chance here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
When an onscreen is "attached" it means it has an active CRTC and output
it interacts with, e.g. listens to configuration changes to update gamma
and privacy screen state.
MetaOutput and MetaCrtc are rather short lived objects meaning they are
disposed of and regenerated each time the compositor reloads monitor
resources, and while MetaOutput are indirectly kept alive due to the
MetaMonitor holding on to them during reloading, the same does not apply
to MetaCrtc, so to avoid trying to disconnect our signals from
disappeared outputs and CRTCs when we dispatch, hold our own references
to these objects.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2665
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2885>
On exit, explicitly detach the onscreens during disposal. This means no
functional changes, but allows for doing more cleanup on detach that
doesn't need to be repeated on disposal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2885>
As implemented in colord 1.4.6, cd_icc_load_handle() has three possible
results:
1. success, taking ownership of the profile;
2. failure because cmsGetProfileContextID returns NULL, *not* taking
ownership of the profile;
3. failure in cd_icc_load(), taking ownership of the profile.
The previous commit ensures that we are not in case 2.
In case 3 where cd_icc_load() fails, ownership was already given to
the colord CdIcc object, so it will be freed when the g_autoptr unrefs
the CdIcc, and we must not free it again: that would be a double-free,
potentially resulting in memory corruption.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2659
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2877>
We want to avoid using too high scales too easily, which started to
happen 2f1dd049bf ("monitor-manager: Rework default scale factor
selection"). Instead of using the closest non-fractional scale, which
effectively is what we'd do, only round upwards if we're closer than
0.25 (25%).
Since there are some wiggle room for scales to make the logical
resolution on the integer pixel grid, make sure to compensate. This
compensation is done by adding an extra 0.2 to scale difference.
For example the following fractional scales will get these corresponding
integer scales:
* 1.25 -> 1.0
* 1.5 -> 1.0
* 1.75 -> 2.0
* 2.0 -> 2.0
* 2.50 -> 2.0
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2880>
Instead of testing headless start using the dummy backend, do so with
the real native backend, and use the drm-mock library instead to emulate
monitors being disconnected at startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
This new filter allows test cases to manipulate what the kernel reports,
e.g. mark connected connectors as disconnected to emulate monitors
connecting and disconnecting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
As part of https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/525
(introduction of transactional KMS API), the logic determining whether a
GPU can have outputs was changed from whether any connectors existed to
whether any connected connectors existed. That effectively meant that we
wouldn't attempt to start at all if there were no monitors connected
while starting up.
This was unintentional, so lets revert back the expected behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
In order to make things more and more asynchronus and to each time we
paint be an isolated event, that can be potentially be applied
individually or together with other updates, make it so that each time
we draw, we use the transient MetaFrameNative (ClutterFrame) instance to
carry a KMS update for us.
For this to work, we also need to restructure how we apply mode sets.
Previously we'd amend the same KMS update each frame during mode set,
then after the last CRTC was composited, we'd apply the update that
contained updates for all CRTC.
Now each CRTC has its own KMS update, and instead we put them in a per
device table, and whenever we finished painting, we'll merge the new
update into any existing one, and then finally once all CRTCs have been
composited, we'll apply an update that contains all the mode sets for all
relevant CRTCs on a device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
MetaRendererViewNative is a MetaRendererView which contains logic
specific to views of the native backend. It will be used by following
commits.
In the future, per-view logic from MetaRendererNative can be moved to
MetaRendererViewNative where it makes more sense to have it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
Add a tiny library that sabotages errors in drmMode*() API calls. This
will be used to artificially trigger arbitrary errors, e.g. cause the
next commit to fail with EBUSY.
The three mocked methods are added as they will be used in a future
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
Instead of using the "discarded" page flip callback when the
"discarding" happened during actual immediate processing, communicate
the same via the KMS update feedback.
The "discarded" page flip callback is instead used only for when a
posted page flip is discarded. In the atomic backend, this only happens
on shutdown, while in the simple backend, this also happens when a
asynchronous retry sequence eventually is abandoned.
This allows further improvements making KMS handling fully async.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
At first it was called seal(), but then updates could be amended after
being posted, given a flag. That flag has been removed, so we can go
back to sealing, since it's once again acts more as a seal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
We test direct client buffer scanout using a TEST_ONLY commit on atomic,
and with various conditions in non-atomic, but if we end up failing to
actually commit despite this, handle the fallout asynchronously. What
this means is that we'll reschedule a new frame immediately.
For this to work, the same scanout buffer needs to be avoided for the
same CRTC. This is done by using the newly added signal on the
CoglScanout object to let the MetaWaylandBuffer object mark the current
buffer as non-working for the onsrceen that it failed on. This allows to
re-try buffers on the same onscreen when new ones are attached.
This queues a full damage, since we consumed the qeued redraw rect. The
redraw rect wasn't lost - it was accumulated to make sure the whole
primary plane was redrawed according to the damage region, whenever we
would end up no longer doing direct scanout, but this accumulation only
works when we're not intentionally stopping to scanout. For now, lets
just damage the whole view, it's just an graceful fallback in response
to an unexpected error anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
Stage view users can schedule updates at ease with
clutter_stage_view_schedule_update(), but couldn't schedule update
"now". Make that easy too by adding
clutter_stage_view_schedule_update_now().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we call schedule(), which will schedule an update some time in the
future, and then schedule_now(), we should reschedule the frame clock to
update immediately, and not some time in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we get a "ready" page flip feedback, it means the page flip was
symbolic, i.e. not real, e.g. as a result of an update that didn't
change the state of the primary plane. Warn if there is a "next fb"
meaning we expected to have a new buffer that we flipped to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This will later be emitted when a scanout failed, e.g. by the not-test commit
failing for some reason, or drmModePageFlip() failing even if the
pre-conditions for scanout in the simple KMS backend passed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This is intended to be used only for plane assignment, and CRTC like
changes, so that one can e.g. change a cursor plane on a pending update
that changes the primary plane, before it has been committed to KMS.
The kms-updates test overrides the get-state function MetaKmsCrtc. This
is needd to not have the update mechanism not clamp the gamma size to 0,
as vkms reports the gamma length 0. By pretending it's 3, we can test a
simple and small gamma lut is merged correctly when merging updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This looks like a bug: There's no reason why windows which advertise
min-size hints that are exactly the size of the workarea should not be
allowed to maximize, so change the checks here to allow for that.
The commit message of 7f64d6b9 also makes the point that this was not
intended, as it says "larger than".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2873>
Surfaces belonging to a screen-casted window should always be considered
visible even if they are not visible on any stage view - be it because
they are on a different workspace, minimized or occluded.
Doing this in an optimal fashion is highly complex right now -
interdependent with (and somewhat similar to) ClutterClones. Thus treat
stream-casted surfaces similar to those with clones, with the small
difference that even a fully invisible surface still gets a primary view
- the fastest one. This ensures that clients never refresh too slow for a
screen-cast, at the cost of sometimes refreshing too fast.
The later only happens on certain multi-monitor setups and should thus be
acceptable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
There is an increasing number of cases where we want the frame callback
logic to run for a stage-view and the complexity needed to avoid these,
combined with the likelyhood of bugs, arguably does not justify the
benefit any more.
Thus unconditionally schedule updates for all stage-views when frame
callbacks are requested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
Screen-casted windows need to be considered visible in various situations
but existing APIs such as `clutter_actor_is_effectively_on_stage_view()`
don't do so. Add new API that allows checking if a surface belongs to a
screen-casted window for the respective cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
The introduction of the META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED
flag threw off some checks around keyboard-driven resize. This
was partly because there were some == checks that did not account
for that flag maybe being enabled, but also the handling
of META_GRAB_OP_KEYBOARD_RESIZING_UNKNOWN into a definite
resize direction was maybe unsetting that flag. Fix both things
at the same time.
Fixes: 2d8fa26c8e ("core: Pass "frame action" grab operations as an "unconstrained" grab op")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2629
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2871>
From the scale factors available to it, Mutter will now try to select
the scale factor that makes the UI's size as close as possible to the
size it would be, w/o scaling, on a display at 135 PPI (for mobile
displays) or at 110 PPI (for stationary displays)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2653>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
The pointer to the manager, the peer name and the ID are things that are
always metadata related to a session, so make them properties on the
interface instead of duplicating them. The implementations still need to
keep track of them, but their existance is shared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This class is intended to be used as a base class for D-bus interface
implementations that deal with "session" objects, i.e. a D-Bus object
representing a certain session of some kind, e.g. a screen cast session.
It handles things such as hooking up to the D-Bus client watcher,
generates IDs, handles shutdown procedures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
It's currently not set by anything, and will only be used by
non-abstract implementations of a future D-Bus interface session
manager. When interface implementations gets ported to this new type,
their MetaDbusSession implementations will set this vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This means the MetaDbusSession interface takes a more active role
instead of being something that more or less sends signals to the
interface implementor. This will allow better control when using
MetaDbusSession to manage these sessions, instead of their non-abstract
variants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
Allows for creating LUTs at some fixed size which maintains enough
precision for concatenating or otherwise manipulating the LUT without
having to care about the precision of the hardware.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
If the device supports the atomic API the property based API is used to
write gamma updates and the legacy API is used in the non-atomic case.
The current state is read from the legacy API always though which can be
different from the property API. This commit always uses the correct API
to update the state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
This API will be used by GNOME Shell to handle X11 events
in the relevant places, as a substitute to gdk_window_add_filter().
It is ATM still a bit ironic, since the Mutter X11 event handler
is itself a GdkFilterFunc, but it may move away from that eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2779>
With detach meaning having the onscreen stop listening on configuration
changes on the corresponding backing mode setting objects. We need to do
this as there is a time between rebuilding the views, and that the new
mode sets are called, where the old onscreen is kept alive, but the
stage view is gone. At this point in time, if privacy screen or gamma
configuration changes, e.g. by the night light temperature changing, the
onscreen would attempt to schedule an update on the now gone stage view.
This commit also renames the "keep onscreen alive" to "detached
onscreens" to more clearly communicate that it's detached onscreens from
their corresponding mode setting objects.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2621
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2863>
Currently, when the rewrite option is passed, the script does not give
much choice on whether changes should be applied or not, it just does
"git comit -a --amend". However, uncrustify is not always entirely
right about the proposed style changes, or it might suggest changes
in distant/unrelated bits in the changed functions. Thus the developer
needs to be given some option.
Change the approach of the --rewrite option, so that it first does
"git add -p", so that individual changes may be decided upon, and
after all the chunks were gone through, uses "git commit --squash"
so that the changes may be reviewed before manually doing
"git rebase --autosquash" to merge the changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2829>
For the coordinates of pointers or stylii, we translate the ones we store
using the viewport matrix already. For touch events otoh, we store coords
untranslated and translate them later only for event emission.
Let's be consistent here and store the coordinates of touch events
translated, just like we do for pointer events.
This fixes touch window dragging on rotated monitors. MetaWindowDrag calls
clutter_seat_query_state(), which uses those stored coordinates. So in case
of a touch sequence the coords returned by query_state() would be
untranslated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2859>
In the case where we early-out from meta_window_drag_begin(), the
effective_drag_window might not be set yet. In this case, we might finalize
the object before effective_drag_window is set, leading to a NULL pointer
when accessing window->display in hide_tile_preview().
To avoid that crash, add a check whether the window is set already. If no
window is set, we can just skip hiding the preview anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2858>
This fixes an issue when GLFW tries to change the display resolution
while fullscreen where the application window size doesn't get updated
according to the emulated resolution.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2725>
Streams are generally recoverable by the client and errors may happen
e.g. on negotiation failures. Right now we close the stream and
corresponding session, which is neither necessary nor expected by
clients.
Just disable the stream instead and let clients handle things as they
seem fit. This allows clients to e.g. try several Gstreamer pipelines
with limited caps on a single stream.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2850>
Doing it in dispose means the backend is actively tearing down itself,
meaning various components might or might not be there, depending on how
the tearing down is implemented. Make things a bit more robust by doing
any work that might rely on the backend being there before shutdown is
done in response to the 'prepare-shutdown' signal being emitted by the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2853>
Meson enforces a separate build dir, so we no longer have to care
about build artifects in the source tree. Same applies for all
the generated crap autotools like to spread around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2840>
Reading upon the history of this code branch (commits 6891ce95dc
and 7a4c808e43 are most relevant), it seems this code is meant to
synchronize Mutter focus state taking the Xserver state as true.
That is, if Mutter tried to change the focus but something truncated
that action, Mutter focus will be changed to be in sync with the
Xserver again.
This sounds backwards in a Wayland session. Mutter focus should be
the canonical source, and not second-guessed from the current Xserver
focus window. These race conditions might still apply between X11
clients, so make these paths only apply in that case.
An example of this breaking can be reproduced with a Spotify and
Firefox window, moving the focus from the first to the second by
going to the GNOME Shell overview in between, and clicking the
Firefox window from there. The Firefox window will be raised, but
refuse to take focus.
It's unclear what made this an issue recently, perhaps commit
0e6395d932 since the now possibly ignored XI_FocusIn/Out events
affect this accounting of the Xserver focused window. Anyhow it
sounds better to ignore these paths for Wayland/native altogether.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2841>
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>
This protocol is intended to let special clients create transient-for
relationships between X11 and Wayland windows. The client that needs
this is xdg-desktop-portal-gnome, which will create e.g. file chooser
Wayland dialogs that should be mapped on top of X11 windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
When modal dialogs are attached, and we set the parent/transient-for
after setting the modal type, the attachedness isn't updated. This is
(apparently) not the case for X11 windows, as they go through a
unmanage/manage dance avoiding the issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The script is a list of newline separated command lines that are sent to
the client one by one as if one would have used e.g.
meta_test_client_do().
It doesn't have error handling as it's expected to be used from tests,
and handling errors in tests that never expects to handle errors is
cumbersome.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The service channel D-Bus interface aims to be a "back door" for
services that needs special casing in Mutter, e.g. have custom private
protocols only meant to be used by that particular service.
There are currently no special casing implemented; only the basic
service channel infrastructure is added. There is a single method on the
interface, that is meant to eventually be used by
xdg-desktop-portal-gnome to open a Wayland connection with a private
protocol needed for the portal backend's rather special window
management needs.
The service channel Wayland client works by allowing one instance of
each "type", where each time needs to be defined to work in parallel. If
a new service client connects, the old one will be disconnected.
MetaWaylandClient's are used to manage the service clients, and are
assigned the service client type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
One can add a wl_global filter to a wl_display instance, which can be
used to decide what clients should see what globals. This has so far
been used to limit a Xwayland specific protocol extension to only
Xwayland. In order to expand the logic about what globals are filtered
to what clients, introduce a filter manager and port the Xwayland
specific protocol filter to this new manager.
Tests are added, using a new dummy protocol, to ensure that filtering is
working as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
It only tests indirect clients, i.e. not the subprocess part, so far,
but tests explicitly terminating by destroying the MetaWaylandClient
object, as well as the client self terminating and the signal being
emitted.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
This API creates a "client" then later sets up a wl_client and returns a
file descriptor some Wayland client can connect to. It's meant to be
used as a method other than WAYLAND_SOCKET and process launching, e.g.
passing a file descriptor via a D-Bus API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
There will be two kind of client instances, lets move fields that are
only relevant to the current way of operation in an anonymous struct to
keep things a bit separate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
This patch unfortunately results in situations where it is intended
that the focus change happens while a grab is present (e.g. Alt+tab
popup), resulting in confused focus state.
This commit is reverted in order to try a similar approach at a
different level.
This reverts commit 7531669b4f.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
We used it to retrieve a Display, and convert between Atoms and
strings. We can just use the MetaX11Display's Display (It's the
same than GDK's anyways) and use XInternAtom/XGetAtomName for
these conversions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2836>
We didn't always set an implementation, when the foreign toplevel wasn't
found, and when the importer tried to set the parent-child relationship,
the implementation was missing and we'd crash in wl_closure_invoke() in
libwayland-server.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2834>
Windows that are decorated may get configure requests before
the frames client created a corresponding frame window and Mutter
reparented the window.
Since the configure request results in the buffer size being
used to update the window size and the window does not have a
buffer yet, these requests could mistakenly result in the client
window being given a minimal size.
In these situations, do not use the buffer size but the given
size. The window still has to undergo frame creation and
reparenting before being shown for the first time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2588
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2605
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2808>
This used to be implicitly done by popups using a META_GRAB_OP_WAYLAND_POPUP
MetaDisplay grab. Since commit a8cd488c6f Wayland popups no longer do that,
so the keyboard focus was simply unset if a popup was destroyed while having
the keyboard focus.
Trigger a full input focus sync, so the correct MetaWaylandKeyboard focus
surface is looked up from the focused MetaWindow.
Fixes: a8cd488c6f - wayland: Drop redundant MetaDisplay grab op
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2833>
On one hand, this used to be handled generically in all the paths that
changed the MetaWaylandPointer focus surface, induced by user interaction
or not.
On the other hand, just listening for crossing events is not sufficient
since those also do happen programmatically. We must only listen to
crossing events that have a physical source device, meaning this was
created through user interaction.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/888
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
For motion-induced crossing events, this will be the device that generated
the motion. For code-induced crossing events (e.g. grabs or actors disappearing)
this will be none.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
On Wayland sessions, this handling is unnecessary and even prone
to confusion (e.g. crossing serials are only ignored in X11-exclusive
paths, so this handling competes directly with that in MetaWaylandPointer).
Avoid it entirely there, so MetaWaylandPointer can figure out
sloppy/mouse mode focus for all Wayland/Xwayland surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
In GTK this is only used for GTK clipboard/DnD selections, and
finding out whether there is a compositing manager in charge.
In Mutter, we manage our own clipboard/DnD selections, and don't
perform any rendering through GTK in the Mutter process.
So there's no special reason to let these events go through GTK,
and (related to xwayland-on-demand?) there may be race conditions
in the handling of the second feature.
There's a chance this race condition may be in Mutter, but it
does not sound worth to chase this race condition when we can
let GTK ignore these events. And it does not make sense to "fix"
gtk3 for this Mutter-only condition, when we intend to eventually
avoid it.
So, take the easy path and ignore these events.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2617
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2831>
Marking the the depth/stencil as discarded before swapping buffers for
the screen signals the GPU that we don't need to keep them around for
the future.
This helps performance by reducing memory bandwidth usage in some GPUs
which may optimize to not write those buffers back to memory at all
after rendering, when they would just be cleared right after that
anyway.
It is not necessary to mark buffers as discarded after swapping buffers.
This should have no effect according to the spec (since that is going to
be followed by new rendering commands which make the buffer valid again)
and removing that has shown no impact in performance tests.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2091>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
New add_monitor command for adding secondary monitors. Support setting
the workspaces-only-on-primary preference.
The stacking test tests the focus and stacking for multiple monitors
with workspaces-only-on-primary=true. The default_focus changes
previously broke this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
The X-GNOME-Bugzilla-* entries in the desktop file were for use by
bug-buddy, a GNOME 2 technology that's been gone for over a decade.
These entries are obsolete and the desktop file can be removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2621>
bind_output() creates output interface resource, but does not
set implementation for it when wayland_output->monitor is NULL.
However, when the wayland library is running wl_closure_invoke(),
it expects the implementation to be non-NULL, and if not, it just
segfaults mutter by NULL pointer dereference.
This commit tries to address this issue by setting an implementation
when wayland_output->monitor is NULL. This could help prevent crash
when resuming from suspend or hotplugging displays.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2570
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2827>
The order of dependencies influences the order of -L arguments to gcc/ld,
we should put our private library first, so that introspection prefers
looking up libraries in private paths than public ones.
This could bring problems in API updates of the libmutter-test library,
since introspection would still prefer the old installed one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2826>
ClutterActions now no longer receive their events via
clutter_actor_event(), instead they get special treatment by the stage
now. Make the MetaGestureTracker work with this and stop emitting events
directly to Clutter via clutter_actor_event(), but instead let them get
through to Clutter (but still not to Wayland).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Since the last commit, ClutterStage automatically cancels an implicit
grab (including all its ClutterActions) when a conflicting ClutterGrab
appears.
This means we no longer have to look out for GRAB_NOTIFY crossings in
ClutterGestureAction and can instead depend on the sequence_cancelled()
vfunc for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
A ClutterGrab takes precedence over implicit grabs, so when one happens,
let's check which part of the implicit grab tree is inside the new
ClutterGrab. Cancel and remove the parts which aren't, and if nothing
is in there anymore, cancel the whole implicit grab.
Emitting crossing events correctly here is getting quite tricky:
- When the implicit grab didn't get cancelled by the ClutterGrab, we
simply want to emit all GRAB_NOTIFY crossings to the implicit grab, as
we do with all other crossings.
- When the implicit grab did get cancelled and the new ClutterGrab wants
to emit ENTER crossings, we want those to be emitted to the actual
targets, so cancel the implicit grab before emission.
- In the last case where the implicit grab did get cancelled and the new
ClutterGrab wants to emit LEAVE crossings, those should be emitted to
the implicit grab again, so we cancel the grab only after the emission
of those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Now that we have two kinds of grabs, the intricacies of event delivery
got slightly more complicated. So this seems like a good point to
introduce a new GRABS debug flag that gives an overview of which grabs
are currently in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
We're almost there, everything is in place to notify ClutterActions
about a sequence getting pulled away under its feet.
The only thing that's missing is the actual notification to actions now,
so let's do that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Another baby step just like the last commit: This commit takes care of
the opposite case: An action handling a sequence event stops further
emission of events to actors.
Since sequences remain around for longer than the context of just a
single event, it makes sense to provide a way to "claim" those sequences
even when outside of event handling context, so introduce API for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
As soon as any event of a sequence is handles/stopped during emission,
all actors and actions that would have gotten to see it afterwards have
a big problem: If that event was a TOUCH_END event, the actor/action is
forever going to think that this touch is still active.
For ClutterActions, we're going to handle this by introducing a way to
send them a notification when stuff like this happens.
As a baby step towards all that, make event emission exclusive to actors
as soon as any actor stopped an event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
We'll soon introduce a new gesture tracking framework which heavily
depends on ClutterActions seeing all events of a sequence. For this to
work, a larger change to event delivery is needed: Implicit grabbing of
all events for button and touch press->motion->release sequences to
ensure ClutterActions continue receiving events for the whole sequence.
This commit takes care of that: At the start of an event sequence we
collect all the event-handling actors and actions to a GArray that lives
in the PointerDeviceEntry, and then deliver all events belonging to
that sequence to the same actors/actions until the sequence ends.
To avoid events getting pulled from under our feet when mutters event
filter returns CLUTTER_EVENT_STOP, this also introduces private API
(maybe_lost_implicit_grab()) on ClutterStage so that we can't end up
with stale sequences.
Note that this also slightly changes behavior when it comes to event
delivery to actions: Because we now store actions separated from their
actors, any action returning CLUTTER_EVENT_STOP now stops event
propagation immediately. That was different before, where we'd emit
events to all actions of the actor and only then stop propagation.
Note that this isn't handling ClutterGrabs correctly right now,
this will be a little tricky, so we'll take care of that in a future
commit.
To handle actors getting destroyed or unmapped during a grab, listen to
notify::grab on the deepmost actor in the implicit grab tree. This gives
us a notification when any actor inside the tree goes unmapped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
A fairly small refactor, move the emission of events to actions from
clutter_actor_event() to stage level.
We do this because in the future we'll need to know on stage level
whether events were handled by an actor or by an action.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
_clutter_actor_handle_event() currently allocates a new GPtrArray on the
heap for every single event emission, let's avoid this by keeping an
array around in ClutterStage and reusing that.
This is moving the last few bits of event emission into ClutterStage,
which will be useful when we introduce implicit grabbing in subsequent
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
There's no real reason to keep those events exclusive to the stage, some
actors or actions might want to get notified about proximity events too,
so propagate them like any other event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Right now and due to loads of refactorings lately, the event emission
paths are a bit cluttered (ha ha ha) around in Clutter. For example the
event target actor gets set in clutter-main.c, but event emission is
actually managed by ClutterStage these days.
Since we'll introduce implicit grabbing of touch/button-press sequences
soon, let's shuffle things around a bit to make that easier:
Move event emission to the stage, it now gets a ClutterEvent without any
extra context like the target actor from clutter-main. The stage then
looks up the target actor itself and emits the event to the appropriate
actors in the scenegraph. A special path is introduced for emitting
crossing events, because here the event-receiving actors don't follow
the "capture+bubble from pointer actor to grab actor" rule.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Crossing events should never be stopped during event emission. We
already have a check that enforces this in clutter_actor_event(), but
ClutterActions still sometimes try to stop crossing events from
propagating.
Improve that situation and return CLUTTER_EVENT_PROPAGATE when handling
crossings in ClutterActions, too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
The previous logic tried to keep the position of the top left corner of
the window relative to the top left corner of the monitor. This allowed
the window to move out of the target monitor. This change keeps the
proportions of the distance between the window and the monitor borders
instead if possible. Otherwise it keeps the relative position of the
center of the window clamped to [0,1] to make sure the window lands on
the right output.
This also slightly changes what monitor is considered to be on: the
monitor which contains the center of the window and, if the center is on
no monitor, the monitor wich overlaps the most with the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2591>
This partly reverts f9857cb8 but leaves an exception for cursor
surfaces in place, as some apps/toolkits will likely not get updated
anytime soon to ensure cursor themes comply with the Wayland spec.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2815>
So we can remove the additional `next_fb` and `current_fb` pointers from
`MetaOnscreenNativeSecondaryGpuState`.
Some non-scanout buffers also need to be held in the case of GL blitting
which completes in the background. Those are referenced from the scanout
buffers themselves to ensure the source buffers live just as long.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2087>
There's still a possibility that some events remain within the
`ClutterMainContext` when it's being unref-ed for the last time (as seen
on asan logs). Make sure they get freed by using
`g_async_queue_new_full()` and specifying the appropriate destroy
function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2817>
Calculating a timestamp from the past distorts the dispatch lateness
calculation, leading to an inflated max_render_time, which again
increases the likelyhood of next_update_time being in the past.
Fixes 99850f4645
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2819>
As with GAMMA_LUT, track whether privacy screen state has been pushed to
KMS in the onscreen. This leaves MetaOutput and MetaCrtc to be about
configuration, and not application.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
As with CRTC GAMMA_LUT, we're moving towards making the entity managing
KMS updates aware if there are any changes to be made, and whether KMS
updates are actually needed or not, and for privacy screen changes, this
means we need to communicate whether the privacy screen state is valid
or not. This allows the caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We're moving towards making the entity managing KMS updates aware if
there are any changes to be made, and whether KMS updates are actually
needed or not, and for GAMMA_LUT changes, this means we need to
communicate whether the GAMMA_LUT state is valid or not. This allows the
caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We may fall through these paths on --nested too, resulting in us poking the
wrong internals from the wrong MetaRenderer subclass. Fixes launching of
clients using wl_drm in --nested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2818>
Running each stacking test as a separate installed-test is analogous to
what was done for build-time tests in c6d1cf4a (!442) and should make it
easier to track regressions, by being able to see whether a regression
is specific to one .metatest script or applies to more than one.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2773>
While completely untested, at least this makes it work "in theory"
again. Before it'd listen to signals on the stage, but have an incorrect
type signature to handle the test paint procedures, meaning it'd
probably crash or cause memory corruptions.
What was needed was a signal which in the callback the test could call
some cogl functions to paint on the framebuffer. While there is no such
signal on the stage, and the ClutterActor::paint signal (which they
probably used in the past) is long gone, lets add a "test actor" that is
just a wrapper that adds that paint signal with a paint context.
The tests that need it are changed to add this actor to the stage, and
to listen to the paint signal on the actor instead of incorrectly
listening on stage signals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2807>
At least indirectly, this is set as object qdata while the
window drag is ongoing, and reset/reconstructed if needed.
Consequently, this edge data does not need to be stored in
the MetaDisplay struct anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Even though the data is still stored in the display, add a "high
level" meta_window_drag_update_edges() call, so that the cached
edges may be updated while a window drag operation is ongoing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This helper object (and the whole window drag operation) will be
requested to the compositor instead of created directly, and only
one of those can exist at a time, so the compositor will also
safeguard that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since SSD X11 windows require synchronization between frame and client
windows on resizes, updates do not always happen immediately but in
control of external factors (i.e. when both windows become to have
a coherent size).
This method will be used to update the window position between
resize/sync operations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This compositor-side object will single-handedly drive a window
drag operation. Currently, this largely copies meta_display_begin_grab_op
and meta_display_end_grab_op, except grabbing is done through a
ClutterGrab instead of direct meta_backend_grab_device() calls. This
also means that the switch from passive to active keyboard grabs is
handled differently.
Currently, this object is dormant. It requires moving more code from
other places to become a fully functional replacement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
We only allow partial grabs in the case of a keyboard-type MetaGrabOp
happening while the pointer cannot be grabbed. In that case, it's not
a big stretch to unconditionally ungrab the pointer device at the time
of undoing the grab, as it will be always ineffective (not even implicit
grabs on frame windows can happen now, inside Mutter).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary, since the SSD frames are no longer
part of Mutter process, so it is not the MetaX11Display connection
which holds the implicit grab when a mouse button is pressed over
a window frame (say, to start a drag).
As the SSD frames client communicates the same way than CSD windows
for window operations, it is also expected to undo its implicit
grab before requesting a window move/resize operation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The final effect of this boolean can now be expressed through the
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag to MetaGrabOp. Use that
in the relevant places, and drop the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Now that it is called from a single place, there's a few arguments
that are unnecessary:
- button and modifiers are unused
- already_grabbed was originally added to handle grab transitions between
window menus (GtkMenus, back in the day) with display grabs. It's no
longer necessary now
- frame_action can be passed through the META_GRAB_OP_WINDOW_FLAG UNCONSTRAINED
flag
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Leave meta_window_begin_grab_op() as the only public API to initiate
a display grab. There's no longer grab operations that don't attain
windows, and ending these grabs usually happen through user interaction
when the right circumstances happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
There is no longer reason to call meta_display_begin_grab_op() except
for window grab operations, and meta_window_begin_grab_op() is a
perfectly fine entry point for all window grab operations.
Move away from meta_display_begin_grab_op().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Currently, it is thought out to be called with META_GRAB_OP_KEYBOARD*
grab op parameters. Make it more generic so it can also be called for
pointer operations (avoiding pointer warping in that situation).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Unlike the comment suggests, this piece of event handling manages
the ungrabbing of a window on button press in the following 2
conditions:
- If a keyboard grab operation was triggered, the window does
additionally follow the pointer, and first button press ends
the grab.
- If a button-press grab is ongoing on the window, but more buttons
are pressed.
We can simplify this to just happen every time a button press event
is received while a window grab op is ongoing. The only case where
this might diverge a bit is same button presses from different
pointer devices, and it's not a big stretch to also undo the grab
in that situation.
This also happens to make the "button" argument in
meta_display_begin_grab_op() completely unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The frame_action boolean is only used by constraints.c code, in order to
determine whether a moving window should be able to move past the top
bar or not.
We can avoid the special casing by passing this information as a
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag passed with the grab op.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary to prevent the bits we wanted to be
prevented by the presence of this grab. We can drop this, and
let it work through the MetaWaylandPointerGrab interface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The whole reason for META_GRAB_OP_WAYLAND_POPUP to exist is to
avoid windows from being activatable/movable/resizable when a
grabbing xdg_popup is active.
Use the meta_display_is_grabbed() method which can tell this
from existing MetaWaylandCompositor grabs, so that this remains
true after dropping META_GRAB_OP_WAYLAND_POPUP.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Make this public API check just return a boolean about whether
there is an existing grab, instead of exposing MetaGrabOp.
It is desirable to avoid exposing details like
META_GRAB_OP_WAYLAND_POPUP, so that MetaDisplay and wayland
grabs can port to ClutterGrab at their own pace, but also
this further information is unused.
This is likely to be temporary API anyways, after both
MetaDisplay and wayland grabs port to Clutter, it will be
possible to check the ClutterStage for all of them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Rewrite this codepath so it handles the grab ops that it cares
about, and ignores the rest. This way the code works despite
possible future modifications to MetaGrabOp (e.g.
META_GRAB_OP_WAYLAND_POPUP removal).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This piece of event handling only applies on windows receiving events while
the display is ungrabbed (i.e. for raising it, or beginning a move/resize
operation).
Move the checks on the current grab operation outside of window.c and into
events.c, so all checks about the current grab operation move closer to the
main event handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
When sysprof-4 and libsysprof-capture-4 are installed into different
prefixes, such as with Nix package manager, the D-Bus interfaces
are likely not discoverable from the latter package.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2572>
Currently subschemas in org.gnome.mutter are marked as child schemas,
but subschemas in org.gnome.mutter.wayland are not. There's no harm
with that, it's just nice to be consistent, and having schemas show
up in `gsettings list-children` is a nice touch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2809>
The GQueue node for transactions are inlined in the transaction struct,
meaning we should never let the GQueue API free the node itself, as that
actuall frees the transaction itself.
We did this during tear down if there were left-over transactions,
meaning we ended up with use-after-free issues after having popped
transactions from the queue.
Fix this by just popping the link itself, which won't attempt to free
it. It is effectively freed when freeing the transaction itself so we
won't leak any memory.
Fixes: 56260e3e07
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2805>
During grabs, it is expected that the X11 focus does not correspond
to the display's focus window, as focus should be on the stage's
XWindow instead.
This still messes up the keyboard focus even after we stopped moving
the X11 focus, because we end up with a presumed X11 focus window
of None, and as a result the stage is considered unfocused.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2776>
When the pointer crosses monitors, we account for a single motion event
resulting in the pointer moving across more than 2 monitors, in order
to correctly account each monitor scale and the distance traversed
across each monitor in the resulting relative motion vector.
However, memory on the direction is kept short, each iteration to
find the target view just remembers the direction it came from. This
brings a pathological case with 4 monitors with the same resolution
in a 2x2 grid, and a motion vector that crosses monitors at the
intersection of all 4 in a perfect diagonal. (Say, monitors are
all 1920x1080 and pointer moves from 1920,1080 to 1919,1079).
In that case, the intersection point at the crossing between 4
monitors (say, 1920,1080) will be considered to intersect with 2
edges of each view. Since there is always at least 2 directions to
try, the loop will always find the direction other than the one
it came from, and as a result endlessly jump across all 4 possible
choices.
In order to fix this, consider only the global v/h directions,
we already know if the pointer moves left/right or up/down, so
only consider those directions to jump across monitors.
For the case at hand, this will result in three monitors visited,
(either bottomright/bottomleft/topleft, or bottomright/topright/topleft)
with a total distance of 0,0 in the middle one, effectively
resulting in a correct diagonal motion.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2598
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Refactor code so that variables don't depend the on motion line
content, but the other way around. This makes it clearer what each
vector means.
This has no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Some tests expect warnings to be logged, and handle that using
g_test_expect_message(). However, if debug topics are enabled, this
causes g_logv() to expect expected messages to also contain entries with
the debug level 'message' or higher to be listed in the expected message
list. Since meta_topic() always logged using g_message(), enabling debug
topics caused any test that used g_test_expect_message() and had debug
logging somewhere along the code path to fail.
Fix this by changing the log level of meta_topic() to 'debug' if we're
in a test. This doesn't mean they won't be visible, they still will
since debug log entries are printed by default during testing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2800>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
It was missing a cairo_region_t. This also needs adapting the test case,
since prior to this, we didn't actually bump the paint counter when
painting.
When a scanout test isn't waiting to go from compositing to scanout, but
from scanout to compositing, we should not early out when we actually
composited, since that's what we're expecting to see.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
Fix a silly copy-paste mistake. Since `GObject` is the parent class,
chaining up to `dispose()` from within your `finalize()`
implementation just leads to a little memory leak and nothing worse.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2799>
We might end up with a NULL opaque_region here in some circumstances
(client deleted _NET_WM_OPAQUE_REGION, or passed invalid data or a
region with 0 rectangles), account for that when freeing the variable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
These frames client will use a visual with alpha information, and
report the opaque frame shapes through the _NET_WM_OPAQUE_REGION
window property. We can use this information in the Mutter side
for accurate opaque shapes, despite X11 windows with frames now
being seen as possibly transparent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
Since the windows created by the frames client will have a RGBA visual, we
no longer can perform simple tests about whether the window is opaque. For
that, we will need to additionally know whether the client-side window has
a visual with an alpha channel.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
This does nothing wrt making race conditions shorter in the
X11 window manager switch case, but is a nice to have in order
to ensure an orderly shutdown of X11 stuff.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2796>
Restarting a X11 window manager is a busy process, trying to leniently
quit the main loop may result in old and new instances each having a
frames client up and running, and the window handover to be less clean
than it should due to the frames client that is about to exit still
being able to react to the batch of events resulting from the window
manager switch that is already undergoing.
In order to avoid extending this transition period any long, make
the frames client exit() the process immediately when SIGTERM is
gotten from the parent process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2796>
Writing to fields (in this case the MetaColorDevice::pending_state) in
response to an asynchronous operation that was cancelled means we'll
write to an arbitrary memory location, potentially causing segmentation
faults or memory corruption.
Avoid these segfaults or memory corruption by only updating state if we
weren't cancelled. Also avoid trying to dereference the device pointer
if we're cancelled.
The memory corruption due to this has been causing test flakyness in the
monitor unit tests due, which should now hopefully be fixed.
Fixes: 19837796fe
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2794>
I hit this rare error running the "x11" test from the suite locally:
(mutter:194027): Gdk-ERROR **: 18:21:52.525: The program 'mutter' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 663 error_code 9 request_code 143 (DAMAGE) minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The only call from the Damage extension in use by Mutter that could
return BadDrawable is XDamageCreate(), and it's likely to be this
call. Wrap this X11 in an error trap, in order to catch possible
failures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2793>
Flushing the input thread might implicitly iterate the mainloop, and thus
update the stage while still inside the clutter_test_flush_input() call.
This means the stage update has already happened when we call
wait_stage_updated(), and that's why we call clutter_stage_schedule_update()
there currently.
This clutter_stage_schedule_update() call is not necessary though, instead
we can flush the input thread from inside wait_stage_updated() after
setting was_updated to FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2792>
If the window is unmapped or otherwise unmanaged while still existing,
we would fail to let the frames client follow up in destroying the
frame for the window.
Delete the _MUTTER_NEEDS_FRAME property, so that the frames client
can react to meta_window_destroy_frame(), this avoids stale invisible
frame windows for clients that simply unmap windows to reuse them
later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2791>
Recent versions of Xwayland can allow or disallow X11 clients from
different endianess to connect.
Add a setting to configure this feature from mutter, who spawns
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785>
This define was dropped by commit 0e8aaebc00 (xwayland: Make
XSetIOErrorExitHandler() mandatory), but some #ifdef checks were
brought back by commit 36f30341ac (wayland: Add a prepare-shutdown
signal).
Since there's no define anymore in config.h, these pieces of code
were unintentionally disabled, and a meta_get_display() call be
also left over. Remove the ifdefs and update the code to build
again.
Fixes: 36f30341ac - wayland: Add a prepare-shutdown signal
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2786>
This XChangeWindowAttributes call was never surrounded by an error trap
and was not really expected to fail with BadWindow since the frame window
would be owned by Mutter itself.
This however is no longer true, and we might be getting a BadWindow from
the frame window given the right timing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
Commit 4e0ffba5c attempted to fix initialization of keyboard a11y,
but mousekeys do attempt to create a virtual input device at a
time that it is too early to try to create one.
Defer this operation until keyboard devices are added, so that
we are ensured to already have the seat input thread set up.
Fixes: 4e0ffba5c - backends/native: Initialize keyboard a11y on startup
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2778>
Quoting Carlos:
The META_PRIORITY_EVENTS ± 1 happening below are in order to set these idles
and timeouts in a priority that is relative to the literal GDK event priority,
making those diverge is a likely way to sneakily break things.
But that's unlikely to happen, and decoupling mutter from GTK further
should make it moot, so perhaps it's alright after all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Clutter has an API to get the text direction but used to depend
on gtk3's translation domain. In order to avoid broken i18n
in case gtk3 is not installed, move the transtalable string to
clutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Now that dynamic max render time uses a new algorithm and takes dispatch
lateness into account, this seems worth a shot. We'll see how it works
out in the wild.
The net result compared to before these changes is still slightly higher
(by ~0.5 ms) minimum latency for me, as measured by
weston-presentation-shm. It should be less vulnerable to frame drops
though.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2500>
Store only two values per kind of duration: The short term and long term
maximum.
The short term maximum is updated in each frame clock dispatch. The long
term maximum is updated at most once per second: If the short term
maximum is higher, the long term maximum is updated to match it.
Otherwise, a fraction of the delta between the two maxima is subtracted
from the long term maximum.
Compared to the previous algorithm:
* The calculcations are simpler.
* The calculated max render time has a slow exponential drop-off (by at
most a few milliseconds every second) instead of potentially abruptly
dropping after as few as 16 frames.
This should fix https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4830
since the short term maximum should always include a sample from the
clock's second tick.
v2:
* Use divisor 2 instead of 4.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2500>
Dispatch lateness is the difference between when we wanted frame clock
dispatch to run and when it actually started running. This can be up to
1ms even under normal circumstances due to process scheduling
granularity, or even higher under load.
This keeps track of dispatch lateness of the last 16 frame clock
dispatches, and incorporates the maximum into the dynamic render time
estimate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2500>
There are two tests; one checks that clearing with a color that cannot
be represented using 8 bits per channel doesn't loose precision when
painted, then read back using glReadPixels(). Would the texture backing
store have 8 bits per channel instead of 10, we'd get a different value
back.
The other test checks that painting from one fbo to another also doesn't
loose that precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
OpenGL requires more hand holding in the driver regarding what pixel
memory layouts can be written when calling glReadPixels(), compared to
GLES2. Lets move the details of this logic to the corresponding
backends, so in the future, the GLES2 backend can be adapted to handle
more formats, without placing that logic in the generic layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
COGL_PIXEL_FORMAT_ABGR_2101010 is defined to mean the 2 A bits are
placed in a 32 bit unsigned integer on the bits with highest
significance, followed by B on the following 10 bits, and so on, until R
on the 10 least significant bits.
UNSIGNED_INT_2_10_10_10_REV_EXT is defined to represent color channels
as
```
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
-------------------------------------------------------------------------------------
| a | b | g | r |
-------------------------------------------------------------------------------------
```
As can be seen, this matches COGL_PIXEL_FORMAT_ABGR_2101010, meaning
that's the format we can directly read and write.
In Cogl, when finding the GL formats, we get the tuple with the GL
format given the format we pass, but we also get returned "required
format" (CoglPixelFormat). This required format represents the format
that is required when reading actual pixels from GLES. In GLES, the
above mentioned format is the only one supported by the
EXT_texture_type_2_10_10_10_REV extension, thus for other types, we need
to do the CPU side conversion ourselves. To achieve this, correctly
return COGL_PIXEL_FORMAT_ABGR_2101010 as the required format.
The internal format should also be GL_RGB10_A2, not GL_RGBA.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
Commit bf84b24 created meta-enums.h but it's pretty empty so far, the
vast majority of enum definitions is still in common.h.
Move the Meta enum definitions to meta-enums.h as one would expect them
to be found.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2467>
This replaces the v1 implementation, which is now renamed to
legacy-xdg-foreign. Both implementations use the same data structures
internally, so that protocol version mismatches between
the importer client and exporter client don't fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
Sysprof's build options have changed recently. This both bumps the sysprof
version and updates the configuration options for the subproject.
If now is not a good time to bump this, that is totally fine, but I wanted
to give you a MR with the necessary changes all in one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2428>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The "later" API is used to queue actions in relation to compositing,
thus is owned by the MetaCompositor instance. Make users of this
functionality get MetaLaters instance from the compositor, and stop
using the global meta_later() API.
display: Use non-singleton MetaLater API
tests: Use non-singleton MetaLater API
meta/common: Make docs refer to context aware MetaLater API
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means we can eliminate the use of scattered singletons that isn't
added by the tests or the test framework itself.
tests: Don't get backend from old singleton getter
Either use the ownership chain, or the explicit test context instance
pointer.
tests/wayland: Pass context to test client constructor
So that we can get the Wayland compositor directly from the context.
tests: Don't get display from singleton
tests/client: Make test client carry a context pointer
tests/runner: Have test cases carry a context pointer
tests/wayland/test-driver: Get backend from context
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Instead of passing around state using GINT_TO_POINTER() pass around a
state struct that also carries a pointer to the context. This allows
avoiding using old singletons for getting a window list.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
On the path towards clear ownership chains and always using them to find
other components, do the same for X11 client support paths too.
x11-display: Don't get backend from signleton
x11/selection: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The API has no concept of user data, and requires the user to some how
get an instance without context, i.e. via static globals. Limit this to
the file where this is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with the backend commit, this means all objects can reach the
MetaContext by walking up the chain, thus can e.g. get the backend from
the context, instead of the global singleton.
This also is a squashed commit containing:
compositor: Get backend via the context
The MetaCompositor instance is owned by MetaDisplay, which is owned by
MetaContext. Get the backend via that chain of ownership.
dnd: Don't get backend from singleton
window-actor: Don't get backend from singleton
dnd: Don't get Wayland compositor via singleton
background: Don't get the monitor manager from the singleton
plugins: Don't get backend from singleton
This applies to MetaPlugin, it's manager class, and the default plugin.
feedback-actor: Pass a compositor pointer when constructing
This allows getting to the display.
later: Keep a pointer to the manager object
This allows using the non-singleton API in idle callbacks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with other parts, make objects have the ability to walk up the
ownership chain to the context, to get things like the Wayland
compositor or backend instances.
Contains these squashed commits:
display: Don't get backend from singleton
window: Don't get backend from singleton
keybindings: Don't get backend from singleton
workspace: Don't get backend from singleton
display: Don't get Wayland compositor from singleton
selection: Add display getter
context/main: Get backend directly from the context
clipboard-manager: Don't get display from singleton
stack-tracker: Don't use singleton MetaLater API
startup-notification: Hook up sequences and activations to display
This allows using context aware API directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means objects have an owner, where the chain eventually always
leads to a MetaContext. This also means that all objects can find their
way to other object instances via the chain, instead of scattered global
singletons.
This is a squashed commit originally containing the following:
cursor-tracker: Don't get backend from singleton
idle-manager: Don't get backend from singleton
input-device: Pass pointer to backend during construction
The backend is needed during construction to get the wacom database.
input-mapper: Pass backend when constructing
monitor: Don't get backend from singleton
monitor-manager: Get backend directly from monitor manager
remote: Get backend from manager class
For the remote desktop and screen cast implementations, replace getting
the backend from singletons with getting it via the manager classes.
launcher: Pass backend during construction
device-pool: Pass backend during construction
Instead of passing the (maybe null) launcher, pass the backend, and get
the launcher from there. That way we always have a way to some known
context from the device pool.
drm-buffer/gbm: Get backend via device pool
cursor-renderer: Get backend directly from renderer
input-device: Get backend getter
input-settings: Add backend construct property and getter
input-settings/x11: Don't get backend from singleton
renderer: Get backend from renderer itself
seat-impl: Add backend getter
seat/native: Get backend from instance struct
stage-impl: Get backend from stage impl itself
x11/xkb-a11y: Don't get backend from singleton
backend/x11/nested: Don't get Wayland compositor from singleton
crtc: Add backend property
Adding a link to the GPU isn't enough; the virtual CRTCs of virtual
monitors doesn't have one.
cursor-tracker: Don't get display from singleton
remote: Don't get display from singleton
seat: Don't get display from singleton
backend/x11: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
While already cleaning up API, if this should ever be more non-static
than a constant, it's better if its a function on the monitor manager
instance than something static.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Since the Wacom panel rewrite, the "output" setting is handled as
a kind of tri-state for display-integrated tablets:
- If the setting is unset, the device is automatically mapped
to an output
- If the setting is set and not empty, the device is mapped to
the output defined by the EDID data
- If the setting is ['', '', ''], the device is mapped to the
span of all displays, like opaque tablets do.
This distinction for the unset setting fell through the cracks,
so both "Automatic" and "All displays" options were handled as
the former.
Add this distinction, so that display-integrated tablets can
be used like opaque tablets of sorts with no limitations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2767>
These are the ones attached to a display, thus they are the ones that may need
help from this heuristic. Non-integrated tablets (e.g. Intuos) will default to
the span of all monitors.
Fixes mapping of opaque tablets if a display-integrated tablet of the same
brand is also plugged in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2767>
This might happen when the workspace is not switched and
focus_default_window is called or when 'workspace on primary display
only' is enabled, a secondary display exists and the workspace is
switched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2747>
There's 2 users of this, meta_display_sync_wayland_input_focus() which
does already perform these checks on its own, and MetaCursorTracker's
update_displayed_cursor() to determine whether it should go with the
Wayland client's cursor.
This second check should also consider the existing ClutterGrabs, so
make meta_display_windows_are_interactable() handle them for both
callers.
Fixes the cursor shown over windows while e.g. there are menus opened.
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/2553
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2754>
This code path is important for "empty" commits to ensure we schedule
frame callbacks even if previous commits didn't cause stage redraws.
There is, however, no reason to schedule updates on all stage views
instead of only those the actor is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
Avoid some allocations, save some CPU cycles and make the code easier
to read.
Behaviourwise the only expected change is that now, if there are mapped
clones, we unconditionally choose the view with the highest refresh
rate the actor (or one of its clones) is on and don't check the
obscurred region any more.
Thus in some cases a client may receive a higher rate of frame callbacks
when obscured on a faster view while a clone is present on a slower
one. The assumption is that cases like this are relatively rare and
that the reduction of code complexity, the reduction of allocations in
`meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is
not fully obscured and has clones on other views, as well as generally
fewer lookups and less code in most common cases, compensate for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
We only support feedback-actors, such as DnD-icons, in the compositing
path at the moment.
The approach is similar to how we handle certain shell elements.
Implementations need to ensure no references to the object keep
around longer that necessary.
Arguably this should be replaced by a more robust and implicit actor
hierachy detection in the direct scanout code at some point.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2470
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2677>
The fields of 'priv->video_format.max_framerate' are all of type
uint32_t. Multiplying by G_USEC_PER_SEC can overflow, and equally,
dividing a large numerical type by uint32_t can err too.
Since the variable holding the result is int64_t, cast all uint32_t
fields to int64_t before doing any maths on it.
Spotted while trying to investigating an issue with framerates on
HDMI screencasts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2762>
Unused since https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
AFAICT.
As a bonus, gets rid of these compiler warnings:
../cogl/cogl/cogl-pipeline-layer-state.c: In function ‘cogl_pipeline_get_layer_min_filter’:
../cogl/cogl/cogl-pipeline-layer-state.c:1279:10: warning: ‘min_filter’ may be used uninitialized [-Wmaybe-uninitialized]
1279 | return min_filter;
| ^~~~~~~~~~
../cogl/cogl/cogl-pipeline-layer-state.c:1274:22: note: ‘min_filter’ was declared here
1274 | CoglPipelineFilter min_filter;
| ^~~~~~~~~~
../cogl/cogl/cogl-pipeline-layer-state.c: In function ‘cogl_pipeline_get_layer_mag_filter’:
../cogl/cogl/cogl-pipeline-layer-state.c:1291:10: warning: ‘mag_filter’ may be used uninitialized [-Wmaybe-uninitialized]
1291 | return mag_filter;
| ^~~~~~~~~~
../cogl/cogl/cogl-pipeline-layer-state.c:1287:22: note: ‘mag_filter’ was declared here
1287 | CoglPipelineFilter mag_filter;
| ^~~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2757>
Add a helper function that ensures any queued virtual input events have
been flushed from the input thread. This works by posting a task to the
input thread, which will itself queue another callback back to the main
thread. Once the main thread callback is invoked, the flush call is
unblocked and the function returns. Upon this, any previously emitted
virtual input event should have already passed through the input thread
back into the main thread, however not necessarily fully processed.
For making sure it has been processed, one also have to make sure the
stage has been updated, e.g. via `meta_wait_for_paint()`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2727>
After the commit "wayland/subsurface: Implement
meta_wayland_surface_get_window()" subsurfaces are supported. Adjust
some comments and fix a warning that could occur when closing a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The intention here was to check if the subsurface belongs to a window.
Thus it didn't behave as expected for subsurfaces belonging to non-toplevel
windows.
After the previous commit we can use `get_window()` to check for what we
actually want here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
Subsurfaces are special regarding windows as they don't have a window,
but usually have an ancestor which does. All current users of
`get_window()` are either used for known surface roles, such as xdg-*
ones, or, as is the case for pointer constrains, would actually want to
get the ancestors window.
Thus implement `get_window()` to allow pointer constrains to work.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2223
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The meta_prop_get_motif_hints() function was only used in the
old MetaUI frames code. The remaining code in mutter accesses
directly the MetaPropValue when loading properties for a window,
and does not use this API call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
Since we use XCB in the Mutter side, but Xlib in the frames client,
we cannot share the same struct definition since both libraries
will expect different type lengths (respectively, 32-bit ints vs.
longs).
Revert the changes that made both executables share the same
struct, since not both of them can get it right (and retrieve
correctly the struct with the contained flags) in reading the
Motif WM hints.
This reverts commit 2fb3c5a4f5.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
Adding the 'default-decoration' CSS class to MetaFrameHeader after
it is set as the headerbar makes it not account for the minimum size
correctly sometimes. This is a bit racy though - if the window opens
very quickly, it works as expected.
Adding the CSS class before the widget is used guarantees it'll
always report the correct size though, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2753>
The Python docs recommends using run() for all use-cases it can handle:
https://docs.python.org/3/library/subprocess.html#using-the-subprocess-module
run() waits for the subprocess started to complete, so it's not
necessary to use wait() and communicate() anymore. This simplifies the
script.
Previously running "check-style.py -r" after each commit in an
interactive rebase failed, b/c the script did not wait for the amend
command to complete. Using run() instead of Popen() solves this issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2733>
Before this, new files introduced by the range of commits checked were
not considered for formatting b/c uncrustify was always turned off in
the beginning of the files, and never turned back on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2733>
Add this CSS class both to the header bar itself, since it is what
actually contains the window controls, and to MetaFrameHeader too,
since it's what's directly attached to the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
Previous commit added support for setting the GTK4 theme setting
according to the color scheme setting. That's cool. What it didn't
add, though, was initializing the GTK4 theme setting to the proper
value. That means if the desktop starts at dark style, you'd still
get a light titlebar.
Fix that by updating the GTK4 theme setting on init as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
These are now referenced on the frames client side (in order to
track deletable state from the client window) and the mutter side
(pretty much everything else, like figuring out if a window wants
WM decorations).
It makes sense to make this a separate header, so that we don't
need to doubly define these flags/structs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
We use this for tracking the deletable state of the client window,
but forgot to check that the MWM_HINT_FUNCTIONS hint is set in
hints.flags before checking hints.functions.
This resulted in windows that do not specify this flag (and thus
should go with the defaults) in being mistakenly removed the close
button, as the functions flags would be typically 0 in that case.
Fixes issues with Chromium and Electron applications missing the
close button, since Chromium does this on X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
Recalculating window features is a busy thing on the Mutter side, the
different properties being (re)set will overwrite the current state
and cause some side work. Between that is the rewriting of the
_MUTTER_NEEDS_FRAME property on the window being recalculated, which
throws the frames client off, by thinking the window does actually
require a new frame.
It is not sufficient to trust that PropertyNewValue means the property
or the value are new, also double check that the window did not have
in fact a frame, and avoid the busy work if it did.
Besides the busywork that can be easily avoided, this also fixes the
window close button state being stuck if the window changed its
deletable state, since the frame being respawn managed to miss the
property change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
meta_screen_cast_window_stream_src_set_cursor_metadata() relies
entirely on meta_screen_cast_window_transform_cursor_position()
to return the correct relative cursor position.
However, this function actually does not return the expected
values, since it does not apply the resource scale to the
transformed position.
Actually apply the cursor scale when calculating the cursor
position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2737>
meta_screen_cast_stream_src_set_cursor_sprite_metadata() receives
the cursor sprite, position, and scale, and with that it downloads
the cursor sprite by drawing it into a separate framebuffer, then
calls cogl_framebuffer_read_pixels() in it - this is the offscren
path that is very common when using screen capturing applications
such as OBS Studio.
There's a sneaky issue in this code path though: the 'scale' value
is a float. The cursor size is then determined by multiplying the
sprite width and height - two integer variables - by scale, and
this relies on standard float-to-int conversions. This is problematic
as sometimes the rounded values disagree with what is expected by
cogl_framebuffer_read_pixels(). If the packing of either the cursor
width or height is off by one, glReadPixels() will try to write into
off bounds, which crashes.
This can be reproduced by enabling fractional scaling, setting a 150%
zoom level, on a 4K screen, and opening any commit with an image diff
in gitlab.gnome.org, all while screencasting. When hovering the new
image, the cursor sprite will be such that it triggers this code path,
and reproduces this issue.
Fix this by always ceiling the cursor sprite sizes.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2542
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2736>
The uninitialized fields in this event causes use of uninitialised
data as seen in valgrind:
==71864== Syscall param writev(vector[0]) points to uninitialised byte(s)
==71864== at 0x5026EBD: __writev (writev.c:26)
==71864== by 0x5026EBD: writev (writev.c:24)
==71864== by 0x6482A3B: UnknownInlinedFun (xcb_conn.c:296)
==71864== by 0x6482A3B: _xcb_conn_wait.part.0 (xcb_conn.c:551)
==71864== by 0x6482BAF: UnknownInlinedFun (xcb_out.c:469)
==71864== by 0x6482BAF: _xcb_out_send (xcb_out.c:470)
==71864== by 0x6483DD7: UnknownInlinedFun (xcb_out.c:416)
==71864== by 0x6483DD7: xcb_writev (xcb_out.c:409)
==71864== by 0x53B79B4: _XSend (xcb_io.c:587)
==71864== by 0x53BBF38: _XReply (xcb_io.c:679)
==71864== by 0x53AFFC9: XQueryTree (QuTree.c:47)
==71864== by 0x4982A5F: query_xserver_stack (stack-tracker.c:508)
==71864== by 0x4EA1F5F: g_closure_invoke (gclosure.c:832)
==71864== by 0x4ECFD45: signal_emit_unlocked_R.isra.0 (gsignal.c:3796)
==71864== by 0x4EC0129: g_signal_emit_valist (gsignal.c:3549)
==71864== by 0x4EC03B2: g_signal_emit (gsignal.c:3606)
==71864== Address 0x287d5900 is 32 bytes inside a block of size 16,384 alloc'd
==71864== at 0x4849444: calloc (vg_replace_malloc.c:1340)
==71864== by 0x53A5FE8: XOpenDisplay (OpenDis.c:240)
==71864== by 0x6100E3C: _gdk_x11_display_open (gdkdisplay-x11.c:1565)
==71864== by 0x60CF675: gdk_display_manager_open_display (gdkdisplaymanager.c:462)
==71864== by 0x49D59F1: open_gdk_display (meta-x11-display.c:1041)
==71864== by 0x49D5D64: meta_x11_display_new (meta-x11-display.c:1156)
==71864== by 0x49564AD: meta_display_init_x11_finish (display.c:743)
==71864== by 0x495679D: on_x11_initialized (display.c:818)
==71864== by 0x4D67558: g_task_return_now (gtask.c:1232)
==71864== by 0x4D67782: UnknownInlinedFun (gtask.c:1301)
==71864== by 0x4D67782: g_task_return (gtask.c:1258)
==71864== by 0x495663C: on_xserver_started (display.c:788)
==71864== by 0x4D67558: g_task_return_now (gtask.c:1232)
==71864== Uninitialised value was created by a stack allocation
==71864== at 0x49D4A59: take_manager_selection (meta-x11-display.c:640)
==71864==
To fix this, fully initialize the event struct before sending it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2535
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2724>
Since the frames are now rendered by a separate process, we no longer
can guarantee at this point that all updates were handled. Engaging
in a new synchronous resize operation will again freeze the actor,
so sometimes we are left with a not-quite-current buffer for the
frame+window surface.
In order to ensure that the right changes made it onscreen, delay
this next synchronous resize step until the moment the surface was
repainted. This avoids those glitches, while still ensuing the
resize operation ends up in sync with the pointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Let the frames client render its own shadow. In order to do that,
avoid double painting a shadow on the compositor side, and extend
the mask area of the frame, so it does unveil the (so far)
hidden frames-client-side shadows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
There's two meanings of "frame" there! Since SSD frames are now
rendered by an external client, and there are no actual mechanism
that ensures the frame did already get painted when the client did
respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be
artifacts when resizing windows.
In order to get always the best visual result, we should actually
synchronize rendering with both the client window and the window
frame window.
This commit adds these mechanisms, so a sync alarm update is
expected on both windows until further resizes are allowed, this
ensures window and frame stay in sync, even after moving rendering
elsewhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
It will become necessary to track properties and changes from frame windows,
and it will be more convenient to have this managed by the common property
tracking mechanisms.
Add this source_xwindow parameter so property handler functions can check
whether the property belonged to the client Window or the frame Window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Store the alarms in a different hashtable, and look up the MetaSyncCounter
right away. It so far avoids the MetaWindow middle man, but will also be
simpler when each window can possibly have more than one active alarms.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Replace the in-process implementation of frames with the external
frames client.
When a client window is created and managed by Mutter, Mutter will
determine whether it is a window that requires decorations and
hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME
property on the client window.
After the frames client created a window that has the _MUTTER_FRAME_FOR
property, Mutter will proceed to reparent the client window on the
frame window, and show them as a single unit.
Rendering and event handling on the frame window will be performed by
the external client, Mutter is still responsible for everything else,
namely resizing client and frame window in synchronization, and
managing updates on the MetaWindowActor.
In order to let the frame be managed by the external client, Mutter
needs to change the way some properties are forwarded to the client
and/or frame windows. Some properties are necessary to keep propagating
to the client window only, some others need to happen on the frame
window now, and some others needs to be propagated on both so they
are synchronized about the behavior.
Also, some events that were previously totally unexpected in frame
windows are now susceptible to happen, so must be allowed now.
MetaFrame in src/core/frame.c now acts as the wrapper of foreign
windows created by the frames client, from the Mutter side. Location,
size, and lifetime are still largely in control of Mutter, some
details like visible/invisible borders are obtained from the client
instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS
properties, respectively).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This small X11 client takes care of creating frames for client
windows, Mutter will use this client to delegate window frame
rendering and event handling.
The MetaWindowTracker object will keep track of windows created
from other clients, and will await for _MUTTER_NEEDS_FRAME property
updates on those (coming from Mutter), indicating the need for a
frame window.
This process is resilient to restarts of the frames client, existing
windows will be queried during start, and the existence of relevant
properties checked. Mutter will be able to just hide/show
SSD-decorated windows while the frames client restarts.
The frames are created through GTK4 widgets, the MetaWindowContent
widget acts as a replacement prop for the actual client window,
and the MetaFrameHeader wraps GtkHeaderBar so that windows can be
overshrunk, but otherwise a MetaFrame is a 100% true GTK4 GtkWindow.
After a frame window is created for a client window, the
_MUTTER_FRAME_FOR property will be set on the frame window,
indicating to mutter the correspondence between both Windows.
Additionally, the pixel sizes of the visible left/right/top/bottom
borders of the frame will be set through the _MUTTER_FRAME_EXTENTS
property, set on the frame window.
In order to make the frame window behave as the frame for the
client window, a number of properties will be tracked from the
client window to update the relevant frame behavior (window title,
resizability, availability of actions...), and also some forwarding
of events happening in the frame will be forwarded to the client
window (mainly, WM_DELETE_WINDOW when the close button is clicked).
Other than that, the frames are pretty much CSD GTK4 windows, so
window drags and resizes, and window context menus are forwarded for
the WM to handle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This check dates all the way back to commit ac2aa5337d. At the time, the
window switcher was an actual X window, that could generate crossing events
if popped up under the pointer. Checking for this kind of crossing events
made sense back at the time in order not to break focus-follows-mouse as
it's been behaving for long.
But now, this UI is all Clutter widgetry, which in the worst case (X11
sessions, of course) it will update the stage window shape to make these
parts clickable. This happens in other places of code that do already
check for ignoring crossing events.
Underneath, this looked up for a Mutter-local GdkWindow of type
GDK_WINDOW_TEMP, only the main MetaFrames window matches those characteristics
nowadays, notably no window switcher popups. Since the remaining window is
never unmapped (until perhaps shutdown), the paths were functionally dead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
If the window is not managed, it's weird that it asks for _NET_FRAME_EXTENTS,
it's even weirder that mutter replies with a frame border that would only
apply if the window were managed. Stop doing the latter, and drop the
MetaUI call that calculates borders from the theme settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Put the helper to use, in order to lift MetaWindow itself from this
accounting. As a bonus, the data itself now moved to the MetaWindowX11
private struct, since this may only happen with X11 windows (or its
Xwayland subclass).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This helper struct takes care of the handling of requests and alarms
in order to satisfy NET_WM_SYNC_REQUEST. It will be necessary to
decouple rendering of windows and frames in future commits, so each
window may need its own synchronization and accounting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This may result in a view of the stack in MetaStackManager that does not correspond
to reality, since the window is already being unmanaged, there is no point either in
notifying the stack manager about it.
This slight divergence with reality in the MetaStackManager may produce a non-accurate
view if querying its state has to go through the predicted branches. Later synchronization
with the X11 stack may even this out, but the result really depends on when it is asked.
Fixes some intermittent failures in the stacking/closed-transient-only-take-focus-parents
unit test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
The meta_window_show() method internally relies on window->mapped being
up-to-date, or attempting to focus it may fail since the window is not
mapped yet, resulting on the window being mapped, but not focused as
it would be expected.
This is moot so far, since windows with frames are created sort-of
synchronously and showing them will result in the focus attempt happening
when the window is already mapped, but things will break when this
becomes an asynchronous step.
Ensure to synchronize client state before showing, so any attempts to
focus the window are able to succeed despite the initial state when
calling meta_window_update_visibility().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
The test does simply "wait" which apparently is not enough to ensure the
client window did resize to the expected dimensions. Use "wait_reconfigure"
and assert that the size after resize is the expected, before going further
at testing its behavior after maximize/unmaximize; it might end up with the
unexpected size after the whole operation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Move the use count from a separate MetaWaylandBufferRef struct to the
MetaWaylandBuffer class, and remove the former.
The buffer use count is now incremented already in
meta_wayland_surface_commit, since the Wayland protocol defines the
buffer to be in use by the compositor at that point. If the buffer
attachment ends up being dropped again before it is applied to the
surface state (e.g. because another buffer is committed to a
synchronized sub-surface before the parent surface is committed),
the use count is now decremented, and a buffer release event is sent if
the use count drops to 0.
Buffer release events were previously incorrectly not sent under these
circumstances. Test case: Run the weston-subsurfaces demo with the -r1
and/or -t1 command line parameter. Resize the window. Before this
change, weston-subsurfaces would freeze or abort after a few resize
operations, because mutter failed to send release events and the
client ran out of usable buffers.
v2:
* Handle NULL priv->buffer_ref in
meta_wayland_cursor_surface_apply_state.
v3:
* Remove MetaWaylandBufferRef altogether, move the use count tracking
to MetaWaylandBuffer itself. Much simpler, and doesn't run into
lifetime issues when mutter shuts down.
v4:
* Warn if use count isn't 0 in meta_wayland_buffer_finalize.
* Keep pending_buffer_resource_destroyed for attached but not yet
committed buffers. If the client attaches a buffer and then destroys
it before commit, we ignore the buffer attachement, same as before
this MR.
v5:
* Rebase on top of new commit which splits up surface->texture.
* MetaWaylandSurfaceState::buffer can only be non-NULL if
::newly_attached is TRUE, simplify accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Until all dma-buf file descriptors for all buffers in the transaction
are readable, which corresponds to when the client drawing to the
buffers has finished.
This fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1162 if the
GPU & drivers support high priority contexts which can preempt lower
priority contexts.
v2:
* Also remove dma-buf fds from transaction and try applying it from
pending_buffer_resource_destroyed. Avoids freeze due to leaving a
GSource based on a closed fd attached if a client destroys a wl_buffer
which is part of a transaction which was committed but not applied
yet. (Robert Mader)
* Tweak transaction cleanup logic in wl_surface_destructor.
v3:
* Adapt to meta_wayland_dma_buf_get_source.
v4:
* Adapt to new commits using transactions for (sub-)surface destruction,
drop code to remove destroyed surfaces from pending transactions.
v5:
* Use g_clear_pointer in meta_wayland_transaction_destroy.
(Georges Basile Stavracas Neto)
* Add spaces between type casts and values. (Carlos Garnacho)
* Use (gpointer *) instead of (void**). (Carlos Garnacho)
* Use gpointer instead of void * in
meta_wayland_transaction_dma_buf_dispatch.
v6:
* Use g_hash_table_remove in meta_wayland_transaction_dma_buf_dispatch.
(Carlos Garnacho)
v7: (Jonas Ådahl)
* Move include of glib-unix.h below that of meta-wayland-transaction.h.
* Split up g_hash_table_iter_next call to multiple lines in
meta_wayland_transaction_commit.
* Call g_source_destroy as well as g_source_unref when freeing a
committed but not yet applied transaction (during mutter shutdown).
v8:
* Drop dma_buf_source_destroy, can use g_source_destroy directly.
(Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
From xdg_surface_constructor_get_popup / xdg_popup_reposition (called
during Wayland protocol processing) to finish_popup_setup /
meta_wayland_xdg_popup_apply_state (called when the popup state is
applied).
This makes sure that the parent window frame rectangle is up to date in
meta_wayland_xdg_positioner_to_placement.
v2:
* Use meta_wayland_surface_state_new () in
meta_wayland_transaction_add_xdg_popup_reposition.
v3:
* Move xdg_popup_repositioned handling to
meta_wayland_xdg_popup_apply_state.
v4:
* Do not steal pending->xdg_positioner in
meta_wayland_xdg_popup_apply_state, fixes leaking the corresponding
memory.
* Drop MetaWaylandSurfaceState::xdg_popup_repositioned, just use
::xdg_positioner.
v5:
* Reformat meta_wayland_xdg_positioner_to_placement calls to stay within
80 columns. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
This makes sure that finish_popup_setup is called after any previous
transactions for the parent surface have been applied, so the parent
window geometry is up to date.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Preparation for potentially calling meta_wayland_transaction_apply some
time after surface commit, in which case doing it in the former would be
too late: The client may legally destroy the attached wl_buffer
immediately after commit, in which case meta_wayland_buffer_attach would
spuriously fail and disconnect the client (or possibly even crash mutter
due to NULL error).
Requires splitting up the surface texture between protocol and output
state, and propagating from the former to the latter via
MetaWaylandSurfaceState.
v2: (Jonas Ådahl)
* Move meta_wayland_surface_get_texture call to separate line.
* Use g_autoptr for GError.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And keep track of the hierarchy separately for the Wayland protocol and
for output. Protocol state is updated immediately as protocol requests
are processed, output state only when the corresponding transaction is
applied (which may be deferred until the next commit of the parent
surface).
v2:
* Directly add placement ops to a transaction, instead of going via
pending_state.
* Use transaction entry for the sub-surface instead of that for its
parent surface.
v3:
* Use transaction entry for the parent surface again, to ensure proper
ordering of placement ops, and call
meta_wayland_surface_notify_subsurface_state_changed only once per
parent surface.
* Drop all use of wl_resource_add_destroy_listener, transactions are
keeping surfaces alive as long as needed.
v4:
* Rebase on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501
* Drop ClutterActor code from meta_wayland_surface_apply_placement_ops.
(Robert Mader)
v5:
* Rename MetaWaylandSubSurfaceState to MetaWaylandSurfaceSubState, since
the next commit adds not sub-surface specific state to it.
v6:
* Move include of meta-wayland-subsurface.h from
meta-wayland-transaction.c to .h, since the latter references
MetaWaylandSubsurfacePlacementOp.
v7:
* Drop superfluous !entry check from meta_wayland_transaction_apply.
v8:
* Rename output/protocol fields to output/protocol_state. (Jonas Ådahl)
v9:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_add_placement_op.
v10:
* Fix a few style issues per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Destroy Wayland protocol related state immediately when the Wayland
resource is destroyed, but keep the rest alive by any transaction which
references the surface.
This makes it easier and cleaner to deal with a surface getting
destroyed while it's still referenced by transactions.
v2:
* No more need to keep references for surfaces in the entries hash
table.
v3:
* Do not use surface->sub.transaction in wl_surface_destructor, just
destroy it.
v4:
* No need for wl_surface_destructor to use its own transaction.
v5:
* Use g_steal_pointer & (more) g_clear_pointer in wl_surface_destructor.
v6:
* Leave SURFACE_DESTROY signal emission in wl_surface_destructor.
v7:
* Use finalize instead of dispose callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
This keeps all surfaces referenced by a transaction alive until the
transaction is destroyed, and makes sure transactions are applied in
the same order as they were committed with respect to all surfaces
they reference.
v2:
* Guard against NULL entry in meta_wayland_transaction_apply.
v3:
* Keep single entries hash table.
v4:
* Unref the surface in the meta_wayland_transaction_merge_into while
loop only if the "to" transaction didn't already have an entry for it,
to prevent premature finalization of the surface (likely followed by a
crash).
v5:
* Unref the surface (implicitly via g_hash_table_iter_remove) in the
meta_wayland_transaction_merge_into while loop even if the "to"
transaction already had an entry for it, or we leak a reference.
* Use g_clear_object & g_steal_pointer to not leave behind a dangling
from->state pointer in meta_wayland_transaction_entry_merge_into.
v6:
* Add curly braces around
meta_wayland_transaction_add_placement_surfaces calls. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Instead of cached_state.
surface_commit for a synchronized sub-surface either commits the
transaction or merges it into the parent surface's transaction (if
the parent is a synchronized sub-surface itself).
This should fix or at least improve the behaviour of nested synchronized
sub-surfaces.
Also change wl_subsurface_set_desync:
* Commit sub-surface transactions separately. This may allow some of
them to be applied earlier in some cases.
* Commit transaction only for descendant sub-surfaces which become
newly de-synchronized themselves.
v2:
* Drop unused function prototypes
v3:
* Use g_clear_pointer for surface->sub.transaction.
v4:
* Use g_steal_pointer instead of g_clear_pointer. (Sebastian Wick, Jonas
Ådahl)
v5: (Carlos Garnacho)
* Add spaces between type casts and values.
* Use (gpointer *) instead of (void**).
v6: (Jonas Ådahl)
* Use g_clear_object in meta_wayland_transaction_entry_merge_into.
* Use meta_wayland_transaction_entry_free in
meta_wayland_transaction_merge_into.
* Fix alignment of meta_wayland_transaction_merge_pending_state
parameters.
* Remove unused meta_wayland_transaction_add_state declaration.
v7:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_merge_pending_state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
A transaction contains the committed state for a surface, plus any
cached state for synchronized subsurfaces.
v2:
* Handle sub-surface positions separately from surface states.
v3:
* Sync child states only for surfaces with state in the transaction.
v4: (Jonas Ådahl)
* Drop unnecessary g_object_new call from wl_subsurface_set_desync. (me)
* Fix indentation & formatting in meta_wayland_surface_commit.
* Add meta_wayland_surface_state_new helper function.
* Fix alignment of meta_wayland_transaction_apply_subsurface_position
parameters.
* Add curly braces around meta_wayland_transaction_sync_child_states
call in meta_wayland_transaction_apply.
v5:
* Make meta_wayland_surface_state_new an inline function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
If multiple transactions have entries for the same surface, they are
applied in the same order as they were committed. Otherwise, they can
be applied in any order.
This is preparation for following changes, transactions are still
applied as soon as they're committed.
v2:
* Move GQueue for transactions to MetaWaylandCompositor (Jonas Ådahl)
v3
* Say "entry for" instead of "state for", since there can be transaction
entries with no state (for surfaces which are getting destroyed).
v4:
* Use a hash table to keep track of all candidate transactions which
might be newly ready to be applied.
* Use clearer function / variable names.
v5:
* Use custom single-linked list instead of hash table for candidate
transactions, ordered by the transaction commit sequence number, so
that they're attempted to be applied in the same order as they were
committed.
* Rename transaction->queue to transaction->committed_queue, and
simplify its handling.
v6: (Carlos Garnacho)
* Add spaces between type casts and values.
* Use (gpointer *) instead of (void**).
v7: (Jonas Ådahl)
* Use G_MAXSIZE instead of ULONG_MAX.
* Fix indentation of meta_wayland_transaction_apply &
meta_wayland_transaction_maybe_apply_one parameters.
* Refactor find_next_transaction_for_surface & ensure_next_candidate
helper functions out of meta_wayland_transaction_apply.
* Refactor has_unapplied_dependencies helper function out of
meta_wayland_transaction_maybe_apply_one.
* Make while (TRUE) loop in meta_wayland_transaction_maybe_apply
consistent with general usage.
* Drop unused value local from meta_wayland_transaction_commit.
* Store pointer to compositor object in transactions, instead of
pointer to the queue of committed transactions.
* Drop tautological g_assert from meta_wayland_transaction_apply. (me)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
v2:
* Use single hash table with struct which will contain all kinds of
state handled by a transaction.
v3:
* Add meta_wayland_transaction_destroy.
v4 (Georges Basile Stavracas Neto)
* Fix struct _MetaWaylandTransaction(Entry) formatting.
* Explicitly test against NULL.
* Use gpointer insteadof void * for
meta_wayland_transaction_entry_destroy.
v5: (Robert Mader)
* Use for loop in is_ancestor.
* Include meta-wayland-transaction.h first in
meta-wayland-transaction.c.
v6:
* Use g_autofree & g_clear_object.
v7: (Jonas Ådahl)
* Rename meta_wayland_transaction_entry_destroy to
meta_wayland_transaction_entry_free.
* Drop g_autofree use from meta_wayland_transaction_entry_free again.
* Make meta_wayland_transaction_entry_free take a
MetaWaylandTransactionEntry pointer.
* Rename meta_wayland_transaction_destroy to
meta_wayland_transaction_free.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Need to deal with surface->resource == NULL and
surface->pending_state == NULL in some places.
v2:
* Avoid expanding conditions to multiple lines.
(Georges Basile Stavracas Neto)
v3:
* Use a single bailout condition in meta_wayland_client_owns_window as
well.
v4:
* Remove spare empty line in meta_wayland_surface_apply_state.
(Robert Mader)
* Add wl_resource_post_error calls in xdg-shell request handlers.
(Robert Mader)
* Drop checks in functions which can only be called if there's a valid
resource.
* Drop more checks which are unnecessary due to leaving the
SURFACE_DESTROY signal emission in wl_surface_destructor later.
v5:
* Move resource = surface->resource assignments to if (!resource) tests.
(Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Creates a GSource which will call the specified dispatch callback when
all dma-buf file descriptors for the buffer have become readable.
v2:
* Hold a reference to the buffer in the source, to prevent the buffer
from getting destroyed before the source.
v3:
* Do not use check callback, handle everything in dispatch callback.
(Dor Askayo)
v4: (Georges Basile Stavracas Neto)
* Define and use MetaWaylandDmaBufSource & MetaWaylandDmaBufSourceDispatch
types.
* Fix meta_wayland_dma_buf_source_dispatch &
meta_wayland_dma_buf_source_funcs formatting.
* Use gpointer instead of void*.
* Rename meta_wayland_dma_buf_get_source to
meta_wayland_dma_buf_create_source. (Carlos Garnacho)
v5:
* Explicitly handle NULL return value. (Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
v7:
* Fix code style harder. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And call it from meta_wayland_buffer_realize. This makes dma-buf fds
available for EGL image type buffers as well.
v2:
* Move buffer->dma_buf.dma_buf assignment value to next line.
(Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Add internal state (starting, running, stopping), and use this instead
of MetaDisplay struct fields to determine whether to start animations.
This fixes issues when we try to animate things when shutting down.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716>
When we remove a child, we stop its transitions (animations), but we
didn't stop animations on grand children. What we did, however, was to
clear the stage views of the grand children, and this caused a bunch of
orphaned transitions (ClutterTimeline) and accompanied warnings.
Make it so that if we stop transitions, and clear stage views, also stop
transitions for the grand children. Detached children don't have a way
to continue animating anyway, since they have no stage view (thus frame
clock) to be driven by.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716>
When a badly behaving ClutterActor implementation manages to invalidate
the allocation after the layout phase and before painting, we have no
idea where the actor should be painted without running the whole layout
machinery again.
For paint volumes in this case we pretend the actor covers the whole
stage and queue full-stage redraws. When updating stage-views, we're
also handling this case, but not in the most graceful way. Just like
with paint volumes, we should assume an actor without a valid allocation
is simply everywhere, so set priv->stage_views to all available stage
views in that case.
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6054
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2694>
On hotplug, the events we receive from the kernel are async, and
connectors in the kernel come and go as they please. In practice, this
means that calling drmModeGetConnector() twice more or less directly
after each other, there is no guarantee that the latter call will return
anything if the former did.
When updating the connector in response to hotplugs, we'd first update
the list of existing connectors, and following that, query each and
every one again for their current state, to update our internal
representation; only the former handled drmModeGetConnector() returning
NULL, meaning if unlucky, we'd end up doing a null pointer dereference
when trying to update the state.
Handle this by querying the kernel for the current connector state only
once per connector, updating the list of connectors and their
corresponding state at the same time.
Fixes the following crash:
#0 meta_kms_connector_read_state at ../src/backends/native/meta-kms-connector.c:684
#1 meta_kms_connector_update_state at ../src/backends/native/meta-kms-connector.c:767
#2 meta_kms_impl_device_update_states at ../src/backends/native/meta-kms-impl-device.c:916
#3 meta_kms_device_update_states_in_impl at ../src/backends/native/meta-kms-device.c:267
#4 meta_kms_update_states_in_impl at ../src/backends/native/meta-kms.c:604
#5 update_states_in_impl at ../src/backends/native/meta-kms.c:620
#6 meta_kms_run_impl_task_sync at ../src/backends/native/meta-kms.c:435
#7 meta_kms_update_states_sync at ../src/backends/native/meta-kms.c:641
#8 handle_hotplug_event at ../src/backends/native/meta-kms.c:651
#9 on_udev_hotplug at ../src/backends/native/meta-kms.c:668
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2131269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2709>
There is no need to use the 'bypass-*' method of event processing in the
changed function since in all cases the 'bypass-*' variable was set, any
following event processing functions would ignore the event anyway.
Simplify things a bit by just returning TRUE if the event is consumed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2714>
We can land inside meta_window_focus() in the middle of changing the
window workspace, because some signal handler of MetaWorkspace's
"window-removed" signal triggers a focus. This can cause a crash in
`g_assert (link)` when updating the MRU list because we still think
we're on the old workspace when actually we are already removed from
this workspaces MRU list.
To avoid crashes like this, bail out of meta_window_focus() when we're
in the middle of a workspace change.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5368
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691>
It's a bad idea to have data like this in the middle of a struct, as it
will easily cause everything behind it to be badly aligned and thus
increase memory access times.
So move all those bitfield booleans to the end of the struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691>
It is generally assumed here and there that the pointer at all point in
time is within some logical monitor, if there is any logical monitor to
be within.
With the input thread, this was for a short amount of time not reliable,
resulting in crashes in combination with hotplugging or suspend/resume,
where monitors come and go quickly.
What happens is that the pointer at first is within a logical monitor,
but when that logical monitor is removed, while the new monitor
viewports are handed to the input thread, the constraining happens
asynchronously, meaning there is a time between between the new
viewports are sent, and before clutter_seat_query_state() starts
reporting the constrained position.
If a new client mapped a maximized window during this short time frame,
we'd crash with
#0 meta_window_place at ../src/core/place.c:883
#1 place_window_if_needed at ../src/core/constraints.c:562
#2 meta_window_constrain at ../src/core/constraints.c:310
#3 meta_window_move_resize_internal at ../src/core/window.c:3869
#4 meta_window_force_placement at ../src/core/window.c:2120
#5 xdg_toplevel_set_maximized at ../src/wayland/meta-wayland-xdg-shell.c:429
#6 ffi_call_unix64 at ../src/x86/unix64.S:105
#7 ffi_call_int at ../src/x86/ffi64.c:672
#8 wl_closure_invoke at ../src/connection.c:1025
#9 wl_client_connection_data at ../src/wayland-server.c:437
The fix for this is to make sure that the viewports are updated and
pointers constrained synchronously, i.e. the main thread will wait until
after the input thread is done constraining before continuing.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2147502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2711>
We've been sending all events to clients immediately for quite some time
now, so this is only really impacting the Clutter scene graph, not
clients anymore.
That makes this behavior a somewhat unnecessary optimization (it was
useful at the time it was added, but it's not anymore), which will only
make our lives harder when we actually expect an event to be queued
(eg. in tests), so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2697>
We put a DEVICE_ADDED or DEVICE_REMOVED event into Clutters event queue
here, so we should also wait for Clutter to process events once.
Just putting an event into the queue doesn't mean it gets processed
immediately (especially when the commit after this one is applied), so
wait for a stage update here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2697>
Currently, we will notify the display about a new window being created
during the constructed phase of the GObject. During this time,
property-change notifications are frozen by GObject, so we'll emit a few
::notify signals only after the window-created signal, although
the actual property change happened before that.
This caused confusion in gnome-shell code where a notify::skip-taskbar =
true emission was seen when the property already was true inside a
window-created handler before.
In order to fix that that, we notify the window creation
post-construction
of the GObject on GInitable.init vfunc
Details
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6119#note_1598983
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6119
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2703>
As suggested by Carlos in a review of this MR, refactor the logic of
clutter_do_event() to have both adding and removing of devices from the
devices list in a single place.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2696>
Having the stage device list be responsible for delivering the
same events twice (first immediately to clients, then later to Clutter)
was expected to be tricky, a sneaky problem with it right now is the
following case:
While collecting events for a stage update cycle, we get three touch
events from the backend: TOUCH_BEGIN(seq=1) -> TOUCH_END(seq=1) ->
TOUCH_BEGIN(seq=1)
What we do right now when we see a TOUCH_BEGIN event is adding a device
to the stage right when it comes in from the backend. And when we see
a TOUCH_END, we remove the device from the stage not immediately but
only after it went through the queue.
In the case of the three events mentioned above, with the current
behavior, this will happen when they come in from the backend:
- TOUCH_BEGIN(seq=1): device gets added to the stage with seq 1, event
gets queued
- TOUCH_END(seq=1): Nothing happens, event gets queued
- TOUCH_BEGIN(seq=1): we try to add device to the stage, but seq 1 is
already there, event gets queued
Now when we go through the queue and see the TOUCH_END, the device with
seq 1 gets removed, but on the subsequent TOUCH_BEGIN, we won't add a
new device, so this event (and all events with seq=1 that are still in
the queue) is now ignored by Clutter because it has no device.
What we want to do here is to cut short once the TOUCH_END event comes
in: Process queued events immediately and make sure the device is
removed from the stage list before a new device can be added. Same goes
for any other events that will lead to devices getting removed.
Small note: Since this leads to clutter_stage_get_device_actor()
returning NULL, I was wondering why we never crash because of this:
Turns out _clutter_actor_handle_event() handles self = NULL just fine
without crashing...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2696>
With commit 6c17aa66c6 we made sure no
stale device entries might land in the stage device list. The same can
happen for pointer devices too in theory, in practice we never really
filter them out, but it's good to handle them here anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2696>
We'll call this function from a few more places for the
CLUTTER_DEVICE_REMOVED case, so move the check for which devices are
valid into the function itself to avoid having to check everywhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2696>
If two X11 windows were the last two, we'd remove them from the stack
while unmanaging them. That'd hit an assert in
meta_stack_tracker_restack_managed(), resulting in the following crash
when Xwayland exited unexpectedly with two or more X11 windows being the
only windows on the stack:
#1 g_assertion_message() at ../glib/gtestutils.c:3256
#2 g_assertion_message_expr() at ../glib/gtestutils.c:3282
#3 meta_stack_tracker_restack_managed() at ../src/core/stack-tracker.c:1210
#4 on_stack_changed() at ../src/core/stack.c:142
#5 _g_closure_invoke_va() at ../gobject/gclosure.c:895
#6 g_signal_emit_valist() at ../gobject/gsignal.c:3456
#7 g_signal_emit() at ../gobject/gsignal.c:3606
#8 meta_stack_changed() at ../src/core/stack.c:265
#9 meta_stack_remove() at ../src/core/stack.c:324
#10 meta_window_unmanage() at ../src/core/window.c:1542
#11 meta_x11_display_unmanage_windows() at ../src/x11/meta-x11-display.c:111
#12 meta_x11_display_dispose() at ../src/x11/meta-x11-display.c:141
#13 g_object_run_dispose() at ../gobject/gobject.c:1448
#14 meta_display_shutdown_x11() at ../src/core/display.c:831
The added test specifically checks that this scenario is handled
gracefully.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2143637
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
Instead of having users of the test client manually deal with alarm
filters, let the test client automatically add itself as filters. This
changes the MetaX11Display a bit, to handle an array of filters instead
of a single filter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2704>
The CRTC cursor sprite scale was incorrectly assumed to be always 1.0
when using the default not-scale-monitor-framebuffer mode. This is
harmless in most cases, as most clients provide HiDPI capable cursors,
but for the ones that didn't, we'd end up drawing their cursors
unscaled, when using the cursor planes.
Fix this by using the "texture scale" which is what is intended for
this.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2477
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2698>
Cursor planes tend to be ARGB8888 and support no other format (ideally
we should not hard code this, but un-hard-coding that is for another
day), and if we put e.g. a XRGB8888 buffer in there, it'll either result
in the gbm_bo allocation failing (it doesn't allow USE_CURSOR with any
other format) or mode setting failing if using dumb buffers directly.
In the former case, we'll fall back to OpenGL indefinitely, and in the
latter, we'll have failed mode sets as long as we try to set the invalid
cursor buffer as the cursor plane.
Change things to process all buffers that are not ARGB8888 using the
scale/rotate machinery we already have, turning XRGB8888 into ARGB8888.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2477
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2698>
Attaching a new buffer with a different size than the old one means
that the viewport needs to be recalculated.
Not doing this caused the viewport to be incorrectly applied when
viewport_src_rect remained the same after attaching such buffer.
Pipeline reset usually happens when applying a new viewport,
but it doesn't happen when the viewport values remain the same.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2689>
A client may provide a positioner that places the window outside of its
parent. This isn't allowed, according to spec, so we hide the window and
log a warning. This, however, leads these affected clients with an
incorrect view of what is mapped or not, meaning it becomes harder to
recover.
Fix this by sending xdg_popup.done when we hide the popup due to an
invalid position. Don't error out the client, let the bug slide, as
that's a less jarring experience for existing applications that
reproduce this than being disconnected, which practically feels like a
crash.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2408
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2645>
In constrast to x11, Wayland has sane handling for touch events and
allows the compositor to handle a touch event while the clients are
already seeing it. This means we don't need the REJECTED state on
Wayland, since we can also grab sequences after the client has seen
them.
So disallow moving sequences to the REJECTED state on Wayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2508>
Updating of the paint volume used for culling these days happens
during the finish-layout stage, not while painting. Also we have
geometry-based, not paint-based picking anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Rename the `last_paint_volume` to `visible_paint_volume`: That avoids
confusion with the `had_effects_on_last_paint_volume_update` flag and
also makes it clear that this paint volume is the currently visible one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Rename the paint_volume_valid flag to has_paint_volume in order to
better reflect what it's for.
The name "paint_volume_valid" implies that the paint volume can be
invalidated and thus sounds like it's involved with some kind of
caching. The flag that's actually involved with caching is
"needs_paint_volume_update", while "paint_volume_valid" is only meant to
store whether the actor has a paint volume to work with.
So rename paint_volume_valid to has_paint_volume to avoid confusion
about which flag is used for caching.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
For clarity and for further improvements, introduce a separate function
to update the paint volume instead of doing that inside
_clutter_actor_get_paint_volume_mutable().
Also add a FIXME comment for a possible bug I noticed while working on
it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
Since ClutterActor now properly caches its paint volume and ClutterText
tries hard to invalidate its own cached paint volume on every redraw
anyway (that's more often than ClutterActor invalidates its own paint
volume), we can simply rely on the caching of the paint volume done by
ClutterActor and invalidate that on every redraw.
So remove the private cached paint volume from ClutterText and all its
invalidation machinery.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
The function _clutter_paint_volume_get_stage_paint_box() actually
doesn't modify the paint volume that's passed to it, so make that a bit
more clear by passing a const paint volume as the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
These days it's possible to chain up into the default get_paint_volume()
implementation again, which renders
clutter_actor_get_default_paint_volume() unnecessary. So remove that
function and move clutter_actor_update_default_paint_volume() back into
real_get_paint_volume() where it belongs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1492>
When modifiers are enabled on mutter on some of the older i915 systems observed
Black-screen on 2nd monitor during multi-head use cases, upon debugging observed
that disabling modifiers on these systems resolved the Black-screen issue:!1618.
This issue depends whether we have enough DBuf space to provide required bandwidth
for the userspace demands. Those platforms which have less Display Buffer, will
just have more chance to face lack of it. However it still depends on various
factors like amount of planes(i.e the more planes we have, the more we divide the buffer),
refresh rate, bpp and so on.
This affects watermark calculations and the minimum blocks required for at least
wm level 0. If we don't have sufficient ddb at least for wm0 for all planes in
the configuration then it is rejected.
Until we have TEST_ONLY commit solution is built we could make sure to disable
modifiers support on these older i915 systems based on udev rules defined in this commit.
This commit makes sure that modifiers are still usable on latest i915 systems.
List of PCI-IDs are referred from:
f8bf2a9a15/include/pci_ids/iris_pci_ids.h
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1618
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2641>
It's not really a backend thing, and we'll want to profile e.g. loading
the backend too, so create it very early and destroy it very late and
let MetaContextMain own it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2678>
This change fixes the issue where the cursor is always
embedded in the frames even when the client has requested
the cursor information be sent as metadata in the stream.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2629>
This reverts commit eac227a203.
Currently, Flatpak applications can bypass the X11 permission setting
and access the X server through abstract sockets because X11 authentication
is not enforced for the current user ID.
Fix this by always requiring X11 authentication for Xwayland. This also
means applications without XAUTHORITY set to the file with Mutter's
Xwayland credentials cannot connect to X, including apps launched from
VT or SSH.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2633>
When deciding if a window should be unredirected because it was causing
fullscreen damage in the past, it was not considered whether the window
is still fullscreen. This could result in a floating window being
unredirected if it was chosen for unredirection because of
_NET_WM_BYPASS_COMPOSITOR = 1 and was previously fullscreened for >= 100
frames, long enough to change does_full_damage, before getting
unfullscreened.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2434
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2651>
Back in 2014 sending pressed keys to Wayland clients caused issues,
because at least Xwayland didn't handle that gracefully, causing issues
like ghost-pressed keys. A way it was reproduced was quickly alt-tab:ing
to and from a Firefox window, which would cause the File menu bar
incorrectly appearing.
While this was reported to the Xwayland component back then, it was,
probably by mistake, assumed to be an issue in mutter, and mutter
stopped sending pressed key events on enter.
The following year, Xwayland was eventually fixed, but the work around
in mutter has been kept around until it was again noticed as an
inconsistency between compositor implementations.
Lets remove the work around, and follow the spec, again.
This reverts commit c39f18c2d4.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2457
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2657>
We'd set the capabilities to 'none', meaning all previously enabled
device classes would be disabled. That means we shouldn't re-disable
them directly after.
This ensures '..disable()' is only called once for every '..enable()'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2657>
We traverse the whole screnegraph anyway these days in finish_layout(),
so no need for the whole "set the flag on parents even though we don't
need it" dance anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2667>
With high frequency mouse devices, we would send very many configure
events per each update cycle, which had the end result that some clients
constantly re-allocating and redrawing their buffers far too often, if
they did this in direct response to xdg_toplevel configure events.
Lets throttle the interactive resize updates to stage updates, to avoid
having these clients doing the excessive buffer reallocation.
This also removes some old legacy X11 client resize throttling, that
throttled a bit arbitrarily on 25 resizes a second; it is probably
enough to throttle on stage updates for these clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2652>
Some mice send a value slightly lower than 120 for some detents. The
current approach waits until a value of 120 is reached before sending a
low-resolution scroll event.
For example, the MX Master 3 sends a value of 112 in some detents:
detent detent
| | |
^ ^ ^
112 REL_WHEEL 224
As illustrated, only one event was sent but two were expected. However,
sending the low-resolution scroll event in the middle plus the existing
heuristics to reset the accumulator solve this issue:
detent detent
| | |
^ ^ ^ ^
REL_WHEEL 112 REL_WHEEL 224
Send low-resolution scroll events in the middle of the detent to solve
this problem.
Fix https://gitlab.gnome.org/GNOME/mutter/-/issues/2469
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2668>
There do indeed seem to be places in our own code that trigger grabs on
actors before they are realized. It was not the intention to change the
practical preconditions for GNOME 43, so make it an even lower minimum
that every caller ought to match: That the actor is attached to the stage.
Further constraining of these preconditions will have to wait until
branching for new development.
Fixes: 9c79c7234 (clutter: Only allow grabs to be created on realized actors)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2670>
The bare minimum that we can ask to an actor before creating a grab
on it is that it is realized (and thus, attached to the stage). Bail
out if that is not the case when creating a grab.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
If an actor is being unrealized or otherwise unparented, it's a good
indication that its grabs are now stale and possibly harmful. Ensure
these are dropped when the actor is unparented.
This is now an unlikely event, since there is code to also dismiss
grabs when a visible grabbed actor goes unmapped. But that may be
prevented from happening, or the ordering of circumstances allow a
grab to be created and an actor destroyed without going unmapped
first. This grab dismission on unmap stays as it matches the UI-level
expectatives that an actor must be visible to be grabbed.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2475
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
Previously, when scroll was received in a remote session, it was handled
as continuous scroll.
This generated issues with clients without high-resolution scroll
support as the code path in charge of accumulating scroll until 120 is
reached was not used and therefore discrete scroll events were not being
generated.
Handle scroll generated in a remote session as discrete scroll when the
source is CLUTTER_SCROLL_SOURCE_WHEEL to fix this issue.
Fix https://gitlab.gnome.org/GNOME/mutter/-/issues/2473
Fixes: 9dd6268d13 ("wayland/pointer: Send high-resolution scroll data")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2664>
In fcfe90aa, multiple for loops were replaced with
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE.
However, this substitution was not side-effect free, and introduced a
null-pointer dereference risk as shown in the example below:
Old:
for (n = g_node_first_child (surface->subsurface_branch_node);
n;
n = g_node_next_sibling (n))
{
if (G_NODE_IS_LEAF (n))
continue;
meta_wayland_surface_update_outputs_recursively (n->data);
}
n is checked for NULL during each loop in the condition expression.
Therefore, when `G_NODE_IS_LEAF (n)` is called, `n` is guaranteed not to
be NULL. Note also that g_node_first_child is also NULL-safe since it
performs a NULL check internally.
New:
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE (surface, subsurface_surface)
meta_wayland_surface_update_outputs_recursively (subsurface_surface);
=
for (GNode *G_PASTE(__n, __LINE__) = meta_get_first_subsurface_node ((surface)); \
(subsurface = (G_PASTE (__n, __LINE__) ? G_PASTE (__n, __LINE__)->data : NULL)); \
G_PASTE (__n, __LINE__) = meta_get_next_subsurface_sibling (G_PASTE (__n, __LINE__)))
In the new logic `subsurface` is still checked for NULL in the loop
condition. However, in the new loop init:
...
meta_get_first_subsurface_node (MetaWaylandSurface *surface)
...
n = g_node_first_child (surface->subsurface_branch_node);
if (!G_NODE_IS_LEAF (n))
...
The above implementation performs a `G_NODE_IS_LEAF` call, which
performs a dereference on `n`, without first checking for NULLs.
This NULL dereference triggers the following gnome-shell crash:
Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 meta_get_first_subsurface_node (surface=0x55d589623450) at ../src/wayland/meta-wayland-surface.h:399
#1 pointer_can_grab_surface (pointer=0x7f6dc4012700, surface=0x55d589623450) at ../src/wayland/meta-wayland-pointer.c:1306
#2 0x00007f6ddb94d509 in meta_wayland_pointer_can_grab_surface (pointer=<optimized out>, surface=surface@entry=0x55d589623450, serial=serial@entry=996) at ../src/wayland/meta-wayland-pointer.c:1321
#3 0x00007f6ddb950d05 in meta_wayland_seat_get_grab_info (seat=seat@entry=0x55d586c24f20, surface=0x55d589623450, serial=996, require_pressed=require_pressed@entry=0, x=x@entry=0x0, y=y@entry=0x0)
at ../src/wayland/meta-wayland-seat.c:467
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2655>
Unlike the multi-view path, the optimized/single-view one doesn't check
if the surface-actor is really present on the view. That is the case
whenever it's hidden - e.g. when the window is minimized.
Fixes 3b7137cb35
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2662>
The stage view list does not get updated when an actor gets hidden in
order to avoid unnecessary work, such as scale changes. However, we
still want `is_effectively_on_stage_view` to report `FALSE` in this
case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2662>
The :input-purpose and :input-hints properties were added without
actually handling the get/set operations, whoops.
All code uses the (working) methods, so this only fixes expectations,
not an actual bug :-)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2659>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case the window content get centered on a black
background which covers the whole monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
Fullscreen Wayland toplevel surfaces don't need to respect the
configured size in which case it should be shown centered on the monitor
with a black background. The black background becomes part of the window
geometry.
The surface container is responsible for correctly culling the surfaces
and making sure the surface actors are removed from the actor tree to
avoid destroying them.
The window actor culling implementation assumes all surfaces to be direct
children of said actor. The introduction of the surface_container actor
broke that assumption. This implements the culling interface in
MetaWindowActorWayland which is aware of the actor surface_container and
fullscreen state.
v2: Fix forwarding culling to surface even if there is a background.
v2: Don't alter passed geometry.
v2: Update window geometry code documentation to reflect these changes.
v2: Only use constrained rect if we're acked fullscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
Prepare for adding Wayland specific culling logic to the
MetaWindowActorWayland class by moving all the logic to the non-abstract
classes, since there will be no reason to keep the logic in
MetaWindowActor around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
This is helpful to know what current state a window actually have, in
contrast to the state in MetaWindow (e.g. MetaWindow::fullscreen) which
is the intended state, be it current or not yet so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
First make sure we call 'move_resize()' in all cases where the size or
position can change, then move the updating of the buffer rect to the
same place as we update the frame rect. This means keeping track of
surface size changes, in addition to geometry changes, and calling
finish_move_resize() whenever any of those changes, in addition to
acknowledged configurations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
A "window rect" in most places refers to the rectangle the window
corresponds to when it comes to window management. MetaWindow::rect also
refers to this window management related rectangle. However in the
geometry sync functions, it instead called what was to be the rectangle
the actor should have as "window rect", which is arguably a bit
confusing. Fix this by renaming it "actor_rect" so that it becomes clear
that it's the rectangle the actor should get on the stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
MetaWindowActor previously peeked at the number of child Actors to
determine the number of surfaces. The following commit rearranged the
tree such that MetaWindowActorWayland always has two Actors. This change
lets the subclass determine if the main surface describes the whole
window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
When a window configuration is constructed for a Wayland surface it
contains a position, size and a scale. The scale is the geometry scale
for the configuration, i.e. before the size is sent the passed dimension
is divided with the passed scale.
When moving between monitors with different scales, if we use the
existing geometry scale, this means we will send a configure event with
incorrect dimensions. Fix this by calculating the scale used in the
configuration given the rect we're configuring with as this will mean
the correct size will be sent to the client.
v2: Removed the fullscreen condition. Don't know why it was added to
begin with.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
There were some magic conditions that decided when
meta_window_constrain() was to be called or not. Reasoning about and
changing these conditions were complicated, and in practice the caller
knows when constraining should be done. Lets change things by adding a
'constrain' flag to the move-resize flags that makes this clearer. This
way we can, if needed, have better control of when a window is
constrained or not without leaking that logic into the generic
to-constrain-or-not expression.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2338>
We have no way to sanely add safe modes if there are no modes we can
compare with, thus don't try.
Fixes the following crash:
#0 are_all_modes_equally_sized at ../src/backends/native/meta-output-kms.c:284
#1 maybe_add_fallback_modes at ../src/backends/native/meta-output-kms.c:310
#2 init_output_modes at ../src/backends/native/meta-output-kms.c:347
#3 meta_output_kms_new at ../src/backends/native/meta-output-kms.c:414
#4 init_outputs at ../src/backends/native/meta-gpu-kms.c:332
#5 meta_gpu_kms_read_current at ../src/backends/native/meta-gpu-kms.c:368
#6 meta_gpu_kms_new at ../src/backends/native/meta-gpu-kms.c:403
#7 create_gpu_from_udev_device at ../src/backends/native/meta-backend-native.c:461
#8 init_gpus at ../src/backends/native/meta-backend-native.c:551
#9 meta_backend_native_initable_init at ../src/backends/native/meta-backend-native.c:632
Fixes: 877cc3eb7d44e2886395151f763ec09bea350444
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2127801
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2646>
This just checks for any chromaticity being zero and gamma being in
range but we could do a better job at detecting bad data in the future.
Also check the return value of cmsCreateRGBProfileTHR which can be NULL.
Fixes gnome-shell#5875
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2627>
ATM sending modifiers to clients prevents direct scanout for DRI3
clients via Xwayland. Xwayland using the dma-buf feedback v4 Wayland
protocol will solve that, but that might take a while yet to appear in
the wild. Once that happens, this can be reverted.
Direct scanout still works for native Wayland clients as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2637>
Make sure that if we wiggle a scan-out capable surface a bit, it won't
scan out if it's not exactly in the right position. Do this by first
making the window not fullscreen, then moving it back and forth,
verifying the correct scanout state for each presented frame.
This test addition reproduces the issue described in
https://gitlab.gnome.org/GNOME/mutter/-/issues/2387.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
If we have a window that match the size (i.e. will pass the "fits
framebuffer" low level check), that doesn't mean it matches the
position. For example, if we have two monitors 2K monitors, with two 2K
sized windows, one on monitor A, and one on monitor both monitor A and
B, overlapping both, if the latter window is above the former, it'll end
up bing scanned out on both if it ends up fitting all the other
requirements.
Fix this by checking that the paint box matches the stage view layout,
as that makes sure the actor we're painting isn't just partially on the
right view.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2387
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2624>
Painting the swap region with CLUTTER_DEBUG_PAINT_DAMAGE_REGION happens
on the view framebuffer, so don't transform the region we paint to the
onscreen.
Fixes the swap region painting on rotated monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2590>
Gnome-shell uses meta_display_focus_default_window() when shell elements
loose focus which is the case with Alt+Tab window switching. Globally
active input clients don't immediately gain focus though so if
meta_display_focus_default_window focuses a wrong window stacking and
focus don't behave as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
New commands to set the number of workspaces, activate a workspace, with
and without focus, move windows to specific workspaces, and check the
stacking on a specific workspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
When switching workspaces we previously focused on whatever window is on
top of the stack. If a window is marked as "always on top" then it would
always receive focus when switching workspaces.
Fixes#2240
Fixes gnome-shell#5162
Fixes#178Fixes#678
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
We want to use the workspace MRU list to decide the default focus but
Globally Active Input clients don't call
meta_window_set_focused_internal and therefore don't update the MRU
list. Move the update to meta_window_focus instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
The completed signal is only emitted if the timeline actually completed
but when an actor is destroyed or removed from its parent the timeline
is stopped and not completed.
The workspace switch effect removes window actors from the window group
which destroys the timeline so on_$EFFECT_effect_stopped is never
called and the pointer to the timeline is dangling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
The workspace switch animation moves the WindowActors out of the
WindowGroup so if we shut down while the animation is playing the
WindowActors will have queued a destroy but will be disposed only after
the compositor is destroyed, leaving the WindowActor with a dangling
pointer.
Fix the issue by killing the workspace switch animation on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2489>
This is an old relic from when ClutterStageView was being added, and
tests were somewhat prepared to be able to test the "X11 style" of
things, with the nested backend some how managing to emulate that.
Lets drop that stuff, it isn't used by the test suite, and isn't useful
anyway; if we want to test X11 configurations, we should use the actual
X11 backend, which didn't make use of this anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2619>
It exposed unnecessary public and private API, and used a global static
variable instead of a return value, none which was necessary. Remove
both API and use a return value for communicating to the caller.
This doesn't remove a public symbol, lets do that for GNOME 44.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2619>
This was used gala to implement hot corners, and the way the barrier API
works, there isn't really any practical reasons to not make it
derivable, since the backend is a separate type and object.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2626>
This adds a copy of the calibration test profile and sets up a test to
first add it as a system profile, then setting up the XDG_DATA_HOME
directory so that the duplicate profile is detected, added, and later
discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
We might fail with some part of the color profile construction and
initialization. For example there might be a system wide profile with
the same ID as one we attempt to add from a local ICC directory. When
this happens, we should drop these profiles, and use the ones from the
system instead.
Profiles may fail to initialize for other reasons too, e.g.
unpredictable colord errors, or other I/O issues.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2429
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
If our profile wasn't fully initialized, we'd try to clean it up, in an
attempt to handle race conditions by finding synchronously then cleaning
it up, but don't attempt this if the profile is ready, as that means we
didn't create one in the first place.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
This is instead of getting anything from the CdDevice. This avoids a
crash when CdDevice isn't successfully setup but something still tries
to look up the filename of the ICC profile.
This isn't a real bug fix for anything, but there is no reason having to
rely on CdDevice for this anyway, and as we don't really have control of
it, it's less reliable of containing something valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2622>
When creating a render device, we create a temporary EGLContext where we
then query the `GL_RENDERER` string to check whether the renderer is any
of the known software renderers. After we're done, we destroy the
context and move on.
This should be fine as according to specification eglDestroyContext(),
with the context being actually destroyed a bit later when it's no
longer current, but mesa, when running RK3399 (Pinebook Pro), this
results in a crash in a future eglMakeCurrent():
#0 in dri_unbind_context () at ../src/gallium/frontends/dri/dri_context.c:266
#1 in driUnbindContext () at ../src/gallium/frontends/dri/dri_util.c:763
#2 in dri2_make_current () at ../src/egl/drivers/dri2/egl_dri2.c:1814
#3 in eglMakeCurrent () at ../src/egl/main/eglapi.c:907
...
We can avoid this, however, by calling eglMakeCurrent() with
EGL_NO_CONTEXT on the EGLDisplay, prior to destroying, effectively
avoiding the crash, so lets do that.
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7194
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2414
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2612>
We'll never scan out, which is why ADDFB2 is required otherwise, and we
won't enable the DMA buffer extension if
'EGL_EXT_image_dma_buf_import_modifiers' is missing, so send modifiers
in this case.
This also happens to avoid crashing when the GPU is null, since we'd
otherwise attempt to dereference it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2578>
EGLStream is incompatible with atomic mode setting, but nvidia-drm when
using libgbm is not, so lets only deny using atomic mode setting when
the render device is an EGLStream based one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2578>
The type of render device used for a specific GPU affects the mode
setting backend that can be used, more specifically, when the render
device is an EGLStream based one, atomic mode setting isn't possible, as
page flipping is done via EGL, not via atomic mode setting commits.
Preparing the render devices before KMS devices means can make a more
informed decision whether to deny-list atomic mode setting for when
a certain GPU uses a EGLStream based render device instance.
This also means we need to translate mode setting devices to render node
devices when creating the render device itself, as doing it later when
creating the mode setting device is already too late.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2578>
Doing an early out in a constructed() is a bit awkward, and unexpected,
and makes it tricky to call the parents constructed() method (which we
didn't), so clean that up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2578>
Currently, the peripheral "output" setting will be unset if Mutter is
deciding automatically the mapped output of a tablet device. In that
case, gnome-control-center will have a hard time figuring out itself
the better output to show the tablet calibration UI, unless it's hand
held by Mutter.
Add this private D-Bus interface so that gnome-control-center can look
up the output as determined by Mutter to bring the missing harmony
between both. This interface consists of a simple method to get the
mapped output for a input device node.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2605>
The D-Bus runner used by tests, including installed tests, is made to be
reusable from GNOME Shell. To do this, install it and the templates in
the pkgdatadir (e.g. /usr/share/mutter-APIVERSION/tests/), generate a
custom runner for the installed tests that uses the installed script and
templates, and change the non-installed original runner to use the
non-installed templates.
The end goal is to reuse the D-Bus session runner and templates used for
mutter when test running GNOME Shell.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1354>
A few calculations and assignments are done unnecessarily when the
last next presentation time is invalid. This increases the cognitive
complexity of the function for no reason.
No change in behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2486>
When moving to another monitor the window size may change in some
cases. While unconditionally notifying a size change is not always
correct, it animates the window when moved to another monitor in
GNOME Shell.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2558>
Following the EGL_KHR_swap_buffers_with_damage specification, the
surface damage used by eglSwapBuffersWithDamage does not need to
contain the damage history.
Rework that to initialize swap_region earlier, before appending the
damage history.
This may help optimizing the composition process in some cases (at least
on X11 when EGL_KHR_swap_buffers_with_damage is available) by not
accumulating additional regions as damaged unnecessarily.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2241>
This is what the protocol says we should do, and even though normally
an out of focus client should not have any reason to create IM requests,
there is a bit of a grey area around focus changes, as both the client
losing focus and the client gaining focus may respectively try to
disable/enable in an undetermined order.
Anyways, since in that situation the client losing focus is not aware
of the requests being ignored, the serial should always be incremented
in order not to break accounting of .done/.commit for that specific
client.
Fixes the IM focus being possibly "lost" after changing focus between
clients, if the race condition turned the odds in that direction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2585>
Mutter can play sounds in some contexts and also provides an API
for libmutter users to do so using libcanberra internally.
In some specific use cases of Mutter, we would like to not depend
on libcanberra and not have any sound playing feature by default.
The changes keeps the sound player API but make it no-op if the
sound_player feature is disabled to not make it possible to break
a gnome-shell build.
See https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2270
for relevant discussion
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2375>
If the vendor_name was previously successfully determined, we would end
up in the else case, overwriting it with "Unknown vendor" and leaking
the previous vendor_name.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2603>
This allows using two separate ICC profiles for one "color profile",
which is necessary to properly support color transform
calibration profiles from an EFI variable.
These types of profiles are intended to be applied using the color
transformation matrix (CTM) property on the output, which makes the
presented output match sRGB. In order to avoid color profile aware
clients making the wrong assumption, we must set the profile exposed
externally to be what is the expected perceived result, i.e. sRGB, while
still applying CTM from the real ICC profile.
The separation is done by introducing a MetaColorCalibration struct,
that is filled with relevant data. For profiles coming from EFI, a
created profile is practically an sRGB one, but the calibration data
comes from EFI, while for other profiles, the calibration data and the
ICC profile itself come from the same source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2568>
We may want to use scanout even if the default framebuffer
of the stage view is an offscreen, for example when a Wayland
client provides pre-rotated buffers. The caller is responsible
to ensure this is correct - we already asserted on that before.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2468>
If a stage view uses an offscreen framebuffer exclusively for
rotation and a Wayland client provides pre-rotated buffers,
we should try to use scanout.
This saves us one copy more than scanout in the onscreen case,
i.e. two fullscreen copies in total.
Offscreen rotation is notably used for all 90/270 degree rotations
at the moment, as using display hardware for them is apparently
more complex than for x-/y-flips and can even have detrimental
effects on power consumption.
This can be tested with `weston-simple-egl`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2468>
This mocks gsd-colord to enable night ligth at a given temperature. The
test then verifies that the result exactly matches that of the gamma
ramps gsd-color generated for the same temperature and ICC profile.
There are two types of profiles tested; ones with VCGT, i.e. calibrated
profiles, and ones without. These are tested as the VCGT affects how the
gamma curve looks, while the non-VCGT profiles all only rely on
the blackbody temperature to generate a gamma ramp.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
More or less copied from gnome-settings-daemon. The look up tables are
either calculated based on the VCGT (Video Card Gamma Table) and the
blackbody color for a given temperature, or the blackbody color for a
given temperature alone, if no VCGT is available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
This means that e.g. custom profiles or calibrated profiles will be
added and registered with colord. This does not use CdIccStore for two
reasons: don't want to generate duplicate entries for auto-generated
EDID or EFI profiles, and we want to store profiles as MetaColorProfile.
It also happens to be the case that CdIcc does synchronous I/O, which
should be avoided everywhere except on startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
It will be used to generate gamma look up tables depending on
temperature.
The temperature comes from org.gnome.SettingsDaemon.Color and
depends on the current night light state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently
brightness set if the proxy is not ready are ignored; whether the
brightness value should be cached and set once it appears or whether
color profiles should be reapplied is yet to be decided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
Instead of passing 4 arguments (red, green and blue arrays as well as a
size), always pass them together in a new struct MetaGammaLut. Makes
things slightly less tedious.
The KMS layer still has its own variant, but lets leave it as that for
now, to keep the KMS layer "below" the cross backend CRTC layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
In practice, for KMS backend CRTC's, we cache the gamma in the monitor
manager instance, so that anyone asking gets the pending or up to date
value, instead of the potentially not up to date value if one queries
after gamma was scheduled to be updated, and before it was actually
updated.
While this is true, lets still move the API to the MetaCrtc type; the
backend specific implementation can still look up cached values from the
MetaMonitorManager, but for users, it becomes less cumbersome to not
have to go via the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
We created device profiles, that we manage the lifetime of in colord,
but color devices can be assigned profiles other than the ones it was
created for. For example, this can include the standard sRGB profile
provided by colord.
To achieve this, keep track of the default profile of the CdDevice as
the "assigned" color profile of the device. Given this profile
(CdProfile), construct a MetaColorProfile that can then be interacted
with as if it was generated by ourself.
The assigned profile (default profile in colord terms) does nothing
special so far, but will later be used to determine how to apply CRTC
gamma ramps etc.
The sRGB.icc file used in the tests was copied from colord. It was
stated in the repository that it has no known copyright restrictions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
This works similiarly to how MetaColorDevice works, by creating them
asynchronously then signalling the 'ready' signal when done. Also
similarly to MetaColorDevice, the on-demand sync cleanup on finalize is
added, to avoid race conditions when hotplugs happens very rapidly,
e.g. in tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Just as gsd-color does, generate color profiles. This can either be done
from EFI, if available and the color device is associated with a built
in panel, or from the EDID. If no source for a profile is found, none is
created.
The ICC profiles are also stored on disk so that they can be read by
e.g. colord. The on disk stored profiles will only be used for storing,
not reading the profiles, as the autogenerated ones will no matter what
always be loaded to verify the on disk profiles are up to date. If a on
disk profile is not, it will be replaced. This is so that fixes or
improvements to the profile generation will be made available despite
having run an older version earlier.
After generating, add some metadata about the generated file itself
needed by colord, i.e. file MD5 checksum and the file path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Tests that test case EDID is setup correctly, and that color devices for
monitors are created.
tests/color: Add hotplugging tests
Checks that changing the number of connected monitors reflects the
number of current color devices, and that we end up with the correct end
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Ready means it has established the connection to colord and can operate.
Will be used by tests to make sure tests don't fail due to race
conditions when connecting to colord.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Previously, gsd-color handled adding color devices. It got information
about those via the GnomeRR API, which is part of libgnome-desktop.
libgnome-desktop itself got this information from the
org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented
by mutter.
Now, mutter itself will add all the monitor color devices itself,
without having to go via gsd-color.
We sometimes need to delete colord devices synchronously, in certain
race conditions when we add and remove devices very quickly (e.g. in
tests). However, we cannot use libcolord's 'sync' API variants, as it
has a nested takes-all main loop as a way to invoke the sync call. This
effectively means we end up sometimes not return from this function in a
timely manner, causing wierd issues.
Instead, create our own sync helper, that uses a separate context that
we temporarly push as the thread-default one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
This will be needed for adding colord integration without breaking
testing.
The test context is altered to make sure any left over color devices are
cleaned up before starting. This means it becomes possible to run a test
case multiple times without having to restart meta-dbus-runner.py.
Note: Don't use os.getlogin() to get the current username; as that
requires a controlling terminal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
It's not really about monitors, even though it is used for monitors.
Lets shrink MetaMonitorManager a bit moving it to the backend.
While at it, stop leaking it too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
What determines whether one MetaMonitor is the same as the other should
be whether the actual monitor is the same. The way to check this is
comparing the EDID vendor/product/serial fields. Whene these are
incomplete, fall back on the 'winsys ID'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Same applies to MetaOutput. The reason for this is to make it possible
to more reliably know when there was EDID telling us about these
details. This will be used for colord integration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
We fairly consistently had multiple monitors with the whole
vendor,product,serial tuple identical. If we start relying on making
monitors a bit more unique, e.g. for colord integration, we need to make
two monitors connected distinguishable in order for tests to properly
reflect reality and excercise the correct colord integration paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
As for the types of monitor, X11 and KMS are currently assumed to always be
physical, while the virtual ones are assumed to be virtual. In theory
X11 ones could be virtual, but lets not bother. KMS ones can be virtual
in the case of virtual KMS, but we typically use that for testing as if
it was physical, so lets leave it as such.
Will later be used to feed correct information to colord.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Create a color manager type that eventually will be the high level
manager of color related behavior, such as ICC profiles and
color "temperature" a.k.a. night light.
For now, it's only an empty shell. It's also constructed by the actual
backend, as at a later point, the X11 and native color management
implementations will differ.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Client connections may linger after the test driver is teared down;
handle this gracefully by unsetting the user data on the wl_resource,
and make the resource destructor a no-op, instead of where it would
otherwise remove itself from the resource list. This fixes this crash
seen in CI:
Received signal 11 (SIGSEGV)
#0 g_list_remove() at ../glib/glist.c:596
#1 test_driver_destructor() at ../src/tests/meta-wayland-test-driver.c:219
#2 destroy_resource() at ../src/wayland-server.c:730
#3 for_each_helper() at ../src/wayland-util.c:416
#4 wl_map_for_each() at ../src/wayland-util.c:430
#5 wl_client_destroy() at ../src/wayland-server.c:889
#6 wl_display_destroy_clients() at ../src/wayland-server.c:1482
#7 meta_wayland_compositor_prepare_shutdown() at ../src/wayland/meta-wayland.c:441
#8 meta_context_dispose() at ../src/core/meta-context.c:667
#9 g_object_unref() at ../gobject/gobject.c:3863
#9 g_object_unref() at ../gobject/gobject.c:3780
#10 glib_autoptr_clear_GObject() at /usr/include/glib-2.0/gobject/gobject-autocleanups.h:29
#10 glib_autoptr_clear_MetaContext() at ../src/meta/meta-context.h:32
#10 glib_autoptr_cleanup_MetaContext() at ../src/meta/meta-context.h:32
#10 main() at ../src/tests/wayland-unit-tests.c:707
#11 __libc_start_call_main() in /usr/lib64/libc.so.6
#12 __libc_start_main() in /usr/lib64/libc.so.6
#13 _start() in /builds/GNOME/mutter/build/src/tests/mutter-wayland-unit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2601>
This reverts an attempt at saving texture memory that was introduced
recently in 16fa2100. It was misguided because the same texture may be
needed in the next frame if a window has multiple previews visible on
screen at once (gnome-shell's overview). Keeping the mipmaps around
seems to reduce the peak render times of the overview by roughly 5%-10%.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2598>
Although its atomic KMS support seems to work at first, mode sets to
anything other than the Xilinx preferred max resolution of 2048x1280
would result in a hang. The xlnx kernel driver is given:
`DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_PAGE_FLIP_EVENT`
and it does complete the mode set without error, but page flip events
never arrive and so you're frozen on the first frame.
Revert to legacy KMS which has no such problem with non-default modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2596>
I don't see how this makes sense at all, ClutterClickAction really
shouldn't mess with BUTTON_RELEASE events that are not part of a
gesture.
So propagate those events instead of stopping them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2552>
The source field was removed from ClutterEvent with commit
b644ea1bce because the preferred way of
getting the event actor is now to use the device/sequence actor from the
stage directly.
With crossing events it's not that easy though, as crossing events
explicitly have a source and related actor that doesn't have to be the
same actor as the device actor. Since we kept around the "related" field
there anyway, let's also introduce a "source" field in
ClutterCrossingEvent and return that actor when get_source() is called
on a crossing event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2551>
Just like we did with the ::captured-event signal, add detail to the
::event signal too. At the first glance this might not seem necessary
since there are individual signals like scroll-event or touch-event that
get emitted at the same time, but these don't exist for touchpad gesture
events and others.
As an easy solution for that, just make it possible to use detail on the
event signal as we did with the caputured-event signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2431>
The "activate" and "deactivate" signals on ClutterStage are used by
Cally to track the key-focus when the user is interacting with shell UI.
key-focus only gets tracked while the stage is activated.
Wayland has no concept of the stage receiving focus or not, so right now
the activation state is bound to whether there's a focus_window in
meta_display_sync_wayland_input_focus(). Since display->focus_window is
set pretty much all the time, this effectively binds activation state to
whether the stage holds a grab or not. This is almost good enough, but
it misses cases where key-focus is on the stage without a grab, for
example when keyboard-navigating the panel after using Ctrl+Alt+Tab.
It seems to make more sense to bind the activation state to whether
key-focus is set to an actor or to NULL, so let's do that instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2329>
In the timespan between an activation token being created and the
token being used by the activated application, the surface that started
the activation request may end up destroyed/disposed.
In that case, the token would be left with a stale surface pointer,
maybe causing crashes later on. Set up a destroy notification listener
so that we do know to unset the token surface if that situation arises,
this will result in Mutter not considering the token activatable, thus
maybe issuing the "Application needs attention" notification if the
activated surface did not immediately get focus. In any case this is
better than a compositor crash.
A typical situation where this may happen is "Open With..." dialogs,
since those don't live long after launching the application.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2390
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2592>
There is some surface tracking going on here, and all notify handlers
are possibly leaving the linked wl_listener behind. Ensure it is unlinked
in all destroy notification functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2588>
Since commit 1bf70334 "tests/runner: Make test runner use the headless
backend", tests are run with the native backend in headless mode, which
will attempt to open each GPU and show a warning (fatal during tests)
if it cannot.
However, in headless mode we might not be logged in on any seat (for
example we might be logged in via ssh instead), which means we might
legitimately not have permission to use any GPUs, even if they exist.
Downgrade the warning to a debug message in this case.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2381
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2584>
The catch option makes test run via 'catch'[1], which will log
backtraces whenever an abort or segmentation fault happens in any of the
subprocesses. The aim is to enable this when running in CI to help
debugging crashes that only tend to happen in CI.
While it's possible to wrap the whole meson command in 'catch', doing so
doesn't cover the KVM tests, so this option is added instead that covers
both cases.
[1] https://gitlab.gnome.org/jadahl/catch/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2561>
Until recently, mutter-test-runner called into libraries that
indirectly depend on (mutter's fork of) Clutter, but did not actually
call into Clutter itself. Commit 1bf70334 "tests/runner: Make test
runner use the headless backend" gave it a direct call into Clutter,
which means the runtime linker will fail unless the executable's
RUNPATH is sufficient to find Clutter.
For future-proofing, do the same for the other test executables.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2389
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2581>
This is a followup to GNOME/mutter!1578
This commit does a couple of things to avoid creating multiple
pipelines per commit.
First, it avoid catch all `when: manual` rules, which might
end up matching custom variables set which might potentially
not be handled.
Secondly it reworks the `workflow:rules:` and the pipeline guard
rules to avoid duplicate pipelines as the gitlab documentation
suggests.
Last, it switches from yaml anchors to the new `reference` gitlab
keyword which is more flexible.
https://docs.gitlab.com/ee/ci/jobs/job_control.html#avoid-duplicate-pipelines
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2534>
This adds the 4 new connector types that mutter didn't know about from
drm_mode.h in the kernel.
Noticed because mutter kept crashing when plugging in a USB-C adapter to
use an external monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2577>
When we e.g. generate switch configs (i.e. the ones from pressing the
Super+P or the switch-config key on laptops), try a bit harder to find a
"good" monitor scale.
With "good", it means pick a scale that was used in a previous
configuration. In practice, this means that if you for example have
configured your external monitor to use a specific scale, then pressed
e.g. "built in only", and then switched back to e.g. "external only" or
"linear", the generated configuration will use the scale that was
previously configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
If two modes are roughly the same, they should probably use the same UI
scaling factor. I.e. for the same monitor, if a 4K mode was configured to
have a certain scaling factor, and we generate a new configuration with
a similar sized 4K mode, we should re-use the scale previously
configured; however if we e.g. go from a 4K mode to a FHD mode, we
shouldn't.
This allows implementing better hueristics when using the switch-config
feature, where we'd be less likely to loose the for a certain monitor
mode combination previously configured scaling factor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This will eventually help with better hueristics for finding a good
scale. It currently doesn't change much, but the helper will later gain
more functionality that will also help when coming up with mirroring
configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
The resulting logical monitor was eventually marked as primary anyway,
but without the config being marked as such, various primary properties
was not set e.g. the one on the MetaOutput. Also, tests would fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This condition is inverted of how it should be. Since pad focus relies
on grouped devices lookups (e.g. pads not grouped with a tablet do not
focus surfaces), this fixes issues in pad focus and event propagation to
wayland clients.
Fixes: fff3654941 - wayland: Check input device capabilities in tablet seats
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2573>
This checks that an unmapped but created Wayland window correctly handle
monitor changes. This is specifically added to test an edge case causing
a crash with the following backtrace:
```
...
4) 0x00007ffff78a2a6b in g_assertion_message_expr ()
5) 0x00007ffff7defd5b in meta_window_update_for_monitors_changed () at ../src/core/window.c:3745
6) 0x00007ffff7899758 in g_slist_foreach () at ../glib/gslist.c:885
7) 0x00007ffff7dbe562 in meta_display_foreach_window () at ../src/core/display.c:3185
8) 0x00007ffff7dbe5fd in on_monitors_changed_internal () at ../src/core/display.c:3210
9) 0x00007ffff796f4ff in g_closure_invoke () at ../gobject/gclosure.c:830
10) 0x00007ffff7981316 in signal_emit_unlocked_R () at ../gobject/gsignal.c:3740
11) 0x00007ffff7987699 in g_signal_emit_valist () at ../gobject/gsignal.c:3495
12) 0x00007ffff7987bc2 in g_signal_emit () at ../gobject/gsignal.c:3551
13) 0x00007ffff7d89915 in meta_monitor_manager_notify_monitors_changed () at ../src/backends/meta-monitor-manager.c:3517
...
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
If the window didn't have a size, it would still have a monitor, and
when we are asked to update, we must update, as the old monitor might
not be kept around, leaving us vulnerable to use after free.
Avoid not updating the monitor by using the stored IDs (preferred, or
previous) to find suitable logical monitors, with the primary monitor
being the last fallback unless we're completely headless.
This fixes the assert
!window->monitor ||
g_list_find (meta_monitor_manager_get_logical_monitors (monitor_manager),
window->monitor)
in meta_window_update_for_monitors_changed() being hit when a Wayland
window has been created, but not mapped, when a hotplug happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This will allow tests to change monitor resolution. The first argument
is the monitor ID; there is always one monitor added by default, and it
has the id 0. It's currently not possible to add more monitors, so
passing '0' is the only valid way to resize monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This hasn't worked for a while, since the test always runs the nested
backend, meaning it's a Wayland compositor. To unblock testing window
management in combination to monitor changes, lets remove the
unreachable X11 WM paths, so that we can start using virtual monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
util-private.h includes glib-i18n-lib.h, which requires GETTEXT_PACKAGE
to be defined. The define comes from config.h,
but that cannot be included in headers, so we have to make sure
that any source file that pulls in util-private.h (or a header
that includes it) includes config.h first.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2566>
In some hardware configurations, presentation timestamps could be
missing from some page flip events, leading to a temporary loss of
vblank synchronization.
This occurs at least with AMD GPUs for atomic commits that only update
the cursor plane. [0]
In those cases, it's better to calculate the next update time
according to the last valid presentation timestamp instead of relying
on the dispatch lateness.
[0] https://gitlab.freedesktop.org/drm/amd/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2481>
The image build step is prone to race conditions, e.g. token changes. It
also tends to hit sporadic connection errors to FDO's gitlab. To
minimize the risk of these types of issues block pipelines, always retry
the image building step if it failed.
This has the unwanted consequence that changes to the image building
that results in the script actually failing, but right now there doesn't
appear to be a way to distinguish between actual build errors, and the
mentioned race conditions, as both cause the script to fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2564>
mutter needs GDK to use the x11 backend. It already calls
gdk_set_allowed_backends ("x11") for this purpose; however, if
GDK_BACKEND=wayland (or any other non-x11 backend possibly) happened to
be in the environment, GDK would fail to initialize at all. This would
result in mutter not registering as X11 window manager, and all X11
clients hanging.
Big thanks to Olivier Fourdan for figuring this out!
v2:
* Restore original value of GDK_BACKEND environment variable after
initializing GDK.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2022283
Bug: https://bugs.debian.org/1008992
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2496>
Both the fragend and vertend shader state was called
"CoglPipelineShaderState", which was rather annoying, especially when
the type needs to be exposed outside of the .c file as part of moving
out unit tests. Make the types unique. This also avoids confusing what
type one is looking at.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
It consists of only a macro and build description logic.
Adds a macro for simpler tests that doesn't require a context; unit
tests requiring a context should use the same framework as conform
tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
All working tests have already migrated to the test suite using mutter;
move the old unported tests over too, and remove the conform test
framework, as it is no longer used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
This is in preparation of moving Cogl tests into src/tests, so they can
use the real backend, instead of the franken-backend it some how still
manages to use some how.
This makes them no longer installed. Most mutter tests are yet to be
installed, so leave that for later, since bigger changes are needed for
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
Now that we support Wayland buffer transforms in all cases, we can
properly report them to outputs.
Also make sure we resend the output geomerty on transform changes.
This partly reverts commit bda9c359
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
This allows the GL fallback path to correctly paint the cursor
if clients pre-rotated the buffer using
`wl_surface::set_buffer_transform`, visually matching the
hardware cursor path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
They can be quite heavy, as they load up one virtual machine each. If
your system is already busy, this can easily cause them to time out
instead of finish in time, as they all fight over the same limited
amount of CPU and I/O time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2556>
Failing in `wait_for_effects_completed()` or `wait_for_view_verified()
indicates client- or compositor-bugs. As hitting those is quite likely
during test development, print error messages to simplify debugging.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
The "single pixel buffer" Wayland protocol extension provides a way for
clients to create 1x1 buffers with a single color, specified by
providing the color channels (red, green and blue) as well as the
alpha channel as a 32 bit unsigned integer.
For now, this is turned into a 1x1 texture. Future potential
improvements is to hook things up to the scanout candidate logic and
turn it into a scanout capable DMA buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
When taking the scanout path we still want to clear the
redraw-clip from the stage-view in order to ensure we skip
frames in `handle_frame_clock_frame()` if no new redraw-clip
was recorded.
This was not done previously as the accumulated redraw-clip was
needed for the next repaint, likely under the assumption that
scheduling a scanout repeatedly would be computationally cost-free.
This assumption does not hold in a VRR world.
In order to archive both, an accumulated redraw-clip for the next
paint and frame-skipping during scanout, introduce new API to defer
and accumulate redraw-clips until the next repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2480>
To Wayland clients, it doesn't matter how we configure our onscreen
buffers, since they don't necessarily have the same bandwidth issues
related to mode setting, whichis the primary reason why we disable
modifiers using the udev rule, so simply check whether importing with
modifiers will work at all and advertise modifiers if so is the case.
This might help avoid issues using legacy non-modifiers path in drivers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
We disable modifiers for two reasons: an udev rule saying so, or the
lack of a working drmModeAddFB2(). However, to the users, this is not
granular enough. While the current user, whether to enable modifiers in
MetaRendererNative, doesn't need more granularity, we want to send
modifiers to Wayland clients even if the onscreen framebuffers should
still be allocated without modifiers.
Prepare for differentiating between how Wayland DMA buffers work and how
onscreen buffer allocation work by separating the relevant device flags.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
Similar to the clutter commits
- Drop all the private structs documentations
- Make use of gi-docgen items linking as much as possible
- Use markdown formatting for code snippets
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2441>
This uses MetaCompositorViewNative to find a candidate surface for
scanout and to keep track of it separately for each view, effectively
allowing each CRTC to use a different buffer for direct scanout.
There are three parts for potentially assigning a buffer for direct
scanout at the compositor level:
1. Finding a candidate surface actor on the view (if any)
2. Attempting to assign the candidate's buffer for direct scanout
3. Updating references relating to the scanout candidate as needed
The three parts were moved in their entirety from being handled by the
MetaCompositorNative to being handled by the MetaCompositorViewNative.
As part of this transition, the logic was also slightly refactored so
that each of the three parts is handled by its own helper function.
This allowed to avoid the use of "goto" statements and hopefully make
the logic easier to read and follow.
The first part mentioned above was changed in this commit to make use
of the new meta_compositor_view_get_top_window_actor () API to get the
top window actor in the view instead of the top window actor on all
views.
The second part and third parts mentioned above weren't changed other
than being done in the context of a view instead of globally.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
All of the checks this function performed internally were already
done before calling it, making it a simple wrapper function without a
meaningful purpose.
Removing this function also reduces the chance of additional checks
being added to the MetaSurfaceActor after it is already chosen as a
scanout candidate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
This class is meant to hold logic specific to the native backend
in the context of a MetaCompositorView.
Its addition requires making MetaCompositorView inheritable, and an
addition of a virtual function which allows each compositor to create
its own MetaCompositorView instance.
In the case of the MetaCompositorNative, a MetaCompositorViewNative
is created. In all other cases, a MetaCompositorView is created.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
First, add logic in MetaCompositorView to find topmost visible
MetaWindowActor on its view, and expose it through a new API.
Then, queue an update to find the top MetaWindowActor of each
MetaCompositorView in the following cases:
1. The MetaCompositor is in its initial state.
2. The window stack order has changed.
3. A window has changed its visibility.
4. A "stage-views-changed" signal was emitted for a MetaWindowActor.
Finally, perform the queued update in meta_compositor_before_paint (),
and assert that an update isn't queued during painting. This ensures
that the top window actor in the MetaCompositorView remains up-to-date
and available to child classes of MetaCompositor throughout the entire
paint stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
The idea is that the state of the MetaCompositorView shall be
up-to-date only in specific scenarios, thus allowing operations
performed on it to be queued and aggregated to be handled in the
right time, and only if they are still necessary.
For example, in a following commit, the top window actor in each
view will be planned (if needed) only once before painting a frame,
rendering the top window actor in the MetaCompositorView potentially
stale in all other times.
Similarly, if a MetaCompositorView is destroyed before the beginning
of the frame, a queued operation to update its top window actor can be
discarded.
As an interface segragation measure, and as part of an attempt to
avoid the use of g_return_if_fail () to check the validity of the
MetaCompositorView's state in multiple places (which is still prone to
human error), the interfaces through which a MetaCompositorView is
made available would only ones where it's state is gurenteed to be
up-to-date.
Specifically, this commit gurentees that the state of the
MetaCompositorView would be up-to-date during the before_paint () and
after_paint () vfuncs exposed to child classes of the MetaCompositor.
The frame_in_progress variable will be used in a following commit to
guarantee that the MetaCompositorView's state is not invalidated during
this time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
MetaCompositorView is a class which contains compositor logic
specific to ClutterStageViews.
Each MetaCompositorView is "attached" to a ClutterStageView as an
opaque pointer using g_object_set_qdata_full (), and is freed when
the ClutterStageView is destroyed. This ensures that the lifetime of
the MetaCompositorView can't extend beyond the lifetime of its
ClutterStageView.
In a following commit, MetaCompositorView will be expanded to allow
keeping track of the top MetaWindowActor located on each
ClutterStageView.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2526>
This can happen with the native backend if the previous frame clock
dispatch didn't result in any KMS update, e.g. because it was triggered
by an input event, but the HW cursor didn't need updating on the stage
view. (This is likely to happen on some out of multiple stage views,
but might be possible even with a single stage view if the cursor isn't
visible)
We would previously delay next_presentation_time_us by one refresh
interval in this case, which could result in spuriously leaving one
refresh cycle unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2498>
Use the dark variant for decorations if the color-scheme preference
indicates that it's preferred, and the client didn't explicitly
pick a variant via the _GTK_THEME_VARIANT hint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2541>
Although mipmapping is still slower than not mipmapping, commit 16fa2100
simplified N synchronous draw calls per texture tower into just one. So
it's more efficient now, and four years have passed since the throttling
was introduced so people also have better hardware as well as mutter being
generally faster than it used to be. So I am happy to effectively revert
commit c9c32835.
This means antialiasing will remain consistent rather than popping in and
out of existence.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/403
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2538>
For this to pass, pass an explicit Wayland display name to avoid the
display conflict warning that may happen when there is an already
running Wayland display server.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2448>
Often, most of the output consists of a long list of exposed modes for
each monitor. If --short is passed, only pass modes that has properties.
In practice, this means "preferred" modes, "current" modes, and
similarly special cases, which significantly reduces noise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2448>
Somewhat long overdue... We've been supporting more than a single
pointer for quite a long time now, let's make sure things don't break if
two pointer devices enter the same ClutterActor: Count the number of
pointers an actor has instead of using a simple boolean value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2348>
In certain edge cases it's currently possible that an actor never
gets a valid allocation and paint volume.
One such case is adding an unmapped, hidden child to an unmapped
cloned parent and then showing the child. This happens currently
e.g. if a Wayland subsurface is added to a already mapped window
while the user is in the overview.
Ensure relayouts in two more such cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2530>
This one does proper error reporting. Via Javascript, barriers are
constructed directly via GObject construction, which currently can't
handle error reporting, but when calling from C we can. However, if we
initialize using GInitable, and use that in our constructor method, once
gjs gains support for construction using GInitable, including the error
reporting, we'll automatically get proper error reporting to Javascript.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
In the past, barries were added to the window management X11 display
instance window table, and then special cased when iterating over the
list.
Since then, barriers, which are really part of the backend, has stopped
being added to the window hash table, instead being managed by the
backend. Lets clean up the left-over special casing that is no longer
needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
Prior to this commit, barriers were created with a MetaDisplay pointer,
despite being entities related and owned by the backend. In the X11
case, it was also not hooked up to the backend X11 connection, but the
clutter one, meaning for example that the logic was active (but dormant)
also for the Xwayland connection.
Fix this by moving X11 barrier management and event processing fully to
the backend. Also replace passing a display pointer with passing a
backend pointer. Keep the display pointer around for a release, but mark
it as deprecated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2442>
It papered over wrong `meta_rectangle_transform()` behaviour for
non-flipped output transforms. Also there is no obvious reason
why we would need inverted values here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
- Drop bogus `meta_monitor_transform_invert()`. It papered over
wrong `meta_rectangle_transform()` behaviour for non-flipped
output transforms.
- Update `scale_and_transform_cursor_sprite_cpu` to match the GL
pipeline matrix in `MetaShapedTexture`, fixing several of the
flipped cases. Note: the rotation applied is the one a client would
need to apply to the buffer for a given monitor transform.
- While on it, drop a redundant `return`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
With `META_MONITOR_TRANSFORM` values matching their `WL_OUTPUT_TRANSFORM`
counterparts, the definition from the Wayland spec applies: the
`META_MONITOR_TRANSFORM` value tells us how the output was rotated
and that the buffer was drawn by the client to compensate for that.
The matrix describes the transformation from surface- to buffer-
coordinates, so the operation we need here is the same one that
the client applied (not from buffer- to surface-coordinates, i.e.
the inverse).
While on it fix `FLIPPED_90` and `FLIPPED_270` to use the correct
axes: flip on the x-axis, rotation on the z-axis.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
`meta_rectangle_transform()` is used in the stack to *compensate* for a
`MetaMonitorTransform` applied to a output, not to apply it again.
Change the function accordingly.
Context:
Experimenting with direct scanout on offscreen-rotated outputs revealed
that the 90/270 degree cases were actually interchanged.
Further digging revealed that we use `meta_rectangle_transform()` with
those values swapped in every single case, papering over the issue.
Either a unintuitive and unexplained `meta_monitor_transform_invert()`
was added, in which case "flipped" values would be wrong, or, in case
of Wayland buffer transforms, the values were swapped by interpreting
the Wayland enums accordingly, see commit 8d9bbe10.
Swapping the 90/270 degree values in `meta_rectangle_transform()`:
1. fixes hardware cursor positioning with flipped output transforms
2. fixes rendering issues with offscreen-rotated flipped output transforms
3. allows us to drop unexplained `meta_monitor_transform_invert()`s in
follow-up commits
4. allows us to make `META_MONITOR_TRANSFORM` and `WL_OUTPUT_TRANSFORM`
enums match again (reverting 8d9bbe10, as already done)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
The following implicit definition for `transform()` did not
correctly apply:
```
a * b = c
c * invert(b) = a
```
Crucially the following did not apply for `FLIPPED-90`
and `FLIPPED-270`:
```
a * invert(a) = identity
```
Fix this by applying the operations, first the flip, then the
rotation, in this order and add tests to ensure correct results
for the requirement above.
Also drop `relative_transform()` as it only had a single user and
can be replaced by `transform()`:
```
invert(a) * b = c
a * c = b
```
As this is not very intuitive, ensure in tests as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
Checking for both bits at once means only one matching bit is
sufficient - very likely in case of `rotate-0'.
This fixes crashes on hardware that does not support 'reflect-'
bits when setting a flipped output transform.
While on it, also update the check for `reflect-y` instead of
`reflect-x` + `rotate-180`. They are logically equivalent,
however some hardware may support `reflect-y` but not both
other bits.
Fixes commit 4e3f3842a1
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
As testing of direct scanout revealed, `META_MONITOR_TRANSFORM`
does actually match `WL_OUTPUT_TRANSFORM` enums. The fact that
things rendered correctly with 90/270 degree values swapped
was because other parts of the stack got the interpretation
wrong, most notably `meta_rectangle_transform()`.
Thus lets revert this change and fix the stack accordingly.
This reverts commit 8d9bbe109b.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2459>
The notification list in the GNOME Shell calendar popup triggers some
interesting interactions when closing a notification:
- Close button is clicked
- The notification animates to be hidden
- The next notification ends up hovered as a result of the animation
- The notification being hovered sets its close button as non-transparent
and reactive
- The pointer is now again over a close button
At this point the reactiveness change should trigger a repick, so that
the new notification's close button is picked, and future button presses
are directed to it, but we do not handle this situation.
To fix this, handle actors becoming reactive so that if the closest
reactive parent has a pointer, it will be repicked again just in case
the pointer is over the newly reactive actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2364
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2532>
The function that currently invalidates pointers over an specific actor
also asserts for the situations where this invalidation makes sense to
happen (i.e. the actor became unmapped, or non-reactive).
We want to have a function that is more forgiving, and that doesn't
enforce any guarantees about the pointer focus actually changing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2532>
We started to report resource changes using prediction when an update
had been successfully committed. While at it, gamma changes were
reported too, but this was problematic, as gsd-color will listen for the
MonitorsChanged D-Bus signal and naively set the gamma again, even if it
didn't change. There aren't currently any actual use cases for being
told when gamma changes from a prediction, so just ignore it and just
report privacy screen changes.
This avoids a feedback loop between mutter and gsd-color.
Fixes: 81b28a1d97
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2531>
Fixes memory leak:
==995170== 936 (40 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 15,090 of 15,641
==995170== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==995170== by 0x4B211D0: g_malloc0 (gmem.c:155)
==995170== by 0x4A56693: meta_wayland_tablet_manager_new (meta-wayland-tablet-manager.c:109)
==995170== by 0x4A56693: meta_wayland_tablet_manager_init (meta-wayland-tablet-manager.c:126)
==995170== by 0x4A3FA95: meta_wayland_compositor_new (meta-wayland.c:626)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: 745cb67988 ("wayland: Initialize the MetaWaylandTabletManager")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 383 (96 direct, 287 indirect) bytes in 1 blocks are definitely lost in loss record 14,733 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A4A8B4: meta_wayland_compositor_update_outputs (meta-wayland-outputs.c:483)
==995170== by 0x4A4ABAB: meta_wayland_outputs_init (meta-wayland-outputs.c:716)
==995170== by 0x4A3FA65: meta_wayland_compositor_new (meta-wayland.c:620)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
v2:
* Use meta_backend_get_monitor_manager. (Jonas Ådahl)
Fixes: 9a4783e364 ("Integrate the monitor manager with wayland")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 288 (96 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 14,607 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A4F973: meta_wayland_init_presentation_time (meta-wayland-presentation-time.c:222)
==995170== by 0x4A3FB04: meta_wayland_compositor_new (meta-wayland.c:635)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: dccc60ec3e ("wayland: Implement stub presentation-time")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 240 (48 direct, 192 indirect) bytes in 1 blocks are definitely lost in loss record 14,428 of 15,641
==995170== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==995170== by 0x4B211D0: g_malloc0 (gmem.c:155)
==995170== by 0x4A3CDB3: meta_wayland_activation_init (meta-wayland-activation.c:383)
==995170== by 0x4A3FB0C: meta_wayland_compositor_new (meta-wayland.c:636)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: ec390b68c5 ("wayland: Implement the xdg-activation protocol")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes memory leak:
==995170== 192 (96 direct, 96 indirect) bytes in 1 blocks are definitely lost in loss record 14,260 of 15,641
==995170== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==995170== by 0x4B21178: g_malloc (gmem.c:125)
==995170== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==995170== by 0x4B0766D: g_hash_table_new_full (ghash.c:1071)
==995170== by 0x4A3F3A4: meta_wayland_compositor_init (meta-wayland.c:477)
==995170== by 0x4E1F509: g_type_create_instance (gtype.c:1929)
==995170== by 0x4E03DFC: g_object_new_internal (gobject.c:2011)
==995170== by 0x4E0538C: g_object_new_with_properties (gobject.c:2181)
==995170== by 0x4E05D40: g_object_new (gobject.c:1821)
==995170== by 0x4A3F8C4: meta_wayland_compositor_new (meta-wayland.c:590)
==995170== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==995170== by 0x10F065: main (mutter.c:148)
Fixes: 8df2a1452c ("wayland: Notify actively of xwayland window/surface associations")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
Fixes potential use-after-free during mutter shutdown, e.g.:
==993876== Invalid read of size 8
==993876== at 0x4A4FCA3: meta_wayland_presentation_time_ensure_feedbacks (meta-wayland-presentation-time.c:373)
==993876== by 0x4A3F07F: on_presented (meta-wayland.c:282)
==993876== by 0x661B7E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==993876== by 0x661A922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==993876== by 0x4DFF4BC: g_cclosure_marshal_generic_va (gclosure.c:1648)
==993876== by 0x4DFE948: _g_closure_invoke_va (gclosure.c:893)
==993876== by 0x4E17498: g_signal_emit_valist (gsignal.c:3406)
==993876== by 0x4E176BE: g_signal_emit (gsignal.c:3553)
==993876== by 0x51D9DB5: clutter_stage_view_notify_presented (clutter-stage-view.c:1226)
==993876== by 0x499ACD2: frame_cb (meta-stage-view.c:83)
==993876== by 0x499ACD2: frame_cb (meta-stage-view.c:43)
==993876== by 0x50CAA41: notify_event (cogl-onscreen.c:175)
==993876== by 0x50CAA41: _cogl_onscreen_notify_complete (cogl-onscreen.c:545)
==993876== by 0x4A877F5: meta_onscreen_native_notify_frame_complete (meta-onscreen-native.c:211)
==993876== Address 0x24b7be58 is 296 bytes inside a block of size 344 free'd
==993876== at 0x484217B: free (vg_replace_malloc.c:872)
==993876== by 0x4E1F88B: g_type_free_instance (gtype.c:2001)
==993876== by 0x49C793C: meta_context_dispose (meta-context.c:675)
==993876== by 0x4E037E0: g_object_unref (gobject.c:3636)
==993876== by 0x4E037E0: g_object_unref (gobject.c:3553)
==993876== by 0x10F145: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
==993876== by 0x10F145: glib_autoptr_clear_MetaContext (meta-context.h:32)
==993876== by 0x10F145: glib_autoptr_cleanup_MetaContext (meta-context.h:32)
==993876== by 0x10F145: main (mutter.c:126)
==993876== Block was alloc'd at
==993876== at 0x483F7B5: malloc (vg_replace_malloc.c:381)
==993876== by 0x4B21178: g_malloc (gmem.c:125)
==993876== by 0x4B395C0: g_slice_alloc (gslice.c:1072)
==993876== by 0x4B39C29: g_slice_alloc0 (gslice.c:1098)
==993876== by 0x4E1F544: g_type_create_instance (gtype.c:1901)
==993876== by 0x4E03DFC: g_object_new_internal (gobject.c:2011)
==993876== by 0x4E0538C: g_object_new_with_properties (gobject.c:2181)
==993876== by 0x4E05D40: g_object_new (gobject.c:1821)
==993876== by 0x4A3F864: meta_wayland_compositor_new (meta-wayland.c:585)
==993876== by 0x49C7FA7: meta_context_start (meta-context.c:412)
==993876== by 0x10F065: main (mutter.c:148)
Fixes: 2ce3a050f0 ("wayland: Wire up presentation-time machinery")
Fixes: 8cff3b84f7 ("wayland/compositor: Process frame callbacks on 'after-update'")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2527>
When we change the privacy screen, we added a result listener to the KMS
update object to notify the upper layer about the privacy screen state
change. This was slightly awkward as one might have changed the state
multiple times for a single update, thus it was necessary to remove any
old result listeners to an update before adding a new one.
Doing this will not be possible when updates are fully async and managed
by the KMS impl device.
To handle this, instead make the post-commit prediction notify about
changes that happens in response to a successfully committed update. We
already predicted the new privacy screen state, so the necessary change
was to plumb the actual change into a callback which emits the signal if
there actually was a privacy screen change.
This will then be communicated via the same signal listener that already
listens to the 'resources-changed' signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2340>
The name had a bit conceptual conflicts with MetaKmsUpdate, as it shared
its namespace but had no relation to it. Fix this by renaming it
MetaKmsResourceChanges (and the corresponding META_KMS_UPDATE_CHANGE_*
to META_KMS_RESOURCE_CHANGE_*). The term "resource" is used since that's
already used in the signal, and the fact that the changes partly comes
from changes in the DRM resource as retrieved by drmModeGetResources.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2340>
With this header we can set a flag to signal that the whole buffer is
corrupt and should be ignored. With this we can cater to all cases:
* Window buffer fine, but cursor broken:
Use the spa_meta_cursor properties like id or offset accordingly
* Window buffer broken, but cursor fine:
Use the chunk flags
* Both are broken / the dequeued buffer is not usable
Use the spa_meta_header flag
Additionally clients can now check if a buffer contains spa_meta_header
data and can thus only check for the new or the old behaviour.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2516>
Since the commit below, meta_crtc_kms_get_cursor_renderer_private has
returned a CrtcCursorData pointer, but this code was still treating it
as a MetaDrmBuffer pointer.
Fixes: fea8ebcca9 ("cursor-renderer/native: Store struct in CRTC private")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2524>
`clutter_actor_iter_destroy` will try to match up the iterator's `age`
with that of the parent ("root") actor:
```
g_return_if_fail (ri->age == ri->root->priv->age);
```
In a simple actor graph that's completely reasonable but somewhere in the
more complex graph of gnome-shell the parent's `age` was skipping ahead
faster than that of the iterator. This could happen in theory if the
destroy indirectly leads to more children being destroyed than the
iterator has visited.
So there's no evidence of actual corruption, only the age check might
fail in a `clutter_actor_iter_destroy` loop because the age check itself
can't handle all possible valid scenarios.
Since our only mandate is to destroy all children, we can do that reliably
without an iterator and thus without assuming anything about the parent's
`age` counter.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4747
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2074>
PipeWire supports flags to signal a corrupted buffer. We should use the
flag SPA_CHUNK_FLAG_CORRUPTED for `chunk->flags` instead of setting
`chunk->size = 0` since the size isn't well defined for arbitrary dmabufs
and should be set to 0.
Sadly clients like obs are using a chunk size of 0 to decide if a buffer
should be imported. Thus we should offer both until clients are using
the flag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2323>
Change meta_seat_impl_notify_discrete_scroll_in_impl to receive 120
based values and report high-resolution scroll values as smooth scroll.
Notify discrete scroll only when the accumulated value reach 120.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
In order to get the delta X/Y value of the
LIBINPUT_EVENT_POINTER_SCROLL_FINGER
or LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS events the new function
libinput_event_pointer_get_scroll_value should be used instead of
libinput_event_pointer_get_axis_value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
Ignore deprecated LIBINPUT_EVENT_POINTER_AXIS events and handle
LIBINPUT_EVENT_POINTER_SCROLL_WHEEL,
LIBINPUT_EVENT_POINTER_SCROLL_FINGER and
LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS instead.
The scroll source is now encoded in the event type making
libinput_event_pointer_get_axis_source and translate_scroll_source
redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
When building the list of formats to be sent as part of the scanout
tranche, avoid requiring modifier support by the DRM driver for
formats relying on implicit modifiers (DRM_FORMAT_MOD_INVALID).
Specifically, the previous check required the DRM driver to have
advertised some modifier support for the given format in its
IN_FORMATS KMS plane property, regardless of modifier it was. If it
hadn't, the format was left out of the list of formats to be sent
in the scanout tranche.
When no formats remained to be sent in the scanout tranche, the
tranche simply wasn't sent.
This resulted in the scanout tranche never being sent for GPUs where
modifiers aren't supported. In those cases, no formats are advertised
using the IN_FORMATS property, and thus the list of formats to be sent
in the scanout tranche remained empty.
Since Mesa doesn't use scanout-compatible buffers for native Wayland
clients unless specifically requested to do so using the "scanout"
tranche flag, it effectively means that direct scanout of native
Wayland clients wasn't supported for GPUs without modifiers support.
Sending a tranche with formats paired with the implicit modifier
(DRM_FORMAT_MOD_INVALID) is both allowed by the protocol and is
already done by default for GPUs with modifiers support, unless the
experimental support for explicit modifiers is enabled in Mutter.
So instead of requiring modifiers to be supported for each format
being evaluated for the scanout tranche, when processing formats
which rely on implicit modifiers, only check if the format in
question is supported by the DRM driver for scanout on the primary
plane.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2510>
While the check for `clutter_actor_has_mapped_clones` clearly indicates
an intention to take clones into account, the following code
does not do so, likely because it predates the introduction of
`clutter_actor_is_effectively_on_stage_view()`.
Switch to that newer API in order to take clones into account. This
avoids unnecessary `wl_surface_send_enter()` and `wl_surface_send_leave()`
events when entering the overview, reducing client work.
This also avoids unnecessarily allocating a `cairo_region_t`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2502>
`clutter_actor_set_child_at_index()` is far from a no-op, even if
the current index is equal to the new one - presumably for good
reasons. For the use-case here we want it to be a no-op though, so
skip calling it if the index already matches.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Unparenting the surface actor when the subsurface object is destroyed
has several issues:
- subsurface actors can be unparented while a close animation is
still ongoing, breaking the animation for e.g. Firefox.
- adding and removing the actor to/from the parent is not handled in
one place, making the code harder to follow.
- if the destroyed subsurface had children of its own, they potentially
stick around until a surface-tree rebuild. This makes the Firefox
hamburger menu not close with the "compositor" backend.
Move the unparenting back to
`meta_window_actor_wayland_rebuild_surface_tree()` and instead just
notify the parent of a state change, if it still exist. This will ensure
a correct mapping between the subsurface node tree and the flat surface
actor list. In case of the closing animation the parent will already be
removed and the call is skipped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501>
Since b443bd42ac, we unmanage a wayland window when clearing its
transient parent. That's to make sure that xdg-foreign doesn't
leave the dialog around after the imported surface was destroyed.
While that behavior is sound, it is problematic to implement it
by unmanaging the window, as that happens entirely behind the
client's back.
Instead, send a close event for the window. Unless the client has
good reasons, it should honor the request. (And if it has good
reasons - like unsaved work - then effectively hiding the window
from both the user and client is probably not the best idea anyway).
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5458
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2499>
Not all windows can be minimized: X11 clients can disable the
functionality, and so do we for windows that aren't shown in
the alt-tab popup or the shell overview, so there would be no
way of getting them back.
While we make sure that we respect that ourselves (keybinding,
window menu, etc.), we don't guard meta_window_minimize(), so
clients or extensions can still minimize a window that isn't
supposed to be minimized.
That can lead to all kinds of issues, from the hidden window
being lost (as far as users are concerned) to a crash when
the minimzed window has a transient parent.
Just add an explicit check to make sure the unexpected doesn't
happen after all, and print a warning if it does.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2491>
The cursor rendering code path used by the screen cast code relies on
the cursor tracker machinery to determine where to blit the cursor
texture, but at the moment the cursor position invalidation is behind
a check for whether the shell is using a Wayland backend. (This code
path used to be Wayland-specific before 00cbcb7ba1 but has been
backend-agnostic since).
This commit removes the check for a Wayland compositor, allowing
cursor drawing to function correctly on X11 when screen casting in
embedded cursor mode.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1780
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2474>
The test case checks that the stage views of hidden actors are
not updated when the views of the visible outer parent change.
The check for the outer parent's updated stage views currently
relies on ClutterFixedLayout not excluding hidden children in
its size request: As the container doesn't contain any visible
children at that point, its size would change to 0x0 and end
up on no stage view (rather than the assumed two).
Avoid that oddity by giving the outer container a fixed size,
so that the visibility of its child doesn't affect the test
when we fix ClutterFixedLayout.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2488>
This adds support for E-EDID extensions. Tags are allocated by VESA and
the CTA has such an extension defined in CTA-861.
The switch in `decode_ext_cta` is empty in this commit because we don't
parse any CTA-861 data blocks, yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2351>
The EDID code is copy from elsewhere, without adapting to conventions
regarding e.g. API and types. Clean this up a bit, as EDID information
will be kept around longer when possible, to be used e.g. by color
management.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2351>
The test aims to test that trying to fetch X11 clipboard content after
Xwayland went away doesn't cause issues. What happens though is that
sometimes the clipboard content doesn't have time to settle (i.e. fetch
mime types etc) before Xwayland gets terminated, which causes flakyness.
Fix this by waiting for the compositor side clipboard owners to finish
setting up before continuing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2484>
The pixel clock determines how fast pixels can be processed. When adding
non-native common modes, avoid adding modes that exceed the max pixel
clock frequency of the native modes. Avoiding these avoids potential
mode setting failures where the GPU can't handle the modeline since the
configured pixel clock is too fast. This replaces the "bandwidth" check
which used the number of pixels and refresh rate, which wasn't enough to
avoid incompatible modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2492>
'screen-cast/monitor-src: Use clutter_stage_paint_to_buffer'
(6c818cd8d5) made the non-dma-buf path use
clutter_stage_paint_to_buffer() to avoid running into direct scanout
issues. At a glance, the dma-buf paths didn't have the same issue since
it explicitly handled dma-bufs by blitting them.
What it also did was move the recording to an idle callback, to avoid
paint reentry issues. A side effect of this, however, is that it also
broke the dma-buf paths, as they rely on the back buffer existing, and
the stage view direct scanout already being setup, which it isn't in an
idle callback.
Fix this by using the dma-buf variant of
clutter_stage_paint_to_buffer(): clutter_stage_paint_to_framebuffer().
This has some negative performance impact, but we can't use
cogl_blit_framebuffer() when using an idle callback for recording.
Potential performance improvements to make things work more as they did
before is to enhance 'cogl_blit_framebuffer()' a bit, making it a vfunc
that could be implemented by MetaOnscreenNative. A flag to say whether
to look at the back or front buffer would let MetaOnscreenNative know
whether to use the already committed-to-KMS buffer, or the current back
buffer.
Fixes: 6c818cd8d5
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2282
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2462>
Fixes leak:
==14889== 2,168 (16 direct, 2,152 indirect) bytes in 1 blocks are definitely lost in loss record 15,308 of 15,584
==14889== at 0x48445EF: calloc (vg_replace_malloc.c:1328)
==14889== by 0x4BAC1D0: g_malloc0 (gmem.c:155)
==14889== by 0x4AAFF60: meta_wayland_dma_buf_feedback_new (meta-wayland-dma-buf.c:298)
==14889== by 0x4AAFFE0: meta_wayland_dma_buf_feedback_copy (meta-wayland-dma-buf.c:317)
==14889== by 0x4AB16B6: ensure_surface_feedback (meta-wayland-dma-buf.c:1121)
==14889== by 0x4AB1848: dma_buf_handle_get_surface_feedback (meta-wayland-dma-buf.c:1169)
==14889== by 0x66F77E9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x66F6922: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==14889== by 0x5318750: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5313B99: ??? (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x5316649: wl_event_loop_dispatch (in /usr/lib/x86_64-linux-gnu/libwayland-server.so.0.20.0)
==14889== by 0x4AA7C19: wayland_event_source_dispatch (meta-wayland.c:110)
Fixes: 64e6bedb6b ("wayland/dma-buf: Add support for scanout surface feedback")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2469>
The MetaKeyboardA11yFlags are used by gnome-shell to show a dialog
whenever a keyboard accessibility feature is switched using the
keyboard.
Unfortunately, commit c3acaeb25 renamed the Clutter flag to Meta and
moved them to a private header. As a result, gnome-shell do not show any
dialog anymore when a keyboard accessibility feature is activated.
Move the MetaKeyboardA11yFlags definition to a public header so that
gnome-shell can use it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2306
Fixes: c3acaeb25 - backends: Move keyboard a11y into backends
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2463>
The min distance to the right/bottom edge depends on Wayland concepts
(wl_fixed_t) and eventually geometry scale. Move the logic the Wayland
side of the pointer constraints machinery to avoid the backend trying to
figure this out without the proper data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
There were some coordinate nudging to avoid running into Clutter
floating point math issues related to coordinate transformations. Over
the years these things have improved, especially with the move to
graphene, so remove the old work around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2460>
The ImplDeviceAtomic converts the MetaKmsPlaneRotation back to the
concrete KMS value. The MetaMonitorTransform is always directly
converted to a MetaKmsPlaneRotation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
Updating the PropTable has the side effect that the parse callback now
also gets called on hotplug but it is used to initialize data. The parse
callbacks are moved to the read_state functions which are aware if this
is an initializing call or just an update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2379>
* creating an actor will result in it being assigned a color state
with the color space sRGB
* creating an actor with a color state passed will result in that
color state being returned
* changing an actor's color state makes that happen
* changing an actor's color state to NULL ends up with it being
changed back to a color state with the sRGB color space
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2443>
ClutterColorState, that is a GObject. each ClutterActor would own
such an object, and it'd be set via a GObject property.
It would have an API to get the colorspace, whether the actor
content is in pq or not, and things like that.
if it is NULL, it will default to color state with sRGB colorspace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2443>
This avoids the following error:
../src/tests/wayland-test-clients/dma-buf-scanout.c💯5: error:
implicit declaration of function ‘close’; did you mean ‘pclose’?
[-Werror=implicit-function-declaration]
100 | close (buffer->dmabuf_fds[i]);
| ^~~~~
| pclose
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2458>
There are no 'features' left, the last one, GLSL shader support, was
moved to Cogl.
This also move the Cogl context creation to a more sensible place, as it
was hidden away in the feature initialization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
The Cogl feature was removed a while back, while Clutter just hard coded
it to TRUE. Lets remove the confusion that GLSL isn't supported and just
remove the (dead) fallback paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2015>
Add `sync_effects_completed()` and `verify_view()` in
order to allow Wayland test clients to trigger verifications
and add convenience functions to use them to client-utils.
Notes:
- `sync_effects_completed()` works in two stages in order
to ensure it doesn't race with window effects. By the time
`sync_effects_completed()` is processed, an effect could
already have ended or not yet been scheduled. Thus we
defer a check for pending effects to the next paint cycle,
assuming that by then they should have been scheduled.
- `meta_ref_test_verify_view()` internally triggers the
`paint` signal for the stage which is why it can not be run
in the after-paint signal handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Version 2 is required for buffer transform, however directly going
for the highest currently supported version doesn't break any
tests and makes more features available.
Also fix indentation below while on it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
Our internal interpretation of output transforms is not in line with
the Wayland spec. Wayland describes them as the transform that a
compositor will apply to a surface to compensate for the rotation
or mirroring of an output device - counter-clockwise.
Mutter in turn interprets it the other way around. One could
argue it does the same but clock-wise - or it interprets the transform
from the viewpoint of the content, not the device.
In either way, the difference is that 90 and 270 degree values are
switched. Thus swap these accordingly when we translate from
`WL_OUTPUT_TRANSFORM` to `META_MONITOR_TRANSFORM`.
See: https://gitlab.freedesktop.org/wayland/weston/issues/99
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1055>
This launches Xvfb, using xvfb-run, and inside tests the following:
1. Launching 'mutter --x11' works
2. Launching a couple of X11 clients works (doesn't crash or result in
warnings)
3. Launching 'mutter --x11 --replace' works
4. Terminating works
It does this using a simple shell script.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
We don't make use of the refresh rate in any useful way in the X11, and
in this case we just ended up with warnings since the refresh rate was
NaN. Fix this by making it 0.0 to mean "no refresh rate". This also is
what 'xrandr' itself reports.
Fixes warnings when launching 'mutter --x11' in Xvfb.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2434>
This adds a minimalistic fullscreen direct scanout test case, that runs
on vkms. It doesn't use EGL, and it uses uninitialized memory, thus it
lacks any kind of implicit synchronization, but it does test that the
scanout selection paths are working.
What is tested is:
* DMA buffer allocated using gbm on top of VKMS
* Buffer passes a mode setting TEST_ONLY check
* Paint is omitted
* Correct buffer active in KMS after presentation
What isn't yet tested:
* Implicit synchronization related behavior
* Presented pixel content
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2417>
They're just typedefs to CoglObject and CoglObjectClass, respectively,
and the latter is unused already. The former is used in a couple of
deprecated headers, which can easily be changed.
Change all CoglHandleObject instances to CoglObject, and drop the types
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2355>
There is no need to make CoglJournal a CoglObject, nor any kind of
object for that matter, since it doesn't require refcounting at all.
CoglJournal is entirely private to, and managed by, CoglFramebuffer,
and it only needs to create and destroy it.
Make CoglJournal a free-form struct, and adjust CoglFramebuffer to
call _cogl_journal_free() instead of cogl_object_unref().
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2087
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2355>
Cleanup all the boilerplate, and port the function to use the auto
generated private helper. Remove the manual autocleanup declaration
since this is now done in the clutter-image.h header.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2355>
We passed the pointer to a GError * as user data on an async I/O call.
The callback function didn't make use of it, so it was never written to,
thus remained NULL, thus was dead code. Remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2446>
It works by using an X11 client to set the clipboard content, using a
mimetype that on purpose is not handled by the clipboard manager. The
test then makes sure we don't crash when trying to transfer data from
the old X11 selection source.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The Xwayland server can go away at any time; when this happen we might
have a test client running, and for it to tear down more nicely, make
sure to avoid trying to clean up X11 resources on the old X11 display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
Xwayland can disappear at any time, for example during a new_async() or
read_async() call. When we eventually finalize the stream, the X11
display it was created for is gone, thus can't clean up the X11
resources. Handle this by making the MetaX11Display pointer a weak
pointer, and ignore cleaning up if it disappeared. This is fine since
the X11 server it created those resources one is gone already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2364>
The property doesn't necessarily exist when using drivers that doesn't
support atomic mode setting, and the way it worked will break night
light and other gamma related features. This makes things use the gamma
length; if it is higher than 0, it definitely supports it one way or the
other, i.e. GAMMA_LUT with the atomic backend, and drmModeCrtcSetGamma()
with the legacy/simple backend.
Fixes: 364572b95c
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2287
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
It doesn't depend on whether the CRTC is active or not, so always read
it. This is also useful to know whether a CRTC supports gamma, before it
is being turned on, without relying on the existance of properties.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2435>
The COMPOSITOR_GRAB event route has effectively been replaced by
ClutterGrabs, which are no longer covered by the existing check.
So check for grabs as well to restore the old behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
The event-route is never set to COMPOSITOR_GRAB nowadays, so the
condition will never be met.
Furthermore, it is expected that ClutterGrabs only happen when
events are routed normally, so the remaining NORMAL check should
already fully cover the old COMPOSITOR_GRAB case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
We already bypass wayland if there is a ClutterGrab, so the case
that used to be covered by the event-route check is already handled,
and we can just remove the obsolete check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Since the new ClutterGrab API replaced the old plugin-modal hook,
the event-route is never set to COMPOSITOR_GRAB.
The code in question already checks whether the stage has a grab,
so we can just remove old checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2436>
Initializing the event mask, SubstructureRedirectMask in particular,
before taking the manager selection fails with BadAccess. Fix this by
initializing said mask after taking the manager selection.
This fixes `--replace`.
Fixes: eb4307c350
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2432>
The code is already trying to avoid creating new laters when there
already is one for the queue type, but this wasn't working because the
ID of the later was never stored after creating a new one. This would
then result in as many laters as meta_display_queue_window() was called
and all of them would run the handler function, even if only the first
one had a non-empty window queue.
Similarly this was causing the later to not be removed if the window
queue got empty after meta_display_unqueue_window().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
Currently the signal is getting emitted accidentally, because even when
removing a window from the queue, the later handler of that queue will
still get run due to a bug. This bug is going to get fixed in the next
commit, but some things might depend on the signal getting emitted when
the visibility of a window has changed.
This change affects the behavior in two ways. First the signal is now
emitted immediately rather than from an idle. And second it now
correctly includes the window in the should_show or should_hide list.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2414>
The compositor currently only updates the topmost window actor that is
visible to it after stacking changes. The visibility of a window actor
to the compositor however might only change via the display idle queue
after the stacking changes. This could then lead to the topmost window
actor being assumed to be NULL on Wayland after switching from an empty
workspace or when opening the first window on an empty workspace. The
result of this is direct scanout being disabled in these cases.
To fix this also trigger the update when the visibility of windows
changes.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2413>
Some windows span the entire screen but still use transparency, such as
the desktop window of Nemo. When these windows were used for direct
scanout, the transparent areas would turn black and nothing else would
be rendered.
In addition to checking the surface for opaqueness, for X11 windows also
the window actor itself has to be checked, because its opacity might
have been changed via _NET_WM_WINDOW_OPACITY.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2263
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
This replaces the API to get the topmost surface actor with an API to
get the surface actor that could be a candidate for direct scanout. The
advantage of this is that it allows X11 and Wayland specific
restrictions for these actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2409>
It's not allowed to call eglQueryWaylandBuffer() if the call to
eglBindWaylandDisplay() failed, and will result in an assert being hit
in mesa if called.
Avoid that by keeping track whether we succeeded to bind, and only
attempt to realize a legacy EGL wl_buffer if binding succeeded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2415>
Mutter makes use of a gsettings scheme that comes from
gnome-settings-daemon to check for the screen orientation.
In use cases where gnome-settings-daemon is not available,
this would lead to a crash as the key doesn't exists
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2398>
The monitors settings such as the privacy screen property is propagated
to the monitors via kms updates, however during initialization and
on monitors changes, we end up clearing the pending KMS updates because
such settings are added to the queue before the backend has fully
initialized the monitors, and this may lead to discarding all the
pending updates, including the one we've just planned.
To avoid this, move settings applications after we've both initialized
the backend and notified it about changes.
Also avoid to try set the settings during actual initialization, but
delay that after post-init.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2372>
Prior to 'compositor: Destroy actors when unmanaging', window actors
were destroyed when the compositor object was destroyed, long after the
windows were unmanaged, however, when this instead changed to happen
when unmanaging, with the original goal to avoid having these actors try
to interact with the disposed MetaCompositor instance, it caused an
issue where window actors would be indirectly destroyed as a side effect
of their parents being destroyed, which caused some fallout in the logic
handling window-close animation tracking, which relies on
meta_window_actor_queue_destroy() being called before a window actor is
actually destroyed.
Fix this by unmanaging windows before unmanaging the compositor.
From an X11 point of view, this should be harmless, since all it really
do is call XCompositeUnredirectSubwindows().
For the native backend and the common behavior, all unmanaging the
compositor instance does is destroy clutter actors, so doing so after
window actors were already cleaned up should not be a problem, as this
was the case before too.
Fixes: 35ac3a096d
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5330
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2403>
Quoting Ray Strode:
we don't expose a way to explicitly save the session in gnome anymore
afaik, and I don't think it's going to show on log out because
I believe we use the FORCE flag from the log out dialog.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2370>
A slightly annoying "feature" of Clutters debug messages is that it also
logs the filename and line of the current debug message. If you don't
have an ultrawide monitor, this can be very annoying and cause lots of
linebreaks in the debug logs.
So remove that debugging feature and no longer log the filename and
line number with debugging messages.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2378>
'kms/impl-device/simple: Get the buffer handle from MetaDrmBuffer'
changed how fb ids are generated, but it only made it fully work with
atomic mode setting. For legacy/simple mode setting, it only handled the
primary plane buffer, not the hardware cursor.
Fix this by making sure the fb id is generated also in the legacy mode
setting case.
Fixes: ea39142da2
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2250
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2397>
When an X11 window becomes an all-workspace window its `workspace` is
set to NULL before `meta_window_x11_current_workspace_changed()` is
called. The latter then checks for `workspace` being NULL (which also
happens when unmanaging) and then returns early. So this does not update
`_NET_WM_DESKTOP` to 0xFFFFFFFF. Instead it remains at the workspace the
window was on before. This was causing programs like `wmctrl` to switch
to this old workspace when activating such a window.
Fix this by checking if the window is unmanaging instead.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2242
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2387>
Simply signal preedit string changes from/to NULL once, in order
to avoid unwanted activity in the client side. We do still need to
send the preedit once each .done event, if there is one, in order
to behave according to the protocol when it matters the most.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2395>
With the unthrottled input emission, we ended up often getting the
cursor updates long before any damage had been posted, meaning that if
you moved around the mouse pointer where the mouse had a high enough
refresh rate, we'd effectively stall the screen cast stream by only
sending cursor updates and nothing else.
Fix this by scheduling an update when we get a cursor update, then
sending a cursor-only frame after any damage and relayout has been
processed, but only if there is no queued damage that will cause an
actual repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This is a signal that will be emitted between the 'before-update' and
'before-paint'. It can be used to handle things when you know whether
there is an update, and you know whether a paint or not will happen, by
looking at the current damage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2393>
This handle is used by the legacy KMS API; lets avoid having to have GBM
specific code where this is done by letting the MetaDrmBuffer API, that
already has this information, expose it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2275>
We'd put the message in a variable called `message`. If something passed
to meta_topic() was called `message`, it'd end up being `NULL` in the
log entry. Avoid this by making the local message variable a bit more
"on topic".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2391>
Mutters event filter can prevent events from getting processed by
Clutter, this can also happen for TOUCH_END/CANCEL events. Processing
these events in Clutter is crucial for proper tracking of touch
sequences though, that's because Clutter adds a PointerDeviceEntry to
the stage on a TOUCH_BEGIN *before* going through the event filter, but
removes that entry on a TOUCH_END *after* going through the filter. So
Clutter really needs to see those TOUCH_END events, or else there will
be a stale PointerDeviceEntry on the ClutterStage.
Make sure those TOUCH_END/CANCEL events always get seen by Clutter by
removing the device entry immediately when those get filtered out.
Because there might still be events belonging to this sequence in the
event queue of the stage, we need to flush the queue before removing the
entry, too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2350>
Unfortunately we cannot do this generically since the target of the
button/touch press does matter, e.g. tapping on the OSK, or clicking
the IBus candidates window. These situations should not trigger a
reset.
So be more selective about the situations where button/touch presses
trigger an IM reset, in the case of ClutterText these are still clicks
inside the actor, for Wayland's text-input it is when clicking the
surface that has text_input focus.
For all other situations where clicking anywhere else might make
sense to trigger an IM reset are covered by the focus changing paths,
that also ensure a reset before changing focus between surfaces/actors.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1961
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit string before changing focus. In addition,
we do not want the preedit string to be able to move between
windows/applications.
Ensure that the commit string is committed when the IM deems so, and
ensure we send a .done event disntinct to the .leave event, so that
the client doesn't miss the commit.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2030
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Focus changes should trigger an IM reset, as some engines do want
to maybe commit the preedit buffer before changing focus. Since
the preedit string is also cleared on reset(), we can do without
that explicit call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
Right now we have a bit of a mixed bag between an active model where
input foci set the surrounding text without being asked for (e.g.
wayland's text_input), and a passive model where the IM engines ask
for content.
Make ClutterText take the same side than text_input, so that dealing
with those is at least consistent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
The clutter_text_delete_text() function used underneath expects character
offsets for both start/end position. Fix the end position passed an offset
instead of that, and compesnate for the cursor position being always -1
when the caret is at the end of the string.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2384>
I've overseen quite an important case in commit
98a5cb37d9: Repicking only when actors get
destroyed is not enough, we actually need to repick when actors go
hidden/unmapped.
While we could also listen to notify::mapped just like we listen to
notify::reactive, it seems better to avoid using property notifications
here due to the usage of g_object_freeze/thaw_notify() in ClutterActor.
It can lead to the stage receiving a notify::mapped with mapped = true
for a pointer actor, which really shouldn't happen (just like
notify::reactive with reactive = true shouldn't happen).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5124
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2333>
DMA buffers might be allocatable, but it doesn't mean the driver doesn't
fail when we try to allocate a buffer with an implicit modifier. Using
the proprietary NVIDIA driver for example, it will fail. Lets catch this
up front and avoid advertising DMA buffer support when we know it won't
work.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2383>
As of currently, we only emit .done() on actual changes coming from the
ClutterInputMethod/ClutterInputFocus. With the recent changes in the
interpretation of serials, it becomes more important now that the
compositor acknowledges every .commit done by the client, in order to
keep them feeding future IM state updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
Compensate the protocol statelessness with our ClutterInputFocus
statefulness. This becomes more necessary now, since sending
consecutive .done() events is now considered acceptable behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2365>
MetaCursorRendererNative only updates the cursor state when the
underlying texture changes. The cursor scale and transform do not
trigger updates. This results in wrong cursor orientations on rotated
displays. Use both texture changes and scale and transformation changes
to figure out when to update the cursor state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2363>
We want all pointer events to be passed through the pointer a11y
processing before going through event filters: Once we go through event
filters, events might be dispatched to Wayland and get filtered out.
With the changes to immediately dispatch events to wayland, this changed
and the pointer a11y is now no longer seeing any events going to wayland
clients. Fix it by shuffling things around a bit and letting pointer
a11y take a peek at events earlier.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5192
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2332>
There's a bunch of crashes right now where the assertions in
clutter_actor_set_mapped() after calling the map/unmap() vfuncs are
failing. The only way this can happen is by re-entering
clutter_actor_set_mapped() during the map/unmap recursion.
The reason for those crashes is that the shell hides/shows some actors
in response to crossing events and key-focus changes. These in turn get
triggered by the newly introduced ungrabbing of ClutterGrabs when an
actor gets unmapped, which triggers GRAB_NOTIFY crossing events and
key-focus changes.
Since these situations are hardly avoidable (it's a valid use-case to
hide/show something in response to a crossing/key-focus event), catch
the set_mapped() call early while we reenter the mapping machinery and
log a warning instead of crashing.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3165
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2299>
With the introduction of untrottled event delivery to wayland clients,
we moved the _clutter_event_process_filters() call outside of
_clutter_process_event(). This also moved the processing of event
filters outside of the timespan where the event is added to Clutters
current_event stack, making Clutter.get_current_event() no longer
available to anything happening inside mutters event filter.
One thing that happens in mutters event filter is detecting and
triggering keybindings like the alt-tab switcher. Now the alt-tab
switcher has a special case where it finishes and activates a window
right when the keybinding gets activated, relying on the current event
time as the timestamp to activate the window.
Now since the current event time is no longer available from inside
mutters event filter, we'd pass 0 to meta_window_activate(), causing
mutter to send a notification instead of actually activating the window.
To fix this, also set a current_event for the ClutterContext when going
through event filters, this makes sure Clutter.get_current_event_time()
works when called inside keybinding handlers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2327>
When switching between the existence and not of a stage ClutterGrab, we
would correctly attempt to synchronize key focus from the perspective of
the Wayland clients.
But this synchronization should do its own checks about existing stage
grabs before determining a client window has key focus or not.
Add that check, so that grabs correctly unfocus the keyboard in Wayland
clients, in addition to pointers and touch.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2194
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2366>
When we get passed a "snippet" to the shaped texture, it's added as a
pipeline layer snippet to change how the source texture is sampled. When
we draw from a texture tower however we have allocated regular textures
which doesn't need any special layer snippet, so create separate
pipelines for those that doesn't use that snippet.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/528
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2278>
In the right combination of circumstances, and given 2 actors (parent
actor P with an offscreen effect and child actor C), we may have the
following situation happening:
- A redraw is queued on the actor C, actors C and P are marked as
priv->is_dirty and priv->propagated_one_redraw.
- During paint() handling we paint actor P, priv->propagated_one_redraw
is turned off.
- We recurse into child actor C, priv->propagated_one_redraw is turned
off.
- A new redraw is queued on actor C, actors C and P are marked as
priv->is_dirty and priv->propagated_one_redraw.
- The paint() method recurses back, actors C and P get priv->is_dirty
disabled, priv->propagated_one_redraw remains set.
- At this point queueing up more redraws on actor C will not propagate
up, because actor C has priv->propagated_one_redraw set, but the
parent actor P has priv->is_dirty unset, so the offscreen effect will
not get CLUTTER_EFFECT_PAINT_ACTOR_DIRTY and will avoid repainting
actor C.
The end result is that actor C does not redraw again, despite requesting
redraws. This situation eventually resolves itself through e.g. relayouts
on actor P, but may take some time to happen.
In order to fix this, consider actors that did get a further redraw
request still dirty after paint().
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2188
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2353>
Simplify the function arguments (the origin is just the actor that
the function is originally called from), and make it also handle
marking as dirty the actor that got the redraw queued up explicitly.
This makes it a single place where priv->is_dirty is being enabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2353>
With Xwayland on demand, a number of maintenance X11 applications need
to be run first, before Xwayland starts accepting requests from the
normal clients, as soon as the WM_S0 selection is acquired by mutter.
On startup, mutter also sets a number of X11 properties that can be
queried by X11 clients.
Unfortunately, mutter acquires the WM_S0 selection before setting those
properties, so mutter and the first regular X11 client will race on
startup.
As a result, the X11 properties set by mutter on startup may not be
available to the very first X11 client when Xwayland starts.
To avoid that issue, make sure to take the WM_S0 selection last when
opening the display.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2176
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2336>
Currently, meta_xwayland_shutdown_dnd() is called from the handler
on_x11_display_closing() triggered from the signal "x11-display-closing"
hooked up from meta_xwayland_init_display().
Once the signal has been triggered, on_x11_display_closing() removes the
signal handler, disconnecting from the signal.
As meta_xwayland_init_display() is called from meta_display_new() which
is issued only once, the signal handler is not restored again.
As a result, meta_xwayland_shutdown_dnd() is not called anymore after
Xwayland has been restarted, but meta_xwayland_init_dnd() will check and
assert that the manager's DND object is NULL.
Basically, restarting Xwayland more that once will trigger an assertion
failure in mutter. That's even more of a problem with autoclose-xwayland
where Xwayland is expected to terminate when there is no meaningful X11
client remaining, which can happen multiple times during the lifetime
of a user session.
To make sure that meta_xwayland_init_display() is called for every new
instance of Xwayland, simply keep the signal hooked in place by not
disconnecting it when triggered.
This reverts commit 9a10b8ff94.
Even though, originally, this issue was first introduced with commit
b4fe1fdd95 ("xwayland: Make setup/teardown
a bit more symmetrical") which didn't actually kept 'x11-display-setup'
and 'x11-display-closing' connected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2168
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2339>
For wayland meta_window_move_to_monitor sends a configure to the client
without actually moving the window, yet and the
meta_display_queue_check_fullscreen call won't detect any changes.
Checking for fullscreen in meta_window_update_monitor fixes the problem
because it is called whenever the window actually changed the monitor it
is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2325>
We rather confusingly still call a secondary display card that is
GPU-less (DisplayLink or other basic KMS device) a "secondary GPU",
so just because secondary_gpu_state is non-NULL doesn't mean we
can use it for rendering. The clearest indication of this is when
there is no EGL surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2341>
Since devices may be multiple things now, check all capabilities in order
to ensure all aspects of the device are correctly configured.
This change does the following observations:
- Devices that have TOUCHPAD | POINTER capabilities prefer the 'touchpad'
settings path. The regular pointer settings path is left for all
non-touchpads.
- Devices that are both a tablet and a touchscreen prefer the tablet
relocatable schema. This works for both aspects as the touchscreen
schema is a subset of the tablet one.
Other than that it's a rather boring, even if verbose search and replace.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We not just have X11 devices, but also virtual devices on both backends.
In the mean time, keep these working on top of a ClutterInputDeviceType,
but transform that into capabilities on device construction so users can
rely on the new flagset.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We do not need to open code the ClutterInputDeviceType fetching from a
libinput_device, since we already created a native ClutterInputDevice that
has the right type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
We use meta_workpace_focus_default_window() to sync the input focus back
to a window after it was on shell UI, this is not really necessary on
Wayland, but it is on X11. What this function does internally is ask
MetaWindowStack about the topmost window and focus+raise that window.
In gnome-shell we set the input focus to the default window every time
the key-focus changes to NULL (see shell-global.c ->
sync_stage_window_focus()). Now when closing the alt-tab switcher and
activating a window while there's an always-on-top window on the
workspace, meta_workspace_focus_default_window() will focus that
always-on-top window right after closing the alt-tab switcher, making it
impossible to focus another window using alt-tab.
To fix this, make meta_workspace_focus_default_window() check if there's
an existing focus_window first, if there is, use that, and if there
isn't, resort to just focusing the topmost one.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5162
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2328>
This fixes instances of:
```
*** BUG ***
In pixman_region32_init_rect: Invalid rectangle passed
Set a breakpoint on '_pixman_log_error' to debug
```
seen when navigating the overview and launching apps.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2349>
The ClutterGestureAction base code would correctly try to cancel a
gesture if it would receive GRAB_NOTIFY leave events (that would indicate
other portions of the actor tree stole input away from the gesture actor),
but it would mistakenly do so only if the gesture was already initiated,
possibly leaving stale point information if the gesture collected input
but didn't initiate yet.
This could be indirectly seen clicking with the mouse on OSK keys with
no motions in between, clicks would accumulate on the swipeTracker
gestures until the trigger point, so the third click could drag the
workspaces.
We do always want to unregister the related device/sequence here, do that
while still cancelling any already initiated gesture.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1907
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4987
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2334>
This commit makes the KVM tests run in special VM runners tagged with
the 'kvm' tag. In order to avoid building the kernel image used for
running the tests each pipeline, it's built as part of the CI image
building.
For now, KVM tests are only run on the x86_64 architecture. The reasons
for this are two that the kernel image building script doesn't yet handle
any other architecture than x86_64 due to differences in how the image
is built and handled, as well as the fact that there only exists a kvm
tagged runner for x86_64.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2152>
This will allow us to reuse the keys and values more easily, as later
commits will rely on being able to iterate over the keys and values to
construct explict env strings for passing into special test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2152>
Previously, we would only check for EXT_swap_buffers_with_damage which
generally will find an implementation. However, some EGL implementations
do not appear to support that naming of the extension, preferring to
only advertise KHR_swap_buffers_with_damage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2316>
We use get_window_for_event() to check whether an event happened on top
of a window or on top of shell UI to decide whether to bypass delivering
the event to Clutter. In case of crossing events though, we can't just
use the device actor to determine whether to forward the event to
Clutter or not: We do want to forward CLUTTER_LEAVE events which
happened on top of shell UI. In that case the device actor is already a
window actor (the pointer already is on top of a window), but the shell
still needs to get the LEAVE crossing event.
Since the event source actor got removed from the detail of
ClutterEvent, the context we're looking for (which actor did the pointer
leave) is now the target actor that the event gets emitted to. Since the
last commit, we also made event filters aware of this context by passing
the target actor to them, so use this context now to determine whether
we're on top of a window or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321>
We'll need the additional context of which actor the event will be
emitted to in mutters event filter (see next commit), so pass that
target actor to the event filters that are installed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2321>
Before scanning out the surface of a native client we have
to check the following attributes that influence the
relationship between buffer and the defined result on screen:
- buffer scale
- buffer transform
- viewport
In the future we can loose these checks again in cases where the
display hardware supports the required operations (scaling, cropping
and rotating).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2276>
Prior to 67033b0a mutter was accidentally including sizes for
configurations that were just focus state changes. This was not leading
to any known problems on the client side, but it was causing issues in
mutter itself when detecting whether a resize originated from the client
or the server.
Not including sizes in focus change configurations anymore however
revealed a bug in gtk. It was storing the window size when in a fixed
size mode (tiled/maximized/fullscreen), but not on any other server side
resizes. It was then restoring this stored size whenever there was a new
configuration without a size while in floating mode, i.e. the focus
change configurations generated by mutter after 67033b0a.
This change now addresses the issue 67033b0a was fixing in a way that
restores the previous behavior of always including the size whenever
sending a configuration.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2091
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2238>
Instead of having different coverage outputs for different architectures
and compilation flags, have each of those tests run coverage in order
to generate a JSON report, and have that merged at a final common job.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2315>
Running meson test from the build directory in a jhbuild environment
picks up libraries which have been installed previously because
LD_LIBRARY_PATH takes precendence over RUNPATH. Make the linker generate
the RPATH tag again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2307>
If the remote desktop service emits absolute input events (e.g. absolute
pointer events) before the stream has started streaming, we don't have a
virtual monitor, as the size has not been negotiated yet. When this
happens, just drop the event. Remote desktop services should probably
make sure not to send events before the streaming has started, but them
doing so anyway shouldn't trigger a crash, which would be the case
otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
This test resizes the stream by updating the PipeWire stream properties.
This triggers a format negotiation, that results in the buffers being
reallocated with the new size. The test makes sure we eventually
receive this new size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
Keep the virtual monitor around if it's being resized. This reduces the
number of unnecessary object rebuilding that happen during monitor
rebuilding.
This changes finalize() vfunc into a dispose() vfunc in the abstract
stream source object implementation, as it needs the abstract stream
source object to close the stream early, so that various signal
listeners get disconnected early.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1904
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
We'll change mode's on-demand so using IDs identical to the virtual
monitor ID would mean IDs didn't change when changing mode, and that is
rather unintuitive. IDs don't mean much anyhow, just make them grow
within the realm of a 63 bit unsigned integer, as the 64th bit means its
a virtual mode ID. Making sure the ID is in the virtual mode namespace
is handled by meta_crtc_mode_virtual_new().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2270>
In some configurations (e.g. NVIDIA driver 470) Xwayland may use DMA
buffer for passing buffers around. When this is done, we might attempt
to scanout these buffers when they are fullscreen, and to do so we
import them using gbm.
However, for the mentioned configuration, there is no gbm device
available for importing. This was not handled, and resulted in a crash;
avoid this crash by checking whether we have a gbm device and fail
gracefully if we don't.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2098
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2318>
This aims to replace the x,y arguments in wl_surface.attach(); meaning
it can be used more sanely together with EGL, and at all when using
Vulkan.
The most common use case for the offset is setting the hotspot of DND
surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1905>
This implements the new 'bounds' event that is part of the xdg_toplevel
interface in the xdg-shell protocol. It aims to let clients create
"good" default window sizes that depends on e.g. the resolution of the
monitor the window will be mapped on, whether there are panels taking up
space, and things like that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
We'd guess the initial monitor before it was actually calculated by
looking at the initial geometry. For Wayland windows, this geometry was
always 0x0+0+0, thus the selected monitor was always the primary one.
This is problematic if we want to provide initial more likely
configurations to Wayland clients. While we're not doing that yet, it'll
be added later, and this is in preparation for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
This will later be used to tell Wayland clients about a size they
shouldn't exceed.
If the window doesn't have a main monitor, this function does nothing
and returns FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2167>
It does not make sense that the event "source" (aka the target) is
both content and recipient of a message. Not doing so, events become
largely independent of the actor that is receiving/handling an
event. This is small step toward making events opaque and immutable.
Every user of these API calls in our code have ported away from
them, but other users may remain in extensions, so make these
functions work on top of the alternative API without accessing the
soon to be removed event field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2311>
This is just "necessary" for --nested stages, since the pointer is
allowed to leave the stage in that case. Since the only side effect
is that there is still a pointer focus somewhere inside the stage,
simply drop this.
This is a small leftover of commit b8f92a6ce4, since we stopped
handling the double ENTER event there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2311>
In addition to the presented callback time, it shows the time to the
reported presentation time (which can be earlier or later than the
presented callback), as well as the GPU rendering duration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1928>
gnome-desktop is used to retrieve the monitor vendor name which in some
use cases is not needed as it brings a bunch of gnome-desktop unwanted
dependencies.
The change makes mutter fallback to an "Undefined" vendor name if it is
built without gnome-desktop
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2317>
Return in meta_egl_choose_all_configs() the actual number of
configurations returned by eglChooseConfig(), which are not
necessarily the same number as those from eglGetConfigs().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2303>
Since the introduction of ClutterGrabs, MetaDnd now no longer gets
notified about input events on the stage during grabs (for example while
the alt-tab popup is shown) and thus can't move the grab feedback actor
anymore.
To fix this, forward events to MetaDnD directly from
meta_display_handle_event() when a ClutterGrab is in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
We get the MetaWaylandCompositor a bunch of times, but we can do with
getting it only once and then also replace the is_wayland_compositor()
checks with a if (wayland_compositor).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2308>
The XDG activation support was missing interoperability with other
startup sequences, notably those coming from other means than XDG
activation.
In order to play nice with X11 startup sequence IDs, we not just
have to check for the startup ID being in the general pool, but
we also need to fallback into X11-style timestamp comparison so the
window ends up properly focused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2314>
When a drag and drop occurs from an X11 client to a Wayland native
client, mutter uses an internal X11 window as a peer for the DnD drop
site.
That internal X11 window is moved and resized to match the Wayland
native windows as the drag destination moves.
When moving from one Wayland native window to another Wayland native
window, the same X11 window is used, and as a result no DND enter/leave
events is emitted.
In that case, the drop may occur on the wrong Wayland native window,
because no new XdndEnter/XdndLeave event were emitted.
To avoid that issue, use a pair of X11 windows instead of just one and
alternate between the two when repicking a new drop surface, so that
moving from a Wayland surface to another will always generate the
expected enter/leave events that we rely on.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2136
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2305>
When generating the action label, we expect both directions of these
features to have consistent settings (either both get a keycombo, or
they don't) or these just return NULL altogether.
Since one of the directions has an action associated, this is
misleading, so be more lenient at the time of generating the action
label.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2001>
The distribute_natural_allocation() function was copied over from Gtk to
Clutter 11 years ago with commit e636a0bbce.
Gtk only supports integers sizes in its layout machinery, while Clutter
does everything using floats.
Since this function sets the minimum_size (the size we allocate the
children in the end) to an integer, this means we're implicitly
typecasting floats to integers here, effectively floor()'ing all sizes
that we allocate the box children.
A bug this caused in gnome-shell was that a scrollView (like the one in
the endSessionDialog) was showing scrollbars even though the content
perfectly fit inside the view: Say the content and its scrollView parent
request a size of 63.9 px, but get allocated a size of 63 px by a box
layout. Now the scrollView notices that its allocated size is smaller
than the requested size and thus shows a scrollbar.
So fix that and use floats in distribute_natural_allocation() instead of
integers, as we do everywhere else in the layout machinery.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2284>
If we happen to handle a CLUTTER_TOUCH_BEGIN without a corresponding
CLUTTER_TOUCH_END at MetaWaylandTouch, we would still attempt to
reuse the older MetaWaylandTouchInfo, resulting in an assert triggered
as there is a stale touch reference on the previous surface.
Warn in place and create a new touch info struct to still fix the
broken surface accounting, instead of finding out the hard
way after the surface is destroyed. The assert is preserved to ensure
the accounting does not sneakily break anymore/further.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/584
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2251>
It passes a MetaLogicalMonitor, which isn't introspected right now, so
skip it completely. The entry point to the UI is handled via
MetaDisplay, so it isn't needed.
This fixes the following warning:
<unknown>:: Warning: Meta: (Signal)monitor-privacy-screen-changed: argument object: Unresolved type: 'MetaLogicalMonitor'
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2287>
Structure tests in a list of dictionaries, instead of requiring each
test to have its own executable(...) and test(...) statement. The
intention of this is to make it easier to add more test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2262>
It already was built into it without any symbols exported, but also
duplicated in test cases that used it. Make it so that the built in
functions are exported, with prefixes, and make all tests use the
exported functions. While at it, make things go via MetaContext or
MetaBackend depending on how early in initialization things are run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2262>
We update some details like the last used device and pointer visibility
from events, but this is done inconsistently on X11 since the
ClutterEvents are created and pushed from an additional place.
Make these updates happen on a private call, that will be called from
these places in X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
Even though it's great that XI2 has an event to notify about device
changes, this is something we can let the MetaBackend code handle
consistently for all backends, since looking for the source device
works everywhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
Instead of relying in the device being updated from different parts of our
machinery for different backends, hook this up to our own event dispatching.
This will allow dropping all other places where this is done.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
We create a cursor renderer per device for those at
meta_seat_native_handle_event_post() with PROXIMITY_IN events, but
the MetaWaylandTabletTool handles the event before that, and goes
with a NULL cursor renderer.
Make MetaBackend::get_cursor_renderer() on the native backend create
those cursor renderers on demand, and only handle PROXIMITY_OUT in
handle_event_post() to dispose those. This makes MetaWaylandTabletTool
happily get a cursor renderer again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/285>
We now only enable DMA buffer based PipeWire screen casting if a
format/modifier has been negotiated. This practically means a consumer
is aware about what is needed, and we should not try to predict that it
uses the DMA buffer the right way (i.e. not mmap:ing directly).
However, in case we're not hardware accelerated, we never want to
attempt to use DMA buffer screen sharing, as we want to avoid
compositing into a DMA buffer on such hardware as doing so can be very
slow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2086>
meta_window_(un)queue() was implemented with global arrays in window.c
that managed MetaLater handle IDs and lists of window queues. In order
to rely less on scattered static variables and making it clearer that
we're dealing with per display window management and not something
specific to a single window, move the window resize/calc-showing queue
management to MetaDisplay.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
It's still used by e.g. GNOME Shell to produce fallback icons for X11
applications that doesn't come with a .desktop file. Geometry stays in
the generic class because it's used for minimize animations and is
configured by the panel (e.g. the one in gnome-shell-extensions).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
The comments in this function tells a story of C programmer self
reflecting about data types and Perl. While that can be nice, the rest
consisted mostly of repeating what the code line below did, with the end
result being that the function didn't fit on screen, resulting in worse
readability overall.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2264>
When handling lid state, we used to update the idle time right after
opening the lid. This behavior changed in commit 14b6c8780d due
to a typo/thinko, "if (lid_is_closed)" used to be an early return
condition before updating idle time, now it only updates in that
case.
Restore the original behavior, since this idle time update is key
in having gsd-power light up the display again, this presumably
fixes situations that required extra "light up" hints after suspend.
What it does surely fix is "ninja test" in g-s-d against recent
mutter, since the behavioral change induced a test timeout there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2272>
The `ensure_x11_unix_perms` function tries to detect systems on which
/tmp/.X11-unix is owned by neither root nor ourselves because in that
case the owner can take over the socket we create (symlink races are
fixed in linux 800179c9b8a1e796e441674776d11cd4c05d61d7). This should
not be possible in the first place and systems should come with some way
to ensure that's the case (systemd-tmpfiles, polyinstantiationm …). That
check however only works if we see the root user namespace which might
not be the case when running in e.g. toolbx.
This change relaxes the requirements such that in the root user
namespace we detect and abort if a vulnerable system is detected but
unconditionally run in toolbx.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2261>
Add some debug logging that allows checking whether we're using DMA
buffers for screencasting or system memory buffers. This can be useful
for debugging screencasting performance and CPU usage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2256>
With the ability to query the renderer for DMA-BUF support we can
announce support for implicit modifiers. This allows PipeWire to check
for matching modifiers while negotiation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
Returns TRUE if the active renderer backend can allocate DMA buffers.
This is the case hardware accelerated GBM backends, but FALSE for
surfaceless (i.e. no render node) and EGLDevice (legacy NVIDIA paths).
While software based gbm devices can allocate DMA buffers, we don't want
to allocate them for offscreen rendering, as we really only use these
for inter process transfers, and as buffers allocated for scanout
doesn't use the relevant API, making it return FALSE for these solves
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1939>
There may be situations where we may stack a ClutterGrab on top of a
wayland popup's. Since ClutterGrab should win over client grabs, we
mostly correctly figure out that it should start doing
bypass_wayland=TRUE and bypass_clutter=FALSE while the ClutterGrab
holds, however the late checks for the MetaDisplay event route can
still toggle bypass_clutter on, resulting in neither handling events.
This check for wayland popups in the display event route should just
enforce wayland handling if wayland is meant to be receiving events,
so ensure these don't mix together.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5020
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2271>
Without input device grabs in play, all functions that emit
pointer/key/crossing/touch events are pretty much the same. Remove this
duplication and use a common emit_event() function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2100>
In case of misuse (e.g. passing NULL stage) this might result in crashes
before the precondition checks managed to kick in. Move this priv variable
initialization after these checks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
Wayland event processing and WM operations are themselves outside the
ClutterGrab loop so far. Until this is sorted out, these pieces of
event handling have got to learn to stay aside while there is a
ClutterGrab going on.
So, synchronize foci and other state when grabs come in or out, and
make it sure that Wayland event processing does not happen while
grabs happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
Since we want these accessed from bindings this must be a boxed
type. This has the side effect of making ClutterGrab a refcounted
object, since we want to avoid JS from pointing to freed memory
and maybe causing crashes if misusing the object after dismiss.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
Toggling the click action on when leaving the actor/action sounds weird,
this was presumably meant to toggle it off on leave, and back to in_held
on enter. This way, the CLUTTER_LEAVE handling also matches what we want
to do in case of grabs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
The lack of handling of regular crossing events here is dubious, perhaps
to be fixed later on. So far, ensure gestures are cancelled whenever
a grab-inducted crossing event would leave this action in the blue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
This is (luckily!) unused, and it's inconvenient to have a toggle to
break the input model we are striving towards. Drop this function
and stick to the default behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2099>
The experimental feature "autoclose-xwayland" requires a couple of
prerequisites:
1. Be able to (re)start Xwayland on demand, i.e. with systemd
2. Xwayland must support the terminate delay
Add a warning message if "autoclose-xwayland" was requested but any of
those prerequisites is not met.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
Since commit 226afa24a - "Use Xwayland auto-terminate feature", the
callback function shutdown_xwayland_cb() does not check for the
autoclose-xwayland experimental feature anymore.
As a result, when running nested or outside of systemd,
gnome-shell/mutter would quit after 10 seconds unless some X11 window
was mapped.
But now that we rely on Xwayland's own terminate feature, there really is
no need to use any xserver timeout function anymore.
We do not need to keep track of X11 windows being created or unmapped, as
again, Xwayland does all that for us at the client level.
Remove all this code that we do not need anymore.
fixes: 226afa24a - Use Xwayland auto-terminate feature
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2258>
Because both code paths require the existence of `GL_TIMESTAMP[_EXT]`
which is only guaranteed if `ARB_timer_query` (included in GL core 3.3)
is implemented.
We know when that is true because `context->glGenQueries` and
`context->glQueryCounter` are non-NULL. So that is the minimum
requirement for any use of `GL_TIMESTAMP`, even when it is used in
`glGetInteger64v`.
Until now, Raspberry Pi (OpenGL 2.1) would find a working implementation
of `glGetInteger64v` but failed to check whether the driver understands
`GL_TIMESTAMP` (it doesn't).
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2107
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2253>
This looks like a relic of glReadPixels-based picking, the pointer
might well be outside redrawn areas, yet still require a device
update (e.g. in order to reflect the actor layout changes in the
"clear area" info).
Instead, always update all devices that are inside the view after
relayouts, the tracking on the need for that update is now done
on each ClutterStageView, instead of globally in the ClutterStage.
This theoretically fixes situations where pointers might miss
updating their "clear area" after the actor tree changed.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2117
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2257>
When using Xwayland-on-demand (default), if the (experimental) autoclose
features is enabled, we can rely on Xwayland's auto-terminate feature
instead of explicitly killing the Xwayland process.
With it, gone is the mechanism that was added to check the X11 clients
connected and their executable to check whether we can (safely) kill
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
The connection to the Xserver for the X11 window manager part of mutter
even on Wayland may prevent the Xserver from shutting down.
Currently, what mutter does is to check the X11 clients still connected
to Xwayland using the XRes extension, with a list of X11 clients that
can be safely ignored (typically the GNOME XSettings daemon, the IBus
daemon, pulseaudio and even mutter window manager itself).
When there is just those known clients remaining, mutter would kill
Xwayland automatically.
But that's racy, because between the time mutter checks with Xwayland
the remaining clients and the time it actually kills the process, a new
X11 client might have come along and won't be able to connect to
Xwayland that mutter is just about to kill.
Because of that, the feature “autoclose-xwayland” is marked as an
experimental feature in mutter and not enabled by default.
Thankfully, the Xserver has all it takes to manage that already, and
is even capable of terminating itself once all X11 clients are gone (the
-terminate option on the command line).
With XFixes version 6, the X11 clients can declare themselves
"terminatable", so that the Xserver could simply ignore those X11
clients when checking the remaining clients and terminate itself
automatically.
Use that mechanism to declare mutter's own connection to the Xserver as
"terminatable" when Xwayland is started on demand so that it won't hold
Xwayland alive for the sole purpose of mutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
This is to get support for the “-terminate delay” option in Xwayland
with libXfixes 6.0.
libXfixes 6.0 provides the new ClientDisconnectMode that clients can
use to declare themselves as to-be-terminated.
This can be used to let Xwayland terminate itself automatically when no
other (“non-terminatable”) X11 client is left.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794>
Adding a <dbus/> element containing a boolean (yes/no) determines
whether org.gnome.Mutter.DisplayConfig ApplyMonitorsConfig will be
callable. The state is also introspectable via the
ApplyMonitorsConfigAllowed property on the same interface.
For example
<monitors version="2">
<policy>
<dbus>no</dbus>
</policy>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The test aims to verify that setting the following policy
<policy>
<stores>
<store>system</store>
</stores>
</policy>
only applies monitor configurations from the system level.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
This adds a way to define a way, at the system level, to define a policy
of how monitor configuration files are loaded.
The intended use case is to e.g. either prefer system level monitor
configurations before user levels, or only allow system level
configurations.
Examples:
Prefer system over user level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
<store>user</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Only allow system level configurations:
<monitors version="2">
<policy>
<stores>
<store>system</store>
</stores>
</policy>
<configuration>
...
</configuration>
</monitors>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
strncmp() always return 0 if the passed length is 0. What this means is
that whatever the first string check happens to be, if the parsed XML
cdata was empty (e.g. if we got <element></element>), the first
condition would evaluate to true, which is rather unexpected.
Fix this by making sure the string length is correct first. Also move it
into a helper so we don't need to repeat the same strlen() check every
time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2030>
The way device backends implement power saving differ, and power saving
needs to contain nothing incompatible in the same update. Make it
impossible to e.g. mode set, page flip, etc while entering power save by
not using MetaKmsUpdate's at all for this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
When we're predicting state, i.e. when having posted an update while
avoiding reading KMS state, copy the predicted state, update the actual
state, and check that the predicted state matches the newly updated one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
It was a bit scattered, with it being split between MetaKms and
MetaKmsImpl, dealing with MetaKmsDevice and MetaKmsImplDevice
differentation. Replace this by, for now, single entry point on
MetaKmsDevice: meta_kms_device_process_update_sync() that does the right
thing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
As other KMS tests, depends on being DRM master and vkms being loaded.
Currently consists of a sanity check that checks for the expected set of
connectors, CRTCs, planes, etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
Right now gamma is set only via the D-Bus API (from gsd-color), but the
actual gamma isn't right after SetCrtcGamma(), meaning if one would call
GetCrtcGamma() right after setting it, one would get the old result.
Avoid this by getting the "current" CRTC gamma from the cache we manage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2159>
In order to support dynamic imports, gjs added an implicit mainloop
that can drive the main context independently from other mainloops
like the one from GApplication or MetaContext.
That means that sources can now get dispatched to the main context
from the moment the plugin is started, resulting in a crash as the
association between compositor and plugin manager doesn't exist until
meta_plugin_manager_new() returns.
Make sure this doesn't happen by only starting the plugin after
meta_plugin_manager_new() has returned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2242>
The code style in the remote-desktop API is currently a mess.
While, the overall code style in mutter and gnome-remote-desktop is to
use spaces as tabulator, the remote-desktop API is mixed with both
spaces as tabulators and actual tabulators.
In addition to that, the code style in the XDG desktop portal APIs uses
spaces as tabulators as well.
To unify the code style, replace all actual tabulators with spaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2255>
The code style in the screencast API is currently a mess.
While, the overall code style in mutter and gnome-remote-desktop is to
use spaces as tabulator, the remote-desktop API is mixed with both
spaces as tabulators and actual tabulators.
In addition to that, the code style in the XDG desktop portal APIs uses
spaces as tabulators as well.
To unify the code style, replace all actual tabulators with spaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2255>
When privacy screen is changed and this happens on explicit user request
(that is not a setting change) we should notify about this via an OSD.
To perform this, we keep track of the reason that lead to a privacy
screen change, and when we record it we try to notify the user about.
When the hardware has not an explicit hotkey signal but we record a
change we must still fallback to this case.
Fixes: #2105
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Privacy screen events on connector are handled as notification events
that won't cause any monitors reconfiguration but will emit monitors
changed on DBus, so that the new value can be fetched.
We monitor the hardware state so that we can also handle the case of
devices with hw-switchers only.
In case a software state is available it means we can also support
changing the state, and if so expose the state as unlocked.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
When both a setting change and a monitor change happens we need to
ensure that the monitor settings are applied.
This is currently only related to privacy settings, but will in future
also handle other monitor parameters such as brightness.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
Some monitors support hardware features to enable the privacy screen
mode that allows users to toggle (via software or hardware button) a
state in which the display may be harder to see to people not sitting
in front of it.
Expose then this capability to the monitor level so that we can get its
state and set it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952>
In some cases mutter is started in the user scope from a TTY (for
example using toolbox). Using sd_pid_get_session fails because it's not
in the session scope so it falls back to the primary session
(sd_uid_get_display). We want to start mutter on the TTY we started
mutter on however. Instead of relying on the scope to figure out the
correct session we first look at $XDG_SESSION_ID which is set by
systemd_pam.so.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2254>
gtk-doc support was taken out about six years ago, but never replaced.
Add support for the newer gi-docgen, which should hopefully encourage
both C and GJS users of these libraries to improve the reference.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2248>
It is possible that we never create a cached state for a surface
even if it is synced. That is the case if `commit()` is never called.
We still need to call `apply_state()` in this case in order to run
e.g. `role_post_apply_state()` or `parent_state_applied` on subsurfaces.
So just ensure to initialize the cached state instead of bailing out.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
Subsurfaces can be effectively synced indirectly via their ancestors.
Right now such indirectly synced surfaces don't apply their cached
state when their ancestor effectively becomes desync as by the time
we call `parent_state_applied()` on them, they are considered as
desync.
Thus sligthly reoder things so when the ancestors becomes desync
and applies its state, those surfaces still count as synced and
will thus apply their cached state as well.
While on it, add a check to prevent `set_desync()` to have side
effects when the target surface is not currently synced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2232>
At first glance the `goto` looks like a loop, or potentially an infinite
loop. It's not a loop because the mode has changed at that point to
`META_SHARED_FRAMEBUFFER_COPY_MODE_PRIMARY`. But we can make it more
obvious and avoid the need for a goto.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2240>
The stage window is an interface, that added properties, that were only
then actually managed by MetaStageImpl. Shuffle things slightly, and let
the MetaStageImpl object deal with these things itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
It tests that if we go from (x is the pointer cursor)
+--------+
| |
| X |
+--------+
to
+----------------+
| |
| |
+--------+ |
| | |
| X | |
+--------+----------------+
i.e. making sure that X ends up somewhere within the logical monitor
region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2237>
These will be skipped by default, but can be run from a TTY for easier
debugging by doing:
dbus-run-session -- meson test -C build --suite mutter/native/tty --setup plain
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This commit makes it possible to run test executables in a test
environment constructed of a virtual machine running the Linux kernel
with the virtual KMS driver enabled, and a mocked system environment
using meta-dbus-runner.py/python-dbusmock.
The qemu machine is configured to use 256M of memory, as the default
128M was not enough for the tests to pass.
Using qemu is also only made possible on x86_64; more changes are needed
for it to be runnable on aarch64, so add a warning if it was enabled on
any other architecture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
This is needed if one wants to run the test suite parts that need KMS or
evdev access in a virtual machine.
However, only initiate these methods if the meta-dbus-runner.py program
was launched with --kvm, as it's only suitable for using while running
as root in a virtual machine.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When we test, we might not have a systemd session to rely on, and this
may cause some API we depend on to get various session related data to
not work properly. Avoid this issue by passing fallback values for these
when we're running in test mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
There will be another mode added later, 'test'; prepare for this by
changing the existing "mode" boolean ('headless') to a mode, which is
either 'default' or 'headless'. Checking the is_headless variable is
changed to using the function is_headless(), except for one place, being
VT switching, which in preparation is only allowed on the 'default'
mode. Other places where it makes sense, the conditions are changed to
switch statements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
When running in KVM, the EGL driver supports querying the render node
path, but it returns NULL. Handle that better by falling back to
querying the device main device file, instead of falling back on v3 of
the protocol and logging a warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
Some API will return NULL or the equivalent; sometimes it's an error,
and sometimes it's not, and the way to check that is by looking at the
return value of eglGetError(). When we check this, don't set the GError
if it returned EGL_SUCCESS, as that indicates that the return value is
expected behavior, and not an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2151>
As ClutterGrab is a stack, the backend only cares about some grab
existing currently or not. Make it sure that we grab whenever we
go to >=1 grabs, and ungrab whenever we go to <1.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Dissociate clutter_stage_set_key_focus() from the actors focused
state, so that it obeys stage grabs. The key focus actor state may
also change due to grab changes, add the code to notify about this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Emit crossing events whenever a grab coming or going would cause a
pointer/touchpoint to become inactive on their position. Depending
on whether the pointer lies inside the old or new grab widgets,
enter or leave events would be generated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
We will want to be more specific about the portions of the actor
hierarchy that receive this event, separate creation and emission
so each place does what is relevant.
However, this commit brings no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
These events are not meant to be ever silenced away, every actor
that is meant to receive one should do so. Make it sure that those
events cannot be stopped, despite the event signal handlers return
values.
This opens the debate about whether crossing events should be
ClutterEvents, since they are more and more uncommon at being one,
maybe this notification mechanism should be taken away from the
event machinery, but that's something for future refactors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
Hopefully, the one to make them all converge. This new ClutterGrab
represents a handle on a created grab. These are stacked, so grabs
can be overridden and remain inactive until there is a time that
they become active again, although undoing these early is optional.
These grabs are global, they do apply to all pointer, touchpoint
and keyboard foci.
At the moment, only the API to create and stack those is added,
the actual functionality is added in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2068>
There was a sanity check that complained if there was still a "next
framebuffer" when disposing an onscreen. This is correct to complain
about under normal operation, as we always wait until receiving the page
flip callback before cleaning up the onscreen and their state.
However, when there are many hotplugs occurring, we might end up with
race conditions when the above sanity check is not valid: when we have
more than one monitor active, paint 1 one of them, but receive a hotplug
event before we paint the other(s), we will discard the already painted
onscreen before really issuing a page flip.
In this situation, we will have the "next framebuffer", but having that
is not a bug, it's a race condition, thus to not leak in this situation,
make sure to clean up the next framebuffer here too.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2081
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2225>
If there are any pending updates, for example if we painted one of
multiple monitors but without having posted the update due to waiting
for another monitor to be painted, but before we paint all of them and
post the update, another hotplug event happens, we'd have stale pending
KMS update. When that update eventually would be processed, we'd try to
apply out-of-date updates which may contain freed memory.
Fix this by discarding any update when we're rebuilding the views. We
can be sure not to need any of the old updates since we're rebuilding
the whole content anyway.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1928
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2216>
Following the EGL_KHR_swap_buffers_with_damage specification, the
surface damage used by eglSwapBuffersWithDamage does not need to
contain the damage history.
Rework that to reduce the amount of rectangles that get passed to
the backend.
Also rework some of the regions that were using fb_clip_region and
missing the last scaling to support fractional scaling.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2089>
A property for reversing the visible order of children is a bit odd.
It has also been unused by actual gnome-shell code since 2010, and the
somewhat related pack_start()/pack_end() API in GtkBox(Layout) is gone
in GTK4.
With that in mind, turn the property into a no-op and deprecate it,
so that it can be dropped next cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2206>
When the before-paint function is executed, it's only purpose
is to check if there's any scanout queue, and immediately
record it if any.
However, since [1], we regressed in this specific case with the
introduction of an idle callback in the before-paint function.
The regression only happens when the PipeWire stream is using
DMA-BUF buffers, and it would operate as follows:
1. In before-paint, when there's a scanout available, we queue
an idle callback to capture the monitor. The idle callback
(almost always) executes after the scanout is pulled from
the stage view
2. meta_screen_cast_stream_src_maybe_record_frame() is called
by the idle callback. In the DMA-BUF case, it then runs
meta_screen_cast_monitor_stream_src_record_to_framebuffer()
3. In meta_screen_cast_monitor_stream_src_record_to_framebuffer(),
because the stage view doesn't have a scanout anymore, it
ends up calling cogl_blit_framebuffer() with the stage view
framebuffer. This is the regression bug.
This regression presents itself in the form of the screencast
stream showing the desktop when there's an unredirected fullscreen
application window running.
Revert before-paint - and only that - back to immediately capturing
any available scanout. Only record these frames when the target
buffer is a DMA-BUF handle. Nothing is captured on before-paint if
the stream is not using DMA-BUF, since the regular paint routine
will handle these frames regularly post-paint.
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
Next commits will reintroduce a certain behavior of stage
capturing that can only happen with DMA-BUF buffers. To
control this, add a new flag tp MetaScreenCastRecordFlags
for this behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2186>
If a Wayland subsurface is the topmost actor, consider in for
scanout as well. This will extend our scanout capabilities to apps
like Firefox
While on it, correct a unnessary type check to a NULL check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
On Wayland a window actor may have more than one surface actor,
most importantly when subsurfaces are used.
Add a new function to request the one which is at the top -
it will be used in the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2211>
If the EGL header is not new enough, it will not contain that relatively
new macro definition, so to avoid breaking compilation, define it
ourselves for now. Should be possible to remove after some time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2214>
We save the window rect before going fullscreen to a dedicated variable,
so we can go back to the correct dimension. We also have a dedicated
variable for returning from other window states, e.g. maximized, and
this one we initialized when creating the MetaWindow. This meant that we
could always rely on this being up to date on X11 windows that were
mapped maximized or fullscreen.
What the commit that introduced the saved rect dedicated for going
unfullscreen missed was to initialize the new saved rectangle too when
creating the MetaWindow. This resulted in windows mapped as fullscreen
often ending up misbehaving when unfullscreening, as mutter would tell
them to unfullscreen to 0x0.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1786
Fixes: a51ad8f932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2210>
Since every input stream now uses its own window, the X property used to
transfer the data no longer has to be unique, so we can stop generating
those unique names. This avoids creating a new atom for every transfer
since those are never freed, neither on the shell nor on the server
side. Also don't unnecessarily duplicate other strings that are
(almost) never used and get them from the atom in the rare case when
they are needed.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1328
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
When there are two (or more) concurrent XConvertSelection requests with
the same target, selection and window and the data is large enough for
SelectionNotify events to overlap. This can result in the affected streams
being considered completed without any data being transferred.
While regular mutter/shell code does not make use of concurrent
XConvertSelection requests with the same targets, some extensions might.
Such as for example a clipboard manager that like the built-in clipboard
manager tries to read the selection on owner-changed.
One potential solution would be to make sure the event is for the correct
property, but not all clients seem to support concurrent requests for the
same targets but different properties on the same window.
This commit instead changes the streams to use their own window which
seems to be more widely supported.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4034
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
This is a preparation for each input stream creating its own window. It
moves deleting the property from meta_x11_selection_input_stream_xevent
where it can run after the stream has been finalized to a spot where
the stream still exists. Use an error trap in case the property was not
set by the client, such as when the conversion failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1812>
The only currently known issue with allocating scanout buffers with
modifiers is memory constraints in multi head setups. Heuristics for
handling that are not implemented, but since it doesn't apply to
anything but i915, remove the other drivers from the deny list.
The other drivers had modifiers disabled to marginally increase the
chance of becoming scanout-able when allocated by Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
This significantly increases the chance of a fullscreen surface buffer
being scanned out instead of being painted via composition. This is
assuming the client supports the DMA buffer feedback Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
This API can be used to construct a MetaKmsUpdate with plane assignments
that in isolation will be tested against the current KMS state. How it
is tested depends on the KMS implementation; in the simple / legacy KMS
backend, the tests are identical to the current scanout requirements
(dimension, stride, format, modifiers, all must match), and with atomic
KMS, it uses the TEST_ONLY on a real constructed atomic mode setting
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2146>
Whenever a surface is promoted as a scanout candidate by
MetaCompositorNative, it'll get a CRTC set as the candidate CRTC.
When a client asks for DMA buffer surface feedback, use this property to
determine whether we should send a scanout feedback tranche.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1959>
This ensures they remain perfectly smooth regardless of how the
dispatch time has been adjusted/optimized/delayed/jittered.
Idea by Ivan Molodetskikh <yalterz@gmail.com>
For example, dragging a window on a 60Hz monitor:
BEFORE
delta(time_us) = 17014μs
delta(time_us) = 15998μs
delta(time_us) = 17006μs
delta(time_us) = 16975μs
delta(time_us) = 16001μs
delta(time_us) = 17002μs
delta(time_us) = 17006μs
delta(time_us) = 16004μs
AFTER
delta(time_us) = 16667μs
delta(time_us) = 16667μs
delta(time_us) = 16670μs
delta(time_us) = 16667μs
delta(time_us) = 16669μs
delta(time_us) = 16668μs
delta(time_us) = 16664μs
delta(time_us) = 16674μs
Caveat 1: Because we don't know a "next presentation time" on the first
frame, the interval between the first and second frame will usually be
different to the subsequent steady interval. So this change increases the
jitter of just frame 2, but eliminates jitter thereafter.
Caveat 2: `clutter_frame_clock_schedule_update_now` schedules updates
earlier than `clutter_frame_clock_schedule_update`. This means potentially
you could get multiple frames targeting the same "next presentation time".
That doesn't really change here though - we're dispatching at the same
times as we used to and just giving timelines a better vsync-aligned
timestamp now.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/25
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
The final tick of a timeline is >= its duration, but when using ticks that
are slightly in the future ("next presentation time") this means the final
tick will execute and complete the timeline up to one frame interval before
the timestamp of that final tick.
For the single clock test we now just check if the overall duration is
within one frame of the expected timeline duration.
The dual clock (switching) test needs a threshold of two frames because
starting each new clock creates a phase shift (error) of up to one frame.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2161>
We can't just run a single 'meson' command in the script as we need to
launch multiple long running processes inside the D-Bus session:
* The meson test invokation itself
* wireplumber
This was handled for the 'test' stages, but not for the 'dist' stage,
which as a result would fail due to wireplumber not being launched
causing any test using pipewire to timeout.
Address this by making run-tests.sh a more generic run-meson.sh that
launches wireplumber before running the actual meson command.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2204>
We're in the destructor, it's pointless to unset the userdata as we'll
never ever see a request being invoked with it ever again, since the
resource itself will be destroyed or marked as destroyed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2202>
When rendering to a buffer that is not the stage view buffer, we can not
know where the buffer will be displayed on the screen. As a result we
also can not know what translation would need to be applied to culling.
This was causing glitches when the gnome-shell magnifier was applying
offscreen effects. ClutterOffscreenEffect causes MetaWindowGroup to be
rendered to an offscreen buffer at an offset, because it draws to a
slightly larger texture with an accordingly translated origin. This
translation then later is canceled out again when the offscreen buffer
is drawn. To meta_actor_painting_untransformed() however which only sees
the translation used when drawing to the buffer this looked like the
window group was being rendered at the offset. This then lead to
redraw_clip getting translated accordingly, resulting in wrong
coordinates used for culling.
Similarly this was leading to issues when taking area screenshots while
at 1x zoom.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1678
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4876
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2080>
Refresh rates >60Hz become ever more common. In order to allow users
to keep hight refresh rates when not running at a natively advertized
resolution, add common refresh rates to our fallback modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
Right now we often add a duplicate fallback mode that's almost
identical to the native mode. This adds unnecessary clutter to
UIs, thus filter out such modes.
In order to keep the code small, use `MetaCrtcModeInfo` directly
instead of recalculating the values. And to keep consistency, do
the same in the loop above.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2189>
This is so that it can unregister from it on tear down. The tracker owns
references to cursors too, but this cycle is already broken as the
backend calls 'g_object_run_dispose()' when tearing the cursor tracker
down.
Fixes a crash on shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2181>
An incorrect assumption that after mode set there would be no pending
page flips was made. This meant that if there was a mode set, followed
by a page flip, if that page flip was for a CRTC on a now unused GPU,
we'd crash due to the renderer GPU data having already been freed. This
commit avoids that by keeping it alive as long as the page flips are
still in the air. It fixes crashes with backtraces such as
0) meta_render_device_get_egl_display (render_device=0x0)
at ../src/backends/native/meta-render-device.c:320
1) secondary_gpu_state_free (secondary_gpu_state=0x1c8cc30)
at ../src/backends/native/meta-onscreen-native.c:560
2) meta_onscreen_native_dispose (object=0x1cb65e0)
at ../src/backends/native/meta-onscreen-native.c:2168
3) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3540
4) g_object_unref (_object=0x1cb65e0)
at ../gobject/gobject.c:3470
5) clutter_stage_view_finalize (object=0x1cbb450)
at ../clutter/clutter/clutter-stage-view.c:1412
6) g_object_unref (_object=<optimized out>)
at ../gobject/gobject.c:3578
7) g_object_unref (_object=0x1cbb450)
at ../gobject/gobject.c:3470
8) meta_kms_page_flip_closure_free (closure=0x1d47e60)
at ../src/backends/native/meta-kms-page-flip.c:76
9) g_list_foreach (list=<optimized out>, func=0x7fb3ada67111 <meta_kms_page_flip_closure_free>, user_data=0x0)
at ../glib/glist.c:1090
10) g_list_free_full (list=0x1cb4d20 = {...}, free_func=<optimized out>)
at ../glib/glist.c:244
11) meta_kms_page_flip_data_unref (page_flip_data=0x1c65510)
at ../src/backends/native/meta-kms-page-flip.c:109
12) meta_kms_callback_data_free (callback_data=0x227ebf0)
at ../src/backends/native/meta-kms.c:372
13) flush_callbacks (kms=0x18e2630)
at ../src/backends/native/meta-kms.c:391
14) callback_idle (user_data=0x18e2630)
at ../src/backends/native/meta-kms.c
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
This ensures we don't have any left over cursor GPU buffers (via
gbm_bo's) after destroying the corresponding gbm_device (owned by
MetaRenderDevice).
Fixes crashes with backtraces such as
1) meta_drm_buffer_gbm_finalize at ../src/backends/native/meta-drm-buffer-gbm.c:450
4) invalidate_cursor_gpu_state at ../src/backends/native/meta-cursor-renderer-native.c:1167
9) update_cursor_sprite_texture at ../src/wayland/meta-wayland-cursor-surface.c:70
10) meta_wayland_surface_role_apply_state at ../src/wayland/meta-wayland-surface.c:1869
11) meta_wayland_surface_apply_state at ../src/wayland/meta-wayland-surface.c:832
12) meta_wayland_surface_commit at ../src/wayland/meta-wayland-surface.c:993
13) wl_surface_commit at ../src/wayland/meta-wayland-surface.c:1158
14) ffi_call_unix64 at ../src/x86/unix64.S:76
15) ffi_call at ../src/x86/ffi64.c:525
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
During tear down, if anything teared down after the seat tries to get
the cursor renderer, we'd crash trying to get it as the seat would
already be gone. Avoid this by returning NULL when there is no seat.
It's assumed that any path that will happen during tear down that relies
on getting the cursor renderer will gracefully handle it not being
present, e.g. by relying on the cursor rendering cleaning up itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2147>
Most clients nowadays switched to buffer damage, most notably Mesa
and Xwayland. Thus lets avoid the extra cost of allocating three
`cairo_region_t`s and doing some calculations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
If no viewport is set, the neutral viewport is the surface size
without viewport destination size applied - i.e. transform and
scale applied to the buffer size. Change it accordingly, giving
us the same values we'd return in `get_width` in this case.
As result, this only changes cases where a viewport destination
size but no viewport source rectangle is set.
The change fixes exactly such cases, e.g. the Gstreamer Wayland
sink. Can be tested with: `gst-play-1.0 --videosink=waylandsink`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2168>
When checking panel orientation on logical monitors we should take
panel orientation transform to check it's properly applied, so ensure
that we're checking the right one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
Commit 2289f56112 ("monitor-manager: Don't apply unneeded orientation
changes") added an early return to handle_orientation_change () in case
the transform is unchanged.
But this did not take the correction of the transform for devices
with 90° mounted panels into account causing a desired orientation
change to get skipped if the new orientation matches the corrected
logical orientation from the previous transform setting.
Fix this by calling meta_monitor_crtc_to_logical_transform () on the
transform before comparing it, matching the
meta_monitor_crtc_to_logical_transform () call in
create_for_builtin_display_rotation ().
Related: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2090>
When Xwayland was not initalized, we'd still clean things up. What this
accidentally meant was that the uninitialized display number 0 was
cleanud up, which very likely was main display of the host session.
What this meant in practice was that /tmp/.X11-unix/X0 was often
removed, causing every Flatpak X11 application to fail to start until
Xwayland was restarted nad the X0 socket file was restored.
Fix this in two ways: firstly only shutdown Xwayland if we ever started
it, i.e. if the X11 display policy was not 'disabled'. This should fix
the issue most of the times. Secondly only clean up the socket if it was
ever initialized. This should fix things if the socket creation failed,
as if it did, the name would be set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2162>
Needs a couple of changes to make tests pass again:
* mesa-dri-drivers needs explicit installation to install swrast dri
driver
* wireplumber needs to be started inside the D-Bus session
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2142>
A popup surface can be remapped multiple times using the same
wl_surface, if a new xdg_popup object is created. To properly handle
this, we need to reset the 'dismissed_by_client' boolean to false, as
otherwise we won't allow new buffer commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
Change to use the headless backend with a virtual monitor, instead of
the nested backend. This means tests can create and use virtual input
devices, which isn't possible with the nested backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
The roundtrip in the handle-configure function could in theory (and in
practice in the future) happen to receive another configure event. If we
send yet another invalid geometry the second time, we log one time too
many in the server, which fails the test. Avoid this by ignoring the
second configure event; it's enough to pass through the error handling
path once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1993>
This won't change anything for 60Hz displays but higher refresh rate
users will benefit.
Using Nvidia EGLStreams on a 240Hz monitor for example (refresh interval
~4.1ms), the maximum render time allowed before dropping to 120Hz is now
3.6ms whereas it was previously 2.1ms.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2158>
When Cogl gained support for importing pixmaps, I think there was a
misunderstanding that there is a difference in how it works in GLX and
EGL where GLX needs to rebind the pixmap in order to guarantee that
changes are reflected in the texture after it detects damage, whereas
with EGL it doesn’t. The GLX spec makes it pretty clear that it does
need to rebind whereas the EGL spec is a bit harder to follow. As a
fallout from Mesa MR 12869, it seems like the compositor really does
need to rebind the image to comply with the spec. Notably, in
OES_EGL_image_external there is:
"Binding (or re-binding if already bound) an external texture by calling
BindTexture after all modifications are complete guarantees that
sampling done in future draw calls will return values corresponding to
the values in the buffer at or after the time that BindTexture is
called."
So this commit changes the x11_damage_notify handler for EGL to lazily
queue a rebind like GLX does. The code that binds the image while
allocating the texture has been moved into a reusable helper function.
It seems like there is a bit of a layering violation when accessing the
GL driver internals from the EGL winsys code, but I noticed that the GLX
code also includes the driver GL headers and otherwise it seems pretty
tricky to do properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2062>
We are using internal API that has the benefit of checking that the
focus surface still matches, but has the drawback that it does not
check the MetaWaylandKeyboard state.
In order to fix this, look for keyboard focus and serial matches
specifically when triggering activation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2148>
The GBM support in the NVIDIA driver is fairly new, and to make it
easier to identify whether a problem encountered is related to using GBM
instead of EGLStreams, add a debug environment variable to force using
EGLStream instead of GBM.
To force using EGLStream instead of GBM, use
MUTTER_DEBUG_FORCE_EGL_STREAM=1
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/2045
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2132>
We created pipes for the stdout of the spawned mock services. This
resulted in the pipe being filled if enough things were logged, as
nothing was reading from it. Change this to allow for two modes:
verbose - where output is logged to the parent stderr, as well as non-verbose
(default) - where things are logged directly to /dev/null.
This fixes frozen tests when running with --repeat and a high enough
repeat count.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2139>
This is notably necessary with transformations, since these don't
trigger allocation machinery, but may affect the actor under the
pointer.
Visible e.g. with GNOME Shell's "Application does not respond"
dialogs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
With Wayland handling all events as they come, this code now just
performs motion compression for events that will be handled by Clutter
widgetry.
The intent to opt tablets and styli out of motion compression was
early and fast client handling, since that is now covered in a generic
manner, this code is superfluous. We don't really need the extra events
for these devices in compositor widgetry either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
We essentially create those at the time they need to be handled, and
use shortcuts that avoid the event from being queued up. It's too much
of a short cut though, these events are also of interest to the Wayland
event handlers, e.g. to handle pointer state changes (e.g. repicks due
to the pick actor being destroyed) immediately, instead of at the next
event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
If we are still under the "clear area" of the pick actor, we forget
to update the coordinates. This is usually not needed, unless we
need to repick again for non-event circumstances (e.g. pick actor
is destroyed). This will ensure the right pointer coordinates are
used afterwards in those situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Traditionally, the next repaint would also involve picking, which
would correct the actor under the pointer. This now does not happen
out of the box, so we really are waiting for the next pointer event
here.
To avoid the pointer/cursor to lag behind, trigger an immediate
repick here, that will look up the new actor under the pointer
coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
And resort to it first, unless we are told to ignore the cache
(e.g. after relayouts). This avoids further pick context operations
while the pointer is on the current actor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This safe area is the region (in stage coordinates) where the pointer
is ensured to stay within the current actor. This is not used yet, but
will be used for optimizations in pointer picking.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
These may be used for optimizations once we find the pick actor,
so picking can be avoided in areas we know didn't cross into
other actors. Nothing makes use of it yet though, just log these
so far.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Since this signal is in a hot path during input handling, it makes sense
not to have this be a signal at all, currently most of the time spent in
it is in GLib signal machinery itself.
Replace it with a function/user data pair that are set on the sprite
itself. Only the places that create an sprite are interested in hooking
one ::prepare-at behavior per sprite, so we can do with a single pair.
This makes meta_cursor_sprite_prepare_at() inexpensive enough.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Let the meta_cursor_sprite_realize() function return a boolean value
telling whether there was an actual change in the sprite cursor. E.g.
the surface/icon for it changed in between.
This is used in the native backend to avoid converting/uploading again
the cursor surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Add a clutter_stage_pick_and_update_device() method that is the only
single entry point for updating a device position as seen by the
stage.
Also, update all callers to use it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
The clutter_stage_get_actor_at_pos() calls it almost 1:1 underneath
and is public API, we can have all callers use this, and stop using
this function outside of clutter-stage.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
As event handling goes:
1) Events get generated and queued by the seat (from another thread in
native, in the same thread in X11)
2) The MetaBackend gets those events and forwards them to Clutter
via clutter_do_event()
3) The events get queued in the ClutterStage
4) At the time of processing a frame, the input events are processed,
5) Motion events are throttled, only the last is effectively handled
6) Events are filtered, wayland and WM handling happens here
7) Events maybe reach to clutter
This commit moves 6 to happen between 2 and 3. The end result is that:
- Throttling only applies to Clutter event handling, The wayland event
forwarding bits will handle the event stream as soon as it comes, as
timely as possible.
- WM event handling is also unthrottled, but that's more of a side
effect.
- This all still happens on the main thread, so there's the possibility
that other busy areas (e.g. relayout) temporarily block this event
forwarding.
- Sending events unthrottled inherently means more CPU, probably
dependent on input devices' frequency. The impact is not measured.
This should bring the best of both worlds with e.g. 1000Hz mice, wayland
clients get unthrottled events, while GNOME Shell UI still behaves like
it used to do.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
If we wait till finalize, dispose will destroy the actor hierarchy
and cause untimely repicks. Ensure to free the pointer/touch info
first, so the hooked signal callbacks are gone when destroying the
actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
This test is injecting input events without checking the correct stage/
device state. Wait for the pointer to enter the stage, so the event gets
correctly forwarded across.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915>
Listen to changes in MetaWindow::is-alive, so that the pointer
can logically leave the surface as soon as that happens. This
helps prevent flooding the client socket while it is stalled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
Change some things in these "app is alive" checks:
- The dialog timeout is separated from the ping timeout, in order
to show it again at a constant rate after dismissing, despite in
flight pings. It still shows immediately after the first failed
ping.
- As we want to tap further into is-alive logic, MetaWindow now
made it a property, that other places in code can fetch and
subscribe.
- Motion events trigger ping (as long as there was none other in
flight for the same window), and are counted between ping and
pong, in order to preemptively declare the window as not alive
before there is trouble with event queues being overflown.
This results in a separate logic between "the application does
not respond" and "we are showing the close dialog" so that the
former may get triggered independently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2122>
If we were cancelled, it could mean we teared down, meaning fetching
manager instances will attempt to fetch past freed instances. Handle
this by waiting with the fetching until we know we weren't cancelled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2140>
MetaBackend can now show whether it is in headless mode or not
using a vfunc is_headless.
Fallback of is_headless returns FALSE.
MetaBackendNative implements is_headless returning its
is_headless property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2130>
This is a strange thing to do since MetaInputMapper also does take care of
devices with an output configured through settings, since we might have
devices that were configure through settings exclude other devices that
belong together with an output (e.g. a display-integrated tablet).
This was essentially here as a last resort to avoid matching two very
similar looking tablets to one of two very similar looking outputs. There
was a 50% chance already that the choice was wrong, and now these devices
can all be configured specifically through settings, so this shouldn't
be missed either.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
Non-display-attached tablets (e.g. Intuos) may find no match, which
should mean "use the span of all monitors", not "pick one for me".
Reserve this fallback to touchscreen devices, since these might
still benefit from it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
The matrix and aspect ratio of the tablet is irrelevant on pads, and
it actually triggers warnings when trying change that on those devices:
gnome-shell:42536): mutter-CRITICAL **: 17:22:41.994: meta_input_device_native_get_mapping_mode_in_impl: assertion 'device_type == CLUTTER_TABLET_DEVICE || device_type == CLUTTER_PEN_DEVICE || device_type == CLUTTER_ERASER_DEVICE' failed
This is unnecessary to do on pad devices, these just need to be moved
together with their respective stylus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2107>
In the case a11y is required, the screen reader is very much
interested in getting an uninterrupted flow of key events. It attempts
so by setting a ::captured-event callback on the ClutterStage, but
that falls short with our MetaDisplay event handler, as clutter events
can be stopped before a11y gets a chance to see them.
This kind of selective amnesia wrt key events is not new, in X11 those
go unheard of by the WM as long as a client is focused and no grabs hold,
so it is clients' responsibility to talk with AT bridge.
This commit doesn't yet change that for X11, but we can do this right
away from the compositor on Wayland, and without any chance to be
tampered by clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1328>
Since the completion callback (on_switch_workspace_effect_complete) sets
priv->tml_switch_workspace1 to NULL, the unref was trying to unref NULL,
and the reffed ClutterTimeline was not getting unreffed.
This could be triggered by rapidly switching workspaces, switching again
before the animation of the initial switch was done.
Found while working on #2038.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2120>
This avoids the following crash, that could happen in certain rare race
conditions, e.g. in tests:
0) wl_closure_invoke (closure=0x2fbf9e0, target=0x2e5b3d0, opcode=0)
at ../src/connection.c:1014
1) wl_client_connection_data () at ../src/wayland-server.c:432
2) wl_event_loop_dispatch () at ../src/event-loop.c:1027
3) wayland_event_source_dispatch () at ../src/wayland/meta-wayland.c:104
4) g_main_dispatch () at ../glib/gmain.c:3381
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2127>
Passing a NULL workspace does not make sense, since it silently
returns no windows. Mandate that a workspace is explicitly requested,
and while at it check the other arguments as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2124>
The cursor renderer shouldn't assume all the CRTCs of a logical are KMS
CRTC's, as we'll end up checking hardware capabilities for CRTC's of
virtual monitors as well, when they were created to not embed the cursor
image directly in the framebuffer.
Instead, use the newly introduced API for checking CRTC cursor
capabilities. This fixes a crash with the following backtrace:
0) get_plane_with_type_for at ../src/backends/native/meta-kms-device.c:150
1) meta_kms_device_get_cursor_plane_for at ../src/backends/native/meta-kms-device.c:173
2) has_cursor_plane at ../src/backends/native/meta-cursor-renderer-native.c:678
3) foreach_crtc at ../src/backends/meta-logical-monitor.c:247
4) meta_monitor_mode_foreach_crtc at ../src/backends/meta-monitor.c:1920
5) meta_logical_monitor_foreach_crtc at ../src/backends/meta-logical-monitor.c:274
6) crtcs_has_cursor_planes at ../src/backends/native/meta-cursor-renderer-native.c:718
7) should_have_hw_cursor at ../src/backends/native/meta-cursor-renderer-native.c:881
8) meta_cursor_renderer_native_update_cursor at ../src/backends/native/meta-cursor-renderer-native.c:1085
9) meta_cursor_renderer_update_cursor at ../src/backends/meta-cursor-renderer.c:411
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2000183
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>
On a KMS backed CRTC, hardware cursor are supported when there are
cursor planes to assign them to. Note that when using legacy mode
setting, fake cursor planes are added when adequate.
On virtual CRTCs, used with virtual monitors, the equivalent of hardware
cursor are always supported, as they are sent using embedded PipeWire
stream metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1991>
This can happen if a texture was newly assigned to the actor, but the
unobscured region hasn't been updated yet. Without bailing here, the
actor would display correctly via direct scanout, but other parts of
mutter would continue considering it obscured, which would e.g. result
in no frame callbacks getting sent for its surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1636
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2112>
Previously we chose to only anti-alias texels inside the boundary
(`clip_radius - 1.0`) but zoomed in you could see it was slightly smaller
than the correct curve (#2024).
Similarly if you choose to only anti-alias texels outside that edge
(`clip_radius + 1.0`) then you'd get an overly convex curve that doesn't
match up with the straight line sections.
So now we anti-alias texels that intersect the circle boundary, regardless
of which side they are mostly on. For efficiency we define "intersect" to
mean any texel whose center is within 0.5 of the theoretical edge.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2024
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2102>
It was dropping to zero after the first frame because it hadn't been
incremented high enough. So the second frame would crash with:
```
#0 g_type_check_instance_cast
#1 META_DRM_BUFFER
#2 copy_shared_framebuffer_cpu
```
That's the CPU-copy path (fallback-fallback) that probably no one is using
but it does work after this fix. Exactly the same issue as was fixed
in `copy_shared_framebuffer_primary_gpu` by 36352f44f9.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2104>
A client can create a token without any seat, serial, or surface. In
this case, we'd still try to grab, which would run into some unforseen
code paths, potentially resulting in the following crash:
0) meta_wayland_tablet_seat_device_added (tablet_seat=0x55dff4271c90,
device=0x7f87b80655b0) at
../src/wayland/meta-wayland-tablet-seat.c:200
1) meta_wayland_tablet_seat_new (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-tablet-seat.c:283
2) meta_wayland_tablet_manager_ensure_seat (manager=manager@entry=0x55dff3ec7b40,
seat=seat@entry=0x0) at
../src/wayland/meta-wayland-tablet-manager.c:239
3) meta_wayland_tablet_manager_ensure_seat (seat=0x0, manager=0x55dff3ec7b40) at
../src/wayland/meta-wayland-touch.c:595
4) meta_wayland_seat_get_grab_info (seat=0x0, surface=0x55dff43ff5b0,
serial=0, require_pressed=0, x=0x0, y=0x0) at
../src/wayland/meta-wayland-seat.c:479
5) activation_activate (...) at
../src/wayland/meta-wayland-activation.c:261
Fix this by not trying to grab if not enough parameters was passed when
creating the token. Also add a test case that reproduces the above
crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
When an activation times out, we'll be signalled two signals on the
startup sequence object: "timeout", and "complete".
Normally, the "complete" signal is emitted when a startup sequence is
completed succesfully by it being used for activation, and in this case,
the xdg_activation implementation should remove the sequence from the
startup notification machinery.
However, in the timeout case, we should not remove it, as the startup
notification machinery itself will deal with this. If we would, we'd end
up with use-after-free issues, as the sequence would be finalized when
removed the first time.
To avoid this, just clean up the Wayland side in the "timeout" signal
handler, leaving the "complete" signal handler early out if it was
already handled by it.
This avoids crashes like:
0) g_type_check_instance (type_instance=type_instance@entry=0xdd6740)
1) g_signal_handlers_disconnect_matched (instance=0xdd6740, ...)
2) meta_startup_notification_remove_sequence (sn=0x4cc890,
seq=0xdd6740) at
../src/core/startup-notification.c:544
3) startup_sequence_timeout (data=0x4cc890, ...) at
../src/core/startup-notification.c:504
4) g_timeout_dispatch (...) at ../glib/gmain.c:4933
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
We set it via setenv(), and might not have the MetaX11Display at hand.
This fixes a crash when the stuck-client dialog (using zenity) appears
without any X1 client having appeared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2081>
This test ensures that windows that were resized such that they extend
beyond the screen will be moved to be fully on the screen (if possible).
This has been working on X11 since forever, but on Wayland only since
the last commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
The previous code was trying to detect client resizes by only
considering resizes without any pending configurations as client
resizes. There can however be pending configurations that do not involve
resizing, such as ones triggered by state changes. These may also stay
unacknowledged by the client until the next size change. This was
causing client resizes after showing the window (and therefore changing
its status to focused) to not be detected as client resize.
Fix this by checking whether the queue has any configuration with size
changes rather than just whether it is empty.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2023
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2103>
Used to log multiple line entries. Just make continue prefix things, no
need to mess with maybe-prefixing; it'll just complicate using some less
custom logging functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2094>
If some connectors disappeared, but the rest didn't change, we missed
actually removing the ones that disappeared, as we incorrectly assumed
nothing changed. Fix this by only assuming nothing changed if 1) we
didn't add any connector, and 2) we have the same amount of connectors
as before the hotplug event. The connector comparison checking makes
sure we report changes if anything of the still available connectors
changed.
Fixes: a8d11161b6
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2007
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
When a docking station is disconnected, a few previously existing DRM
connectors may now be gone. When this happens, getting them via the
libdrm API results in NULL pointers returning, and we need to handle
this gracefully by making sure the connector state is properly updated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2097>
The 'stop_after_next' will execeute one command, then not return to the main
loop until a 'continue' command is passed. Commands will still be
processed between 'stop_after_next' and 'continue'.
This is intended to be used to induce race conditions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
Currently the stored unconstrained_rect is only ever updated if there
was a move, resize or state change according to the move_resize_internal
implementation. For Wayland windows however resizes or state changes
are done in two steps, first the new configuration is sent to the client
and then once client acknowledges it, it is set on the mutter side in
another move_resize_internal call. Only the second call would result in
the unconstrained_rect being updated.
This started causing problems when unfullscreening windows was
immediately followed by a strut change. These strut changes started
happening in gnome-shell due to the visibility of the panel now being
considered for the struts and the presence of a fullscreen causing it to
be hidden until unfullscreen. In this situation first the unfullscreen
would resize the window to its pre-fullscreen size as expected, but then
the strut change triggers another window resize. This window resize is
based on the stored unconstrained_rect, which is still at the fullscreen
size because the unfullscreen resize only has sent its configuration,
but it has not been acknowledged yet. As a result the strut change
causes a resize to the fullscreen size which due to the constraints now
looks like a maximized window.
To fix this always update the unconstrained_rect when the requested size
has changed, but not when a previous request has been acknowledged
unless it is originating from the client itself.
If this included the move_resize_internal call from acknowledging the
size as well, it would be possible for this to be delayed long enough on
the client side to overwrite an intermediate resize originating from
mutter. And if this did not include resizes originating from the client,
clients would not be able to set an initial window size.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1973
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
meta_window_wayland_finish_move_resize() is called for both, finishing
a resize that has been requested through/by mutter and for resizes
directly done by the client. This introduces a CLIENT_RESIZE flag to
differentiate the former from the latter. Having this distinction is
required to know what the last requested size by either the client or
mutter is while ignoring older requests that might only have been
applied now.
This excludes client resizes when there are still pending
configurations, because the resize is known to be only temporary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2066>
Because POSIX sh was, with hindsight, not a particularly well-designed
programming language, if we don't 'set -e', then we'll respond to failure
of a setup command such as cd by carrying on regardless.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2009>
The assumption here seems to be that it's an overlay onto the
current environment which would make sense; but the implementation in
gnome-desktop-testing currently removes all other environment variables
(see GNOME/gnome-desktop-testing#1). This causes test failure when the
tests are run in Debian's autopkgtest framework, possibly because PATH
is cleared.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2009>
Systems with AMD GPUs do not take advantage of Mutter's zero-copy path
when driving DisplayLink screens. This is due to a very slow CPU access
to the zero-copy texture. Instead they fall back on primary GPU doing a
copy of the texture for fast CPU access. This commit accelerates texture
copy by working through damage regions only.
Tests on a 4K screen with windowed applications show significant
reduction of GPU utilisation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2033>
If one would end up with an actor attached to mapped actor, where the
attached actor doesn't itself have an up to date stage view list while
listening on the stage for updating, when clearing the stage views of
the list, anything that would query the stage views list at this time
would end up accessing freed memory.
This could happen if
1) An actor was added to a newly created container actor attached to
the stage
2) The actor got a timeline attached to it
3) The actor was moved to a container that already was mapped
4) A hotplug happened
After (1) both the container and actor would not have any stage views.
After (2) the timeline would listen on the stage for stage views
updates. After (3) the actor would still listen on the stage for stage
views updates. When (4) happened, the actor would be signalled when the
stage got its stage view cleared, at which point it would traverse up
its actor's tree finding an appropriate stage view to base its animation
on. The problem here would be that it'd query the already mapped
container and its yet-to-be-cleared stage view list, resulting in
use-after free, resulting in for example the following backtrace:
0) g_type_check_instance_cast ()
1) CLUTTER_STAGE_VIEW ()
2) clutter_actor_pick_frame_clock ()
3) clutter_actor_pick_frame_clock ()
4) update_frame_clock ()
5) on_frame_clock_actor_stage_views_changed ()
6) g_closure_invoke ()
7) signal_emit_unlocked_R ()
8) g_signal_emit_valist ()
9) g_signal_emit ()
10) clear_stage_views_cb ()
11) _clutter_actor_traverse_depth ()
12) _clutter_actor_traverse ()
13) clutter_actor_clear_stage_views_recursive ()
14) clutter_stage_clear_stage_views ()
...
Avoid this issue by making sure that we don't emit 'stage-views-changed'
signals while the actor tree is in an invalid state. While we now end up
traversing tree twice, it doesn't change the Big-O notation. It has not
been measured whether this has any noticible performance impact.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1950
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2025>
Certains keys (such as ~ and |) are in the keyboard map behind the
second shift level. This means in order for them to be input, the
shift key needs to be held down by the user.
The GNOME Shell on-screen keyboard presents these keys separately on
a page of keys that has no shift key. Instead, it relies on mutter
to set a shift latch before the key event is emitted. A shift latch
is a virtual press of the shift key that automatically gets released
after the next key press (in our case the ~ or | key).
The problem is using a shift latch doesn't work very well in the face
of key repeat. The latch is automatically released after the first
press, and subsequent repeats of that press no longer have shift
latched to them.
This commit fixes the problem by using a shift lock instead of a shift
latch. A shift lock is never implicitly released, so it remains
in place for the duration of key repeat.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2045>
The `guess_candidates()` function scores each display that an input
device could be mapped to and then uses the `sort_by_score()` comparator
to find the best option. The function expects the list to be sorted from
best to worst, but the comparator currently sorts them in the opposite
order. This causes the function to end up returning the _worst_ match
rather than the the best. This commit reverses the sort order of the
comparator so that the best display can be returned as intended.
Closes: #1889
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1934>
This does two things to frown upon:
- Modifies ClutterEvent structs, while the effort is to have those
completely opaque, and readonly after creation from the input
thread side.
- Stores state in the ClutterInputDevice struct, event though those
are also considered static after creation, managed by the input
thread, etc.
Stop doing that. This makes all events just forwarded as-is in
the ClutterStage/clutter-main.c code.
Handling of click count sounds like material for a ClutterGestureAction
(or perhaps ClutterClickAction), all of both callers now do it in place
at the moment, while gestures lack a better state tracking and management.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
This will not try the captured-event shenanigans to emulate grab
behavior, instead relying on event delivery being influenced by
other grab mechanisms.
While at it, improve handling of additional touchpoints by
cancelling the click action right away, as the differences in
event handling make this unwanted behavior surface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
By default, the pan action performs matrix translations on the
child widget. Nobody wants that (or, nobody wants *just* that).
It's cleaner not to mix mechanism and effect in ClutterGestureAction
subclasses, so drop this base implementation, and change the signal
accumulator so it's more similar to event signals (not that it's
used any longer, anyway).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2024>
Mutter already calculates and tracks the damage rectangles to redraw
only areas of the screen that change since the last time a buffer was
used.
This patch extends this by using the EGL_KHR_partial_update extension to
inform the GPU in advance that only those areas will be changed, which
may allow for further optimization.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023>
Add support for a cogl function to set the damage_region on an onscreen
framebuffer.
The goal of this is to enable using the EGL_KHR_partial_update extension
which can potentially reduce memory bandwidth usage by some GPUs,
particularly on embedded GPUs that operate on a tiling rendering model.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2023>
Defining valid values makes
1. changing settings less error prone
2. sure they are discoverable.
This does reset the values once on update, but fortunately does *not*
change the way to set the values. Thus e.g. enabling fractional scaling
via terminal command still works as before and internet guides stay valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1961>
This will make clients immediately aware of the output disappearing,
while still allowing for a grace period of 10 seconds for attempting to
bind to it before it turning into a protocol error. This API added as
part of wayland 1.18.
This requires us to not add the output resource to the output resource
list, if the output was made inert. This effectively makes the resource
useless, but that is harmless, since shortly after, the client will
clean it up anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This will be crucial when we start to remove the global directly when an
output is removed, as that means Xwayland might have removed the output
before we managed to get our queries in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
We setup Xwayland in an early phase of the X11 display, before we had a
MetaX11Display, and teared down in a couple of places happening when
tearing down the Xwayland integration if the X server died or
terminated. It was a bit hard to follow what happened and when it
happened. Attempt to clean this up a bit, with things being structured
as follows:
* Early during X11 display connection setup, only setup the rudimentary
X11 hooks, being the libX11 error callbacks, and adding the local
user to XHost.
* Move "initialize Xwayland component" code to a new
'x11-display-setup' signal handler. Things setup here are cleaned up
in the 'x11-display-closing' handler.
* Connect to 'x11-display-setup' and 'x11-display-closing' up front,
and stay connected to these two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1796>
This old handling of session files looked on ~/.mutter, which has
been unused and unsupported for a long time. It also had paths were
the GError was leaked. Fix both by dropping the legacy code, and
falling back to the common error paths.
CID: #1502682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
This warning is actually dead code, since should_be_mapped and
must_be_realized are always set to the same value, so it does not
make sense to check for "a && !b".
Turn this into an assert so we avoid the dead branch, but do not
remove the variable duplication so the more aptly named variable
is used where it belongs, for clarity.
CID: #1506254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
When grabbing the devices, there's no error paths that would quit
late enough that both pointer and keyboard would need ungrabbing,
so the keyboard checks were dead code.
Fix this by dropping the boolean variable checks, and adding goto
labels to unroll the operation properly at every stage.
CID: #1418254
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2061>
The monitor orientation tests do a lot of things in sequence. Replace
some of the comments with g_test_message() so that the log from a failed
test gives us a better idea of how far we got.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
Previously, we were waiting up to 300ms for the signal, then proceeding
anyway. However, 300ms is not necessarily long enough to wait on an
autobuilder that might be heavily loaded, particularly if it's a non-x86
with different performance characteristics.
Conversely, if mutter responds to the D-Bus signal from the mock sensor
before we have connected to the signal, then we cannot expect to receive
the signal - it was already emitted, but we missed it. In this case, we
need to avoid waiting.
One remaining use of wait_for_orientation_changes() that would previously
always have timed out was in
meta_test_orientation_manager_has_accelerometer(), which does not
actually expect to see an orientation-changed signal. Make this wait
for the accelerometer to be detected instead.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1967
Bug-Debian: https://bugs.debian.org/995929
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2049>
When we use gbm together with the NVIDIA driver, we want the EGL/Vulkan
clients to do the same, instead of using the EGLStream paths. To achieve
that, make sure to only initialize the EGLStream controller when we
didn't end up using gbm as the renderer backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2052>
This switches the order of what renderer mode is tried first, so that
the gbm renderer mode is preferred on an NVIDIA driver where it is
supported.
We fall back to still try the EGLDevice renderer mode if the created gbm
renderer is not hardware accelerated.
The last fallback is still to use the gbm renderer, even if it is not
hardware accelerated, as this is needed when hardware acceleration isn't
available at all. The original reason for the old order was due to the
fact that a gbm renderer without hardware acceleration would succeed
even on NVIDIA driver that didn't support gbm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2051>
This replaces functionality that MetaRenderDevice and friends has
learned, e.g. buffer allocation, EGLDisplay creation, with the usage of
those helper objects. The main objective is to shrink
meta-renderer-native.c and by extension meta-onscreen-native.c, moving
its functionality into more isolated objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
All render devices that have a device file backing them might be able to
allocate dumb buffers, so add a helper for doing that. Will indirectly
result in an error up front on a surfaceless render device due to lack
of a device file.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It might not be needed by the user of the buffer, so don't always
require it up front. Instead make sure that any user that needs it first
calls "meta_drm_buffer_ensure_fb_id()" to create the ID.
Only the plain gbm implementation creates the ID lazilly, the other
still does it on construction due to the objects used to create them
only existing during construction.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Mostly calls into gbm_bo_* API, or something somewhat similar when on
dumb buffers. Added API are:
* get offset for plane
* get bpp (bits per pixel)
* get modifier
This will allow users of MetaDrmBuffer to avoid having to "extract" the
gbm_bo to get these metadata.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
The purpose of MetaRenderDevice is to contain the logics related to a
render device; i.e. e.g. a gbm_device, or an EGLDevice. It's meant to
help abstract away unrelated details from where it's eventually used,
which will be by MetaRendererNative and the MetaOnscreenNative
instances.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
Meant for MetaRenderer and everything related that deals with turning
composited frames, or client buffers, into mode set updates. This is
slightly related to the debug topic 'kms' is meant for the KMS details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1854>
It was a feature relevant for when Clutter was an application toolkit
that wanted the application window to communicate a minimum size to the
windowing system.
Now, clutter is part of the windowing system component, so this feature
doesn't make any sense, so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This feature was configured depending on whether the Cogl backend
reported COGL_WINSYS_FEATURE_MULTIPLE_ONSCREEN or not. All cogl backends
do report this, so any code handled the 'static' case were never used.
While we only ever use one stage, it's arguable more correct to
consilidate on the single stage case, but multiple stages is something
that might be desirable for e.g. a remote lock screen, so lets keep this
logic intact.
This has the side effect of completely removing backend features, as
this was the only left-over feature detection that they handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This changes the setup phase of clutter to not be result of calling an
init function that sets up a few global singletons, via global singleton
setup vfuncs.
The way it worked was that mutter first did some initial setup
(connecting to the X11 server), then set a "custom backend" setup vfunc
global, before calling clutter_init().
During the clutter_init() call, the context and backend was setup by
calling the global singleton getters, which implicitly created the
backend and context on-demand.
This has now changed to mutter explicitly creating a `ClutterContext`
(which is actually a `ClutterMainContext`, but with the name shortened to
be consistent with `CoglContext` and `MetaContext`), calling it with a
backend constructor vfunc and user data pointer.
This function now explicitly creates the backend, without having to go
via the previously set global vfunc.
This changes the behavior of some "get_default()" like functions, which
will now fail if called after mutter has shut down, as when it does so,
it now destroys the backends and contexts, not only its own, but the
clutter ones too.
The "ownership" of the clutter backend is also moved to
`ClutterContext`, and MetaBackend is changed to fetch it via the clutter
context.
This also removed the unused option parsing that existed in clutter.
In some places, NULL checks for fetching the clutter context, or
backend, and fetching the cogl context from the clutter backend, had to
be added.
The reason for this is that some code that handles EGL contexts attempts
to restore the cogl EGL context tracking so that the right EGL context
is used by cogl the next time. This makes no sense to do before Cogl and
Clutter are even initialized, which was the case. It wasn't noticed
because the relevant singletons were initialized on demand via their
"getters".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
In various places we retrieved the default seat from the ClutterBackend.
All the clutter backends implement this by calling
meta_backend_get_default_seat() which will then return
MetaBackendPrivate::default_seat.
Lets avoid this by fetching the default seat directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
Rename all instances of `MetaClutterBackendX11` so they are called
`clutter_backend_x11`. This is because `MetaBackendX11` will start to be
used for some things, and having both be named `backend_x11` would be
confusing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2002>
This one is a trivial wrapper around clutter_actor_get_children(), so just
use that in the two places where clutter_container_get_children() is used,
and remove clutter_container_get_children().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2057>
Right now we damage the stage even if an actor is not mapped, for
example in the overview.
Stop doing so, reducing over-paint significantly in some situations.
Clones will still do stage damage on their own.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2035>
Quoting the spec for `wl_data_device::drop`:
> If the resulting action is "ask", the action will not be considered
> final. The drag-and-drop destination is expected to perform one last
> wl_data_offer.set_actions request, or wl_data_offer.destroy in order
> to cancel the operation.
We did not respect the action choosen by the drop destination when
it called `wl_data_offer::set_actions` after `wl_data_device::drop`
if a user override was still active. This eventually resulted in
a protocol error in `wl_data_offer::finish`, as the current action
could still be `ask`.
Fix this by only allowing a user override to `ask` before `drop` is
called, thus making sure the final `set_actions` preference is
honored.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1952
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2043>
Since the CI pipeline now runs `meson dist` which includes a test
for an up-to-date NEWS entry, post-branch/release version bumps
have become unwieldy.
It's still useful to increase the API version right after branching
though, so return to bumping it manually and do so now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2053>
With each wl_ouitput corresponding to a monitor, the logical monitor is
not part of the MetaWaylandOutput anymore.
Previously, send_xdg_output_events() would compare the old logical
monitor against the new one to determine whether the size and/or
position was changed and should be sent along with the xdg_output
events.
But that logic is now defeated as there is no old/new logical monitor
anymore, so the updated size or location would never be sent again.
Xwayland relies on this information to update its X11 clients and its
own internal root size, without this the X11 screen size and XRandR
information would never be updated.
To avoid that issue, always send the xdg_output size and location on
xdg_output events, Xwayland is smart enough to update its X11 clients
with XRandR only when the layout actually change.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1964
Fixes: bf7c3450 - Make each wl_output correspond to one monitor
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2050>
ClutterText implements its own get_paint_volume() with its own cache,
but was not invalidating the actor paint volume when when it has
changed. This sometimes could result in labels, especially quickly
changing ones, using the old paint volume which either would cut off the
label or leave parts of the old label on screen.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1943
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2006>
Easily seeing the buildtype and debug status can be quite useful.
Gnome-Shell already has it.
And while on it, add a 'Directories' section for already existing
entries.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2044>
meta_keymap_x11_replace_keycode currently reports to the X server
that the key types data is changed when adding a key to the keymap.
It's not changed. The number of key types is the same, and none of
them are modified.
This has two bad side effects:
1) It sends all of the key types data into the request
2) It hits a bug in the X server leading to the request getting
rejected entirely. See:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/761
Furthmore, the changed structure used to report to the X server
that the key types data is changed doesn't actually need to modified
at all in the function. It's already prepped by libX11 with the
correct state for the changes mutter is doing when
XkbChangeTypesOfKey is called.
This commit addresses the above two problems by just removing the
lines causing the issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2039>
Keys in the reserved keycode list are always added for the first group.
Before the previous commit such keycodes were not found unless that was
the current group. But now that we can also find matching keycodes that
are not directly in the current group, this is not necessary anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
Some keys, such as enter or backspace are only bound to a single group,
even if multiple groups are configured. Because the code was previously
only looking for keysyms in the same group as the current one, no
matching keycodes for these would be found if the current group is not
the first group. This was causing those keys to not work on the X11 OSK.
To fix this use the correct action to convert an out of range group for
that key according to its group_info field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
This effectively changes meta_keymap_x11_get_entries_for_keyval() to
meta_keymap_x11_get_entry_for_keyval() and moves the check if the
keycode maps to the keyval in the current group there. This simplifies
the code a bit and will allow a followup fix.
As a side effect this now also causes the reserved kecodes to be
searched, if no keycodes were found, rather than just when only ones
matching the wrong groups.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1955>
The extra stage update we schedule in `apply_state()` is mainly
needed in two situations:
- a partial update happened only in obscurred or off-screen parts
of a surface
- a surface requests frame callbacks without having done damage,
notably the (in)famous Firefox vsync implementation.
Commit 0330ce1f15 limited the update to cases when the actor
was mapped, breaking it for Firefox in the overview.
Remove the mapped check again and get the stage from the backend,
restoring previous behaviour.
Fixes 0330ce1f15
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1957
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2034>
Avoid having laptops suspend or lock as soon as the power cable is
unplugged as the timeout for those actions when on battery are smaller
than the timeouts when on AC.
- laptop is plugged in, and hasn't been used for X minutes
- laptop is unplugged
- the gnome-settings-daemon power plugin sets up its timeouts for
inactivity for the "on battery" case
- those X minutes of inactivity are still counting, and are above
the level of one of the timeouts (say, suspend or lock screen),
mutter fires the timeouts
- gsd-power activates the action associated with the timeout
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1953
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2029>
If the ancestor a window is transient for has already been unmanaged
when the window is activated via meta_window_activate_full while its
transient_for property still points to that ancestor, this will cause
the already unmanaged ancestor to get added to the windows workspace.
This is after the ancestor had its workspace set to NULL when it was
unmanaged, causing this to look like an actual workspace change. Once
the window has been added to the workspace, it will never be removed
again, because the it has already been unmanaged. This confuses things
like the shell window tracker and leads to phantom windows being
considered present for apps that are not even running anymore.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4184
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2003>
When a test failed, an exception would be raised. This meant that the
mocked service would stay alive, and the test case being run eventually
failing due to a timeout, not the failure itself.
Fix this by catching the exception during the test, ensuring that we
tear down properly, then re-raise the same exception again after having
teared down.
This avoids the dead lock, while still printing the appropriate error
message.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2008>
With the introduction of MetaContext, the responsibility for handling
signals was changed to the application (e.g. GNOME Shell) using
libmutter. What wasn't fixed was making the stand-alone mutter do the
equivalent as well. This commit fixes this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2007>
When the native backend is paused we still process the udev events
even though this isn't needed and may just cause unneeded events to be
triggered afterwards.
Since we'll resume with full changes on such event, we can just block
the signal hander when paused and restore it afterwards.
As per this we can cleanup also a bit the device adding signal handling
given that now we don't have to disconnect/reconnect it again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Resume happens after we may have received various events that we've
ignored, so at this point we need to just emit an hotplug event like if
everything changed so that user settings may be re-applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may get informations about what CRTC or connector
changed a property (and the property itself), so in such case let's just
ignore the changes to the non-affected CRTCs/connectors, and let's read
only the affected one
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
On hotplug events we may receive a "CRTC" or "CONNECTOR" property that
indicates which crtc/connector property ID has changed.
In such case, instead of update data for all the devices, only update the
device containing the relative connector.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Hotplug events may contain CRTC or CONNECTOR ids to notify a property
change to just one owner, so we need to find its parent device.
Also we may want to update properties directly without having to go through
all the devices, so expose a simple way to find them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
In case we have no devices, after a KMS update (both because they've
all have been removed or because there were none), we may need to behave
differently compared to the case in which nothing changed, so add a more
specific KMS update change type
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
If only gamma changed on drm CRTC's we don't have to rebuild the whole
monitors, nor to inform the backed about, the only consumer could be the
DBus API, and so we still emit a signal, but nothing else is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
Since we cache already all the KMS parameters we care about let's check at
each device update if anything has really changed and only in such case
emit a resources-changed signal.
In this way we can also filter out the DRM parameters that when changed
don't require a full monitors rebuild.
Examples are the gamma settings or the privacy screen parameters, that
emits an udev "hotplug" event when changed, but we want to register those
only when we handle the changed property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1964>
A client request for maximizing itself should always be handled by mutter
by emitting a configure event with the native maximized resolution,
regardless of the client's own set limits. This also aligns the behavior by
allowing fixed-sized windows to go into fullscreen or maximized state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1997>
These match their alpha counterparts, apart from not setting the
alpha bit. This allows our internal mashinery to more easily
distinguish whether we need a slow alpha-pass during rendering or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1810>
These match their alpha counterparts, apart from not setting the
alpha bit. This allows our internal mashinery to more easily
distinguish whether we need a slow alpha-pass during rendering or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1810>
It works correctly with scanouts, in contrast to
clutter_stage_capture_into. Inspired by
meta_screen_cast_area_stream_src_record_to_buffer.
maybe_paint_cursor_sprite is now unused and thus removed.
v2:
* clutter_stage_paint_to_buffer requires switching to recording from an
idle callback as well. (Jonas Ådahl)
v3:
* Set human readable name for idle source. (Ivan Molodetskikh)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1940
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1914>
The way wl_seat capabilities work, by notifying clients of capabilities
changes, and clients consequently requesting the relevant interface
objects (pointer, keyboard, touch) is inherently racy.
On quick VT changes for example, capabilities on the seat will be added
and removed, and by the time the client receives the capability change
notification and requests the relevant keyboard, pointer or touch,
another VT switch might have occurred and the wl_pointer, wl_keyboard or
wl_touch already destroyed, leading to a protocol error which kills the
client.
To avoid this, create the objects when requested regardless of the
capabilities.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1797
Related: https://bugzilla.gnome.org/show_bug.cgi?id=790932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/77>
So far, releases are done locally by invoking `meson dist`.
We can do better and leverage the existing CI infrastructure, to get
to the following release workflow:
- bump version in meson.build, update NEWS etc.
- open merge request for the release
- merge when the pipeline (including dist check) succeeds
- tag the release
- wait for the tag pipeline to spit out the tarball artifact
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1980>
I don't think this ever happened to me, but it can't hurt enforcing
that every release has a corresponding NEWS entry.
(The script has been copied from Polari, thus the metainfo support)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1980>
Analogous to `get_image()` this returns a `ClutterContent` for a
given `MetaWindowActor`. This can be used to implement window
effects without a roundtrip from GPU to CPU memory.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1893>
In X11 when we switch to another tty all the the signals are blocked (as
the display fd is not replying back to polling, causing the main loop to
stop), and they are all handled once we switch back to the tty.
This is not a problem for most of external events, but in case of
accelerometer changes, once we reactivate a mutter session we'll get
them all together, causing lots of monitor reconfigurations leading to
black screen for some seconds and most of the times to a wrong
configuration being applied.
To avoid this, batch all these events using an idle to only apply the
last one we got in a loop.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1217
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
Create a test system bus and use it to run all the tests, add a mock
SensorsProxy (via dbusmock template) server that implements the
net.hadess.SensorProxy interface.
To make testing easier, the service is created on request of a proxy for
it, whose lifetime controls the mock service lifetime as well.
This is done using a further mock service that is used to manage the
others, using python-dbusmock to simplify the handling.
Add basic tests for the orientation manager.
As per the usage dbusmock, we're now launching all the tests under such
wrapper, so that local dbus environment won't ever considered, and
there's no risk that it may affect the tests results both locally and in
CI.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
When creating the configuration for the builtin monitor we try to get
the panel configuration for the builtin panel, but we don't proceed if
that monitor is currently inactive.
This is fine when adjusting an active configuration to the current
device rotation, but it isn't correct when we want to create a new
configuration based on another where the monitor is configured but not
yet enabled.
So, only find the panel configuration without looking the current state
but ensuring that the passed configuration will enable it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
When we get an orientation event we don't care about keeping track of the
configuration changes, but actually we can consider the new configuration
just a variant of the previous one, adapted to floating device hardware
events, so we only want to apply it if possible, but we don't want to keep
a record of it for reverting capabilities.
Doing that would in fact, break the ability of reverting back to an actual
temporary or persistent configuration.
For example when device orientation events happen while we're waiting for
an user resolution change confirmation, we would save our new rotated
configuration in the history, making then impossible to revert back to
the original persistent one.
So in such case, don't keep track of those configurations in the history,
but only keep track of the last one as current, checking whether the
new current is child or sibling of the previously one.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1221
Related to: https://gitlab.gnome.org/GNOME/mutter/-/issues/646
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
When creating a configuration taking orientation into account we're using
the sensors orientation even if this is currently not used (for example
when an accelerator is available, but there's no touch screen).
This would cause to have a different behavior when configuration is
created and when we're loading a known configuration on startup.
So always honor whether the monitor's orientation is managed or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
All the auto-rotation code is expecting to have a built-in panel, but we
still monitor accelerometer changes if we don't have one (uncommon, but
possible).
Thus manage the panel orientation in such case and update it on monitors
changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1233>
These are ClutterInputFocus subclasses, so this will trigger reset of
the input method. As the .done event is possibly deferred in the
zwp_text_input_v3 implementation, ensure the changes caused by the
reset are flushed immediately, before the button press is forwarded
to the client by MetaWaylandPointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940>
This mode is passed along by the ClutterInputMethod, the
ClutterInputFocus will preserve it and ensure it is honored
whenever the IM is being reset.
This mode is immediate. The ClutterInputFocus commits the
text directly without queueing a CLUTTER_IM_COMMIT event.
This is important so events are serialized in the right order
in the wayland implementations (i.e. commit before wl_pointer.press).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940>
In line with GTK, the input method context should be reset when clicks
are handled by the ClutterInputFocus user. The reset action can then
either clear or commit the preedit text, as configured by the IM module.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1940>
This commit adds support to atomic KMS backend for optional plane property
prop_fb_damage_clips. Some drivers (e.g. EVDI) take advantage of this
property and process only updated regions of the screen instead of
processing the full frame. This can save system resources.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1879>
Added a function `meta_window_set_inactive_since` it sets
xattr on the cgroup directory for the given MetaWindow.
Resource management daemons can then monitor these changes on xattr
and make allocation decisions accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960>
Currently the only way to get cgroup for a MetaWindow is to get it's
PID and perform a bunch of file accesses and string manipulations.
This is especially not feasible if we want to get the cgroup every
time a MetaWindow has gained or lost focus.
A solution to this is to cache the GFile for a cgroup path.
The creation and access of this GFile is handled by
`meta_window_get_unit_cgroup` function.
`meta_window_unit_cgroup_equal` is a utility function which allows
us to compare whether two MetaWindows belong to the same cgroup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960>
To utilize the API provided by libsystemd it would be better to
create a separate HAVE_LIBSYSTEMD configuration option instead of
having to rely on HAVE_NATIVE_BACKEND.
For now this will be utilized for getting the control group of a
MetaWindow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1960>
and the subsurface was not previously detached from it using
`wl_subsurface_destroy()`.
Without 'window-actor/wayland: Remove subsurface actors on dispose' this
test would fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1958>
commit c4a73e7950 added
code to cleanup the renderer when the meta backend is
disposed. Unfortunately, this introduced a crash when
the window manager is replaced.
This is because cleaning up the renderer involves talking
to the X server over a display connection that's closed
two lines higher as part of the clutter_backend_destroy
call.
This commit fixes the crash by swapping their order.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1965>
There is very little point in sending an X11 client message to
gnome-panel in case gnome-shell isn't handling the binding. We
can just as well do nothing, so do exactly that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1886>
Using "framebuffer_discard" in the list refers to an invalid extension.
The extension which introduces glDiscardFramebufferEXT is
"GL_EXT_discard_framebuffer".
With this fix, cogl_gl_framebuffer_fbo_discard_buffers can actually call
glDiscardFramebufferEXT.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1974>
The docu for `Popen.wait()` says:
> This will deadlock when using stdout=PIPE and/or stderr=PIPE and
> the child process generates enough output to a pipe such that it
> blocks waiting for the OS pipe buffer to accept more data.
Fixes 3caa5fea3c
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1971>
If for some reason uncrustify gets angry at our file and indent on/off
marks, it will result in an error code other than 0. Since in those
cases there is no output to diff with, we misinterpret those situations
as "the whole file should be deleted", which is far from it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1970>
Borrowed from Tracker, this script has different mode usages:
* --sha allows specifying a commit SHA, HEAD^ by default.
* --dry-run shows suggested changes in stdout, by default
the local tree is changed.
* --rewrite amends the last commit, in addition to performing
the changes.
This allows from simple style checks in the development tree,
automatically rewriting with the suggested changes (e.g. with
`git rebase --exec ./check-style -r`) and CI integration.
The script has per-function granularity, and works by re-styling
individually every commit, and inside every commit every chunk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1924>
We fetch a frame clock that we schedule update on when queuing
_NET_WM_FRAME_DRAWN events. In some situations this frame clock is the
one from the stage, and if there are multiple hotplugs in a row, we
failed to update it as there were no stage views changes on the window
actor itself. As an actor updates the stage views list on layout, When a
queue_frame_drawn() call was done (typically from an X11 event) after a
second hotplug, it'd attempt to schedule an update on the frame clock
from the previous hotplug, as it didn't get notified about any
stage-views changes since for itself there was none.
Fix this by not caching the frame clock at all and just fetch it every
time.
In the majority of cases, this fetching means iterating over a very
short list (most often a single entry, rarely more), so it's very
unlikely to be of any relevance. The only situations where it might be a
heavier operation is the short time between a hotplug and a layout, as
it will attempt to traverse up to the stage to find a clock, but that's
likely only a few levels, so even that is unlikely to be an issue.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4486
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
Make sure that when we've recreated views that we'll actually paint a
new frame for it. This was very rarely a problem, as views tend to
result in getting damage etc being queued as side effects of various
things, like layout, but e.g. when running certain tests, this might not
happen. There is no situation where we want to create a new view that
should remain unpainted, so just make sure we initialize it to become up
to date.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
This is more in line with the protocol, and allows us to remove some
awkward code that tries to "combine" different metadata from different
monitors into one, which sometimes meant picking an arbitrary "main"
monitor, or "and" metadata together to find a common ground.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1712>
Makes workspace transitions in gnome-shell look more seamless, since
both outgoing and incoming workspace have focused windows.
This is only done for click focus mode, since it's not known which
window would be focused for the other modes.
Track the state and recompute it when it changes, to avoid redrawing
the windows needlessly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
Each workspace has a window that will be focused when switching to that
workspace. Add a function to retrieve that window.
This is only relevant for click-to-focus focus mode, since with the two
other modes no window will be focused upon switching, and will only gain
focus when hovered.
This will be used in the next commit to make this window appear focused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
This was introduced by accident in commit 1467b6b02a
y-inverted textures in combination with shape masks appear to
be only commonly used with EGLstreams. However, as we draw the
shape mask ourselves, we don't want to apply the y-invert to it
as testified by the left over `cogl_pipeline_set_layer_matrix()`.
Note that we still allow to apply viemports and buffer transforms,
as the Xwayland mode setting emulation may use it (in fact only
the former, but it probably does not hurt to leave the later as well).
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1792
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1937>
Monitor configuration check tests can be very complex and in case of
failures we can't easily catch where a failure happened without entering
in debug mode, something that isn't always an option in CI or external
builders.
So add more debug statements in configuration check functions and use
macros to ensure that we print the caller function and location on more
complex check functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Primary monitor is just the same of the other monitors, but it has a
primary monitor flag. Since the computation of the scaling isn't
dependent anymore on the computed configuration we can now generate the
primary monitor config together with the others.
However, we've to ensure that the primary monitor is the first of the
configs list in order to properly compute the positioning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Compute the monitor scaling in a separated function using the primary
monitor (not its config) and pass it to the creation function instead.
This will allow removing the special logic for the primary monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Factorize the creation of a configuration inside one function that looks for
the primary monitor and the other monitors using the matching rules and
dispose them according to the chosen policy (checking if the result is valid
when using the suggested positioning).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Add a find_monitors function that allows to search for monitors that match
the MonitorMatchRule filter and use this to look for the primary monitor and
the other monitors that need to match the requested filter in order to be
configured.
Having just one function doing this kind of checks reduces the possibility
of unexpected results.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
Verify that the suggested monitor configuration contains only adjacent monitors,
and that if this is not the case we fallback to the linear configuration.
This can happen in case of multi-DPI setup, so add a test checking this too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
It could happen that monitors suggest to use coordinates that don't take
in consideration the scaling applied to one monitor, and such the
generated configuration is not valid because not all the monitors are
adjacent.
So enforce this check before accepting a suggested configuration as it
is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
We may need to check if rectangles region has adjacent neighbors and
so if there are no gaps in between monitors.
This can be done by checking if each monitor is adjacent to any other in
the same region.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/522>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
This code sneaked unconditionally, even though we can disable
tracing code with -Dprofiler=false. Add some COGL_HAS_TRACING
checks so that this code is also optionally built.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1951>
Will be used to trace a lot more, and with more details, and thus may
have a larger impact on what is actually measured. This potential impact
is the reason for enabling only when needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1700>
A trace "anchor" is a trace head (CoglTraceHead) that is placed in a
certain scope (e.g. function scope), but then only triggered in another
scope, e.g. a condition.
This makes it possible to have optional trace instrumentation, that is
enabled only given e.g. a debug flag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1700>
The failure to allocate was not properly handled, causing crashes later
on due to the offscreen being NULL.
#0 cogl_gl_framebuffer_bind (target=36160, gl_framebuffer=0x0)
#1 _cogl_driver_gl_flush_framebuffer_state (...)
#2 cogl_context_flush_framebuffer_state (read_buffer=0x55f48f386780, draw_buffer=0x55f48f386780, ...)
#3 cogl_framebuffer_clear4f (framebuffer=0x55f48f386780, ...)
#4 clutter_layer_node_pre_draw (...)
#5 clutter_paint_node_paint (...)
...
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1942>
When a selection owner advertises a mime type, but does not provide the
content upon a request for the mime type content, the requesting side
might wait indefinitely on the content.
To avoid this situation, add a timeout source, which will cancel the
selection transfer request after a certain timeout (15 seconds) passed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1874>
Currently, if g-r-d closes the read end of the pipe for a
SelectionRead() operation, due to realizing that the application, that
should provide the mime type content, does not provide any content,
mutter won't notice that and still assumes that the read() operation
on the pipe in g-r-d is still happening, as mutter never writes to the
pipe in that situation and therefore cannot realize that the pipe is
already closed.
The effect of this is, that if g-r-d aborts a read() operation and
requests a new read() operation via SelectionRead(), mutter will deny
the request since it assumes that the previous read() operation is
still ongoing.
Fix this behaviour by also checking the pipe fd in mutter before
denying a SelectionRead() request.
https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/60
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1874>
With some resolutions (such as 4096x2160) we may compute duplicated
scale factors because we used a too wide threshold to check for an
applicable value.
In fact, while when we're at the first and last values it's fine to
search applicable values up to SCALE_FACTORS_STEP, on intermediate ones
we should stop in the middle of it, or we're end up overlapping the
previous scaling value domain.
In the said example in fact we were returning 2.666667 both when
looking to a scaling value close to 2.75 and 3.00 as the upper bound of
2.75 (3.0) was overlapping with the lower bound of 3.0 (2.75).
With the current code, the lower and upper bounds will be instead 2.875.
Adapt test to this, and this allows to also ensure that we're always
returning a sorted and unique list of scales (which is useful as also
g-c-c can ensure that this is true).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1878>
We introduced META_MONITOR_SCALES_CONSTRAINT_NO_FRAC to get global scale
values however, this didn't work properly for some resolutions.
In fact it may happen that for some resolutions (such as 3200x1800) that
we did not compute some odd scaling levels (such as 3.0) but instead
its closest fractional value that allowed to get an integer resolution
(2.98507452 in this case).
Now this is something relevant when using fractional scaling because we
want to ensure that the returned value, when multiplied to the scaled
sizes, will produce an integer resolution, but it's not in global scale
mode where we don't use a scaled framebuffer.
So, take a short path when using no fractional mode and just return all
the applicable values without waste iterations on fractional values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1878>
Scaling values computation code served us well in the past years but
it's quite delicate and it has some issues in edge cases, so add a test
that verifies that the computed scaling values for all the most common
resolutions (and some that may be common in future) are what we expect
to be.
This may also serve us in future when we'd define a better algorithm to
compute the preferred scale, but this not the day.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1878>
When deriving the global scale from current monitor, we were just checking the
supported value by the primary monitor, without considering weather the current
scale was supported by other monitors.
Resolve this by checking if the picked global scale is valid for all active
monitors, and if it's not the case, use a fallback strategy by just picking the
maximum scale level supported by every head.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/407
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/336>
In Xrandr we were caching the available scaling modes that were computed just
for the current mode, for each monitor, while we can actually reuse the
default implementation, by just passing the proper scaling constraint.
In monitor we need then to properly filter these values, by only accepting
integer scaling factors that would allow to have a minimal logical monitor
size.
Fixes https://gitlab.gnome.org/GNOME/mutter/issues/407
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/336>
We only listen to it for 2 settings (drag threshold, double click
time), and we already have the stock ClutterSettings object tracking
the source of these. This code is redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1862>
Seems glGetString(GL_RENDERER) in the wild can return NULL, causing
issues with strstr(). Handle this more gracefully by using
g_return_val_if_fail(), that assumes a NULL renderer means software
rendering.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1931>
This will require some symbol exporting, but the benefit is that have
better control of what external test cases can do in terms of creating
more testing specific contexts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This makes it possible to declare the type in an installed header (so
that e.g. META_CONTEXT_TEST(context) works), but without having to
expose the MetaContextClass struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Add a method meta_context_destroy() that both runs dispose and unrefs
the context. Tear down is moved to dispose() so that things owned by the
context are destroyed when calling meta_context_destroy(), or when the
last reference is released.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Before we first created the MetaWaylandCompositor instance, which would
repare Clutter/Cogl so they could initialize and turn on Wayland display
server features, then later to initialize the rest. Now that part is
done by the Wayland infrastructure itself, so we don't need the early
initialization. Simplify things a bit by centralizing it all into a
single meta_wayland_compositor_new() call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This is done by keeping around a pointer to MetaContext as
"client_pointer" (which is practically the same as "user_pointer"
elsewhere), as well as creating a `MetaIceConnection` wrapper for ICE
connections.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
As with the compositor type enum, also have the X11 display policy enum,
as it's also effectively part of the context configuration. But as with
the compositor type, move it to a header file for enums only, and since
this is a private one, create a private variant meta-enums.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Since this tests the `--virtual-monitor` command line argument, it uses
the `MetaContextMain` variant of the context, as it's there that command
line argument is handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This object intends to replace the scattered functions that are used to
make up what is effectively a "mutter context". It takes care of the
command line arguments that is now done in main.c, persistant virtual
monitors, and the like.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
The clutter tests neeed to start and stop, thus uses their own main loop
instead of the one in MetaContext. Shouldn't matter, since nothing
in mutter should happen that makes the test self-terminate from inside
mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Users can add option entries, and it'll be part of the configuration
phase.
Create the main group manually to be able to set a user_data pointer;
this will be required to not have to rely on globals when parsing
options using a callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This intends to replace the call to `meta_register_with_session()` that
deals with X11 session management, and is called when the user is
"ready". In thet test context, doing that makes no sense, so make it a
no-op.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
The start phase creates the MetaDisplay object, and initializes Wayland, and
creates the main loop.
The run phase runs the main loop and handles returning an error if the
context was terminated with an error.
The terminate phase terminates the main loop, with or without an error.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
Configuration is the first step of the lifetime of a context, after
creation; it's here where argc/argv is processed, and it's determined
what kind of compositor, etc, it is going to be.
The tests always run as Wayand compositors, so the configuration is
quite simple, but will involve more steps later on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
It'll be part of and owned by MetaContext, intending to replace
`meta_is_wayland_compositor()`, but place it in a new file for public
enums so that it can be used from wherever.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This introduces a MetaContext implementation aimed to be used for test
cases, with as little boiler plate as possible needed in the test.
It currently doesn't do anything, just fills out the GObject boiler
plate and sets a name.
Build it into every core test, for compilation, even though it isn't
used anywhere yet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This type is intended to replace the scattered functions used to
configure how the Mutter compositor is run. It currently doesn't do
anything, and only has a human readable name, intended to be set to e.g.
"GNOME Shell".
It's an abstract type, and is intended to be used via either a future
`MetaContextMain` for real display server use cases, and a
`MetaContextTest` for test cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1861>
This job does:
1. Download the coverity bundle and untar it
2. Build mutter using clang and the coverity tool
3. Compress the coverity report
4. Upload for analysis
Things to note:
- Analysis are throttled, as per https://scan.coverity.com/faq#frequency
we qualify for 21 weekly builds, 3 daily. Mutter is sometimes a busy
project, so it seems we'd get often those consumed early in the day.
This is something we can resign to, but the times we'll try to upload
a report to have it rejected make the operation kinda pointless and
probably better throttled by ourselves.
- The task is manual, given the restrictions above.
- The task only applies on master, as the envvar holding the coverity
token is protected in gitlab.
- I had to use clang as the coverity tool doesn't seem to work ATM with
gcc as per recent Fedora.
- The coverity tarball is 1.2GB in size, which is a bit too big to have
it downloaded each time. As per their upload instructions, the tarball
gets updated twice yearly, so this is cached to minimize downloads.
- The coverity token for mutter is kept private/hidden in gitlab CI
settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1100>
Not sure how to update the damage or redraw clip or something; at least
this works properly when under a constantly-redrawing window, which is
ok for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
Max render time shows how early the frame clock needs to be dispatched
to make it to the predicted next presentation time. Before this commit
it was set to refresh interval minus 2 ms. This means Mutter would
always start compositing 14.7 ms before a display refresh on a 60 Hz
screen or 4.9 ms before a display refresh on a 144 Hz screen. However,
Mutter frequently does not need as much time to finish compositing and
submit buffer to KMS:
max render time
/------------\
---|---------------|---------------|---> presentations
D----S D--S
D - frame clock dispatch
S - buffer submission
This commit aims to automatically compute a shorter max render time to
make Mutter start compositing as late as possible (but still making it
in time for the presentation):
max render time
/-----\
---|---------------|---------------|---> presentations
D----S D--S
Why is this better? First of all, Mutter gets application contents to
draw at the time when compositing starts. If new application buffer
arrives after the compositing has started, but before the next
presentation, it won't make it on screen:
---|---------------|---------------|---> presentations
D----S D--S
A-------------X----------->
^ doesn't make it for this presentation
A - application buffer commit
X - application buffer sampled by Mutter
Here the application committed just a few ms too late and didn't make on
screen until the next presentation. If compositing starts later in the
frame cycle, applications can commit buffers closer to the presentation.
These buffers will be more up-to-date thereby reducing input latency.
---|---------------|---------------|---> presentations
D----S D--S
A----X---->
^ made it!
Moreover, applications are recommended to render their frames on frame
callbacks, which Mutter sends right after compositing is done. Since
this commit delays the compositing, it also reduces the latency for
applications drawing on frame callbacks. Compare:
---|---------------|---------------|---> presentations
D----S D--S
F--A-------X----------->
\____________________/
latency
---|---------------|---------------|---> presentations
D----S D--S
F--A-------X---->
\_____________/
less latency
F - frame callback received, application starts rendering
So how do we actually estimate max render time? We want it to be as low
as possible, but still large enough so as not to miss any frames by
accident:
max render time
/-----\
---|---------------|---------------|---> presentations
D------S------------->
oops, took a little too long
For a successful presentation, the frame needs to be submitted to KMS
and the GPU work must be completed before the vblank. This deadline can
be computed by subtracting the vblank duration (calculated from display
mode) from the predicted next presentation time.
We don't know how long compositing will take, and we also don't know how
long the GPU work will take, since clients can submit buffers with
unfinished GPU work. So we measure and estimate these values.
The frame clock dispatch can be split into two phases:
1. From start of the dispatch to all GPU commands being submitted (but
not finished)—until the call to eglSwapBuffers().
2. From eglSwapBuffers() to submitting the buffer to KMS and to GPU
work completing. These happen in parallel, and we want the latest of
the two to be done before the vblank.
We measure these three durations and store them for the last 16 frames.
The estimate for each duration is a maximum of these last 16 durations.
Usually even taking just the last frame's durations as the estimates
works well enough, but I found that screen-capturing with OBS Studio
increases duration variability enough to cause frequent missed frames
when using that method. Taking a maximum of the last 16 frames smoothes
out this variability.
The durations are naturally quite variable and the estimates aren't
perfect. To take this into account, an additional constant 2 ms is added
to the max render time.
How does it perform in practice? On my desktop with 144 Hz monitors I
get a max render time of 4–5 ms instead of the default 4.9 ms (I had
1 ms manually configured in sway) and on my laptop with a 60 Hz screen I
get a max render time of 4.8–5.5 ms instead of the default 14.7 ms (I
had 5–6 ms manually configured in sway). Weston [1] went with a 7 ms
default.
The main downside is that if there's a sudden heavy batch of work in the
compositing, which would've made it in default 14.7 ms, but doesn't make
it in reduced 6 ms, there is a delayed frame which would otherwise not
be there. Arguably, this happens rarely enough to be a good trade-off
for reduced latency. One possible solution is a "next frame is expected
to be heavy" function which manually increases max render time for the
next frame. This would avoid this single dropped frame at the start of
complex animations.
[1]: https://www.collabora.com/about-us/blog/2015/02/12/weston-repaint-scheduling/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
Scanout doesn't go through the usual path of compositing and doing
eglSwapBuffers, therefore it doesn't hit the timestamp query placed in
that path. Instead, get the timings by binding the scanout buffer to an
FBO and doing a timestamp query on the FBO.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
Add utilities that allow getting the current GPU timestamp and creating
a query which completes upon completion of all operations currently
submitted on a framebuffer. Combined, these two allow measuring how long
it took the GPU to finish rendering something to a framebuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1762>
This drops some custom building of various components that are now up to
date. While at it, start using the FDO_DISTRIBUTION_PACKAGES variable to
install packages, as it with the bumped ci-templates version also
doesn't install weak dependencies.
This also requires tweaking the pipewire dead lock work arounds, as it
changed configuration file paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1865>
This fixes a warning/error:
In function 'parse_settings',
inlined from 'read_settings' at ../clutter/clutter/x11/xsettings/xsettings-client.c:398:25:
../clutter/clutter/x11/xsettings/xsettings-client.c:202:13: error: 'buffer.byte_order' may be used uninitialized [-Werror=maybe-uninitialized]
202 | if (buffer.byte_order != MSBFirst &&
| ~~~~~~^~~~~~~~~~~
This is needed to bump the CI image from F33 to F34, which includes a
upgraded compiler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1865>
In order to make it possible to e.g. unload an unused DRM device, we
need to make sure that we don't keep the file descriptor open if we
don't need it; otherwise we block anyone from unloading the
corresponding module.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
We need to call eglBindAPI() with GLES before we setup the secondary
GPU blit. We've been lucky not really needing this, as it has been
GLES default, which is what the secondary blit uses, in order to not
depend on the default, or if we want to create the secondary blit
objects after initializing cogl, we must make sure to bind the right API
at the right time.
As we need to bind the GLES API when setting up the secondary blit, we
need to make sure that cogl gets the right API bound when that's done,
so Cogl can continue working. For this, add a "bind_api()" method on the
CoglRenderer object, that will know what API is correct to bind.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
The DRM buffers aren't really tied to mode setting, so they shouldn't
need to have an associated mode setting device. Now that we have a
device file level object that can fill this role, port over
MetaDrmBuffer and friends away from MetaKmsDevice to MetaDeviceFile.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Keep a private MetaDeviceFile instance for the GPU's managed by the
renderer. This is a step towards decoupling rendering from mode setting,
as well as on-demand holding of device file descriptors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Tags are meant to make it possible for a device file opener to tag a
file if it has affected the state the file descriptor is in; e.g. if it
has enabled a DRM capability.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
Handle open() failing due to being interrupted by trying again until it
either succeeds, or fails due to some other error. This was an error
handling path taken when opening sysfs files; do the same here to not
potentially regress once we open sysfs files with the device pool.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
It's only when we take/release from/to logind we need these two
integers, so only retrieve them when that's done. Making this change
makes it possible to open devices that don't have these parameters.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
This changes the way the KMS backends load; if we're headless, we always
use the dummy one and fail otherwise; in other cases, we first try the
atomic backend, and if that fails, fall back on the simple one.
The aim for this is to have the impl device open and close the device
when needed, using the device pool directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
This practically does the same thing as part of MetaLauncher, except
with added thread safety and caching. For example, opening the same file
a second time will return the same MetaDeviceFile, and only once all
acquired MetaDeviceFile's are released, will the file descriptor be
closed and control of the device released.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1828>
ClutterInputDevice's get_group_n_modes() vfunc is meant to return
-1 for groups that are out of the known range, not within. Fix the
early return condition, and let the native backend return correctly
the number of modes for the given group.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1920>
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.
Inspired by (and commit log mostly copied from) e6a13e5d57
("monitor-stream-src: Add before-paint watch to catch scanouts").
v2:
* Do not call stage_painted from before_stage_painted (Georges Basile
Stavracas Neto)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1707
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1902>
When the MetaWindow resize machinery for toplevels ended up in the
Wayland window implementation, we tried to avoid configuring
not-yet-mapped windows that just had its zero sized dimension pass
through the constraint machinery, resulting in a 1x1 sized window.
If we'd properly set up the min size metadata earlier, that 1x1 would
likely be the minimum size set of a window, which makes things harder to
predict when peeking at side effects.
However, what the side effect peeking intends to do, as documented in
the comment, was to figure out when the client hadn't committed any
buffer yet, i.e. during the initial map, and in those cases avoid
sending that nasty 1x1 size, resulting in silly window sizes. A more
robust way to detect this is instead checking when we shouldn't really
try resize things our own way, and in those cases early out as was done
before.
This means that, for a yet to me mapped window, we only ever want to
send an initial non-zero configuration when 1) it's initially maximized,
2) initially fullscreen, or 3) initially tiled in any way, as those are
the situations where the compositor is the one deciding the size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1912>
When drmModePageFlip() or drmModeAtomicCommit() unexpectedly failed (e.g.
ENOSPC, which has been seen in the wild), this failure was not handled
very gracefully. The page flip listener for the scanout was left in the
MetaKmsUpdate, meaning when the primary plane composition was later page
flipped, two page flip listeners were added, one for the primary plane,
and one for the scanout. This caused the 'page-flipped' event to be
handled twice, the second time being fatal.
Handle this by making 'no-discard' listener flag be somewhat reversed,
and say 'drop-on-error', and then drop all 'drop-on-error' listeners
when a MetaKmsUpdate failed to be processed.
Also for a "preserve" flagged update, don't ever trigger "discard"
callbacks just yet, as preserved updates are used again for the primary
plane composition, in order to not miss e.g. CRTC gamma updates, or
cursor plane updates, which were added separately.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1809
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1910>
A simply wrapper around `CoglTexture`, making it easy to reuse
content without roundtrip from GPU to CPU memory and back.
It optionally takes a clip rectangle which is implemented by
creating a `CoglSubTexture`. A limitation here is that floating
point clips are not supported.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1888>
The cancel phase for swipe gestures was not being handled, hence,
Wayland "end" events where not sent to clients when the gesture was
cancelled.
A swipe gesture is cancelled when extra finger(s) are put down on the
touchpad in the middle of the gesture or when some, but not all, of the
fingers are put up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1857>
There is an udev rule marking whether a device should be ignored by
mutter or not, but it was only respected on hotplug events not on init,
partly defeating its purpose. Fix this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1892>
Getting crossing events is necessary between client surfaces while
there is a popup grab in effect (e.g. allow press-drag-release in
menus), we should only stick with the focus surface while the pointer
is outside any client surface.
This partially undoes commit 79050004b0 (or, at least, mutter no
longer fixes the bug it claimed to fix). This will be addressed in
gtk4.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1885>
A view is only a 'CoglOnscreen' if it ends up on a CRTC, thus needs a
mode. Other views are for virtual monitors, and require no mode setting,
so exclude them from the pending mode set list.
This avoids a dead lock when we'll be waiting indefinitely for mode
setting on a virtual monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1891>
When using `CLUTTER_PAINT=damage-region` highlighting was conspicuously
absent during fullscreen animations like entering or leaving the
overview. That was because `queued_redraw_clip` was empty, because it
had been initialized from `redraw_clip == NULL` (full stage redraw).
Now we paint the damage region as the full view (which it is) instead
of nothing at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1890>
Just like we do on EGL. Two bits are required because
`cogl-clip-stack-gl.c` needs each stencil buffer element to be able to
count from 0 to 2.
This mistake probably went unnoticed because:
* Drivers usually provide more than 1 anyway; and
* Optimizations in `cogl-clip-stack-gl.c` avoid calling the code that
needs to count past 1 in most cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1873>
Previously we were using a mask of 0x1 for the lifetime of the stencil.
This was wrong for two reasons:
* The intersection algorithm needs to count up to a maximum 2, so a
mask of 1 would clamp to 1 instead. Then decrementing all pixels
resulted in all pixels being zero even though we want some to be 1.
So the stencil then blocked some color buffer pixels being rendered.
* The lifetime of the mask was too long. By leaving it non-zero at
the end of the function we could accidentally end up modifying the
stencil contents during our later color buffer paints.
This fixes faulty rendering of some actors seen in gnome-shell with
test case: `env COGL_DEBUG=stencilling`
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1873>
Previously we were using a mask of 0x1 for the lifetime of the stencil.
This was wrong for two reasons:
* The intersection algorithm needs to count up to a maximum 2, so a
mask of 1 would clamp to 1 instead. Then decrementing all pixels
resulted in all pixels being zero even though we want some to be 1.
So the stencil then blocked some color buffer pixels being rendered.
* The lifetime of the mask was too long. By leaving it non-zero at
the end of the function we could accidentally end up modifying the
stencil contents during our later color buffer paints.
This fixes missing rendering of some actors seen in gnome-shell with
test case: `env COGL_DEBUG=stencilling CLUTTER_PAINT=disable-clipped-redraws`
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1873>
The mutter tests require to run in a valid environment where a display
is available and a session bus, however currently we rely on the current
environment, and this may lead to unexpected behaviors.
So let's just ensure that a display is running through xvfb-run and
that a session bus is running in a temporary directory.
We also ensure to use the gsettings memory backend, even because by
setting TestEnvironment we ensure that no other env variable is leaked
to the test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1876>
The cogl tests need to run with a display server set, however since we
use TestEnvironment, only the listed env variables will be exposed to
the test and so no DISPLAY will be set when launching it with
gnome-desktop-testing-runner.
As per this, just run the tests using xvfb-run so that we match what's
happening in CI and we ensure that the tests are run in a safe
environment.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1876>
When running multiple tests at once (with --all) as in the
installed-tests cases, we may open and close the display multiple times,
this leads to setting the alarm filter each time that the x11 display is
opened (causing a critical error) because we never disconnect from the
::x11-display-opened signal.
So disconnect from the signal on test destruction, to avoid this to be
emitted multiple times.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1876>
We first initialized the Wayland infrastructure, then the display, but
on shutdown, we first teared down the Wayland infrastructure, then the
display.
Make things a bit more symmetric and tear down the display before
Wayland. This however means we need to tear down some things Wayland a
bit earlier than the rest. For now this is a separate function, but
eventually, it can be replaced with a signal shared by the backend's
'prepare-shutdown' signal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This way we can initialize without having any way to retrieve it via
some global variable. This isn't needed now, but will be once Wayland
infrastructure initializiation is done in a single step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This is especially important as we might end up here when initializing
the Wayland infrastructure. Later that will be done in one step, meaning
the "get_default()" function will not work properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
It might not be there when shutting down, so get it from a more managed
place. Note that this isn't strictly needed right now, but eventually,
the MetaWaylandCompositor pointer will be cleared using a g_clear*()
helper, which clears the pointer before freeing the instance, which
wouldn't work here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This will allow us less awkward startup, where previously we had to
pre-initialize Wayland very early so Cogl could bind the Wayland display
when it initialized. Move things around so we bind the Wayland EGL
display when initializing the rest of Wayland infrastructure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1863>
This object takes over the functionality of meta-idle-monitor-dbus.c,
meta-idle-monitor.c and meta-backend.c, all related to higher level
management of idle watches etc.
The idle D-Bus API is changed to be initialized by the backend instead
of MetaDisplay, as it's more of a backend functionality than what
MetaDisplay usually deals with.
It also takes over the work of implementing "core" idle monitors. The
singleton API is replaced with thin wrapper functions on the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1859>
It just complicates things; we can't run them right now, so just get rid
of the runtime variability; just change the macros if you want to tweak
the test, would you be able to get it running.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
Wayland support is not really a "backend" thing, it just lacked a better
place to store its instance pointer. Eventually we'll have a better
place, but prepare for that by initializing it together with the more
similar subsystems.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
The rest of debug flag details are in util.c and util.h, make things
less scattered by moving the rest to util.c too.
While at it, put the coredump:ability setting needed for being suid
there too, so we have a common place for initializing "debug utils".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1833>
Commit 64c9c9c5b0 fixed monitor
screencasting, when fractional screencasting is enabled.
For the remote desktop usage, NotifyPointerMotionAbsolute() submits
the new mouse pointer position in addition to the stream, where the
mouse pointer was moved.
When not using fractional scaling, the mouse pointer position is
correct.
With the usage of fractional scaling, the mouse pointer position is
wrong, as the scale of the position is applied two times.
Fix this behaviour, by reverting the second scale by dividing by the
logical monitor scale, when fractional scaling is used.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1808
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1867>
When finalizing, the MetaDisplay instance will already be gone, so to be
able to gracefully tear down the clipboard integration, make sure to
close sessions before the display is closed, i.e. on prepare-shutdown.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1853>
The callback on_displayfd_ready() would unconditionally set the return
value to TRUE, regardless of the condition.
Use the GIO condition to determine if there was data written and adjust
the return value accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1851>
Some clients such as mpv might set the WM_TITLE as a UTF8_STRING based
on some unconverted/unvalidated metadata that is not actually UTF8. This
would then be set as the title of a MetaWindow (in the absence of a
valid UTF8 _NET_WM_TITLE). The shell then tries to use this window title
for things like the overview or the window switcher where it would
trigger an UTF8 validation error and leave the shell in an unusable
state.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1794
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1850>
This commit adds scaling support to clutter_stage_capture_into, which
is currently used when screencasting monitors. This is supposed to
fix graphical issues that arise when using fractional scaling.
Fixes#1131
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1855>
We initialize, but might not start, e.g. when a test case just needs a
backend and doesn't start mutter. When cleaning up, we'll still try to
clean up Xwayland integration, and this commit handles cleaning up
without having made the mess.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1856>
We make objects inert when disabling the seat, but we requests may still
have effect. This is especially bad if disabling is followed by
destroying, but also means e.g. set_cursor() not doing an early out
after the pointer capability was disabled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
MetaDisplay does a lot of things, and is a central part to anything
window management. To let Wayland units have an easier time tearing
down, make it so that the Wayland infrastructure is terminated before
MetaDisplay.
This also makes sure that X11 support is turned off, so that we don't
stumble upon Xwayland terminating due to the Wayland socket connection
being broken. Will mitigate that in a better way in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
We might not be the only entity holding on to the X11 GdkDisplay,
meaning the X11 connection will stay alive indefinitely, e.g. if the gjs
context has some reference to it.
Avoid running into issues due to X11 connection errors by setting the
libX11 handlers to no-ops, so when we are terminating; that means the
GDK X11 connection can stay "alive" until its too late, and we'll just
silently ignore any connection errors that may happen due to the
lingering GDK display reference.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
It keeps references to cursors, and cursors keep references to DRM
buffers. In order to be able to clean up on exit, explicitly destroy the
cursor tracker on shutdown.
We can't rely on GObject reference counting, as gjs might hold onto a
reference until it's garbage collected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
Various things, e.g, the renderer, the stage, either directly or
indirectly depends on GPU objects being alive during tear-down. Make it
so, by moving GPU cleanup after the other cleaning. This will allow
tearing down a couple of more objects.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
The first phase happens early, which discards pending page flips,
meaning the references held by those page flip closures are released.
The second phase happens late, after other units depending on the KMS
abstraction, have been cleaned up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
We already swapped the front buffer, and even if it didn't get
presented, we should still swap our representation of the state, to not
get into a confused buffer tracking state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1822>
All pointer a11y is a fabrication of Clutter backend-independent
code, with the help of a ClutterVirtualInputDevice and with some
UI on top.
On the other hand, MetaInputSettings is a backend implementation
detail, this has 2 gotchas:
- In the native backend, the MetaInputSettings (and pointer a11y
with it) are initialized early, before the ClutterSeat core
pointer is set up.
- Doing this from the MetaInputSettings also means another dubious
access from the input thread into main thread territory.
Move the pointer a11y into ClutterSettings, making this effectively
backend-independent business, invariably done from the main thread
and ensured to happen after seat initialization.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1765
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1849>
Since commit d2f8a30625 we use Graphene to union paint volumes, it
turns out a quite severe issue snuck in during review of that MR though:
Unioned paint volumes (so paint volumes of any actors with children) now
have negative heights. Once projected to 2d coordinates they luckily are
correct again, which is why everything is still working.
The problem is that obvious once looking closer: For the y coordinates
of the unioned paint volume we confused the maximum and the minimum
points and simply used the wrong coordinates to create the unioned paint
volume.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1827>
The graphene functions used by clutter for picking assume that boxes are
inclusive in both there start and end coordinates, so picking at y
coordinate 32 for an actor with the height 32 placed at y coordinate 0
would still be considered a hit. This however is wrong as 32 is the
first position that is not in the actor anymore.
Usually this would not be much of a problem, because motion events are
rarely ever at exactly these borders and even if they are there will be
another motion event soon after. But since actors in gnome-shell usually
are aligned with the pixel grid and on X11 enter/leave events are
generated by the X server at integer coordinates, this case is much
more likely for those.
This can cause issues with Firefox which when using client side
decorations, still requests MWM_DECOR_BORDER via _MOTIF_WM_HINTS to have
mutter draw a border + shadow. This means that the Firefox window even
when using CSD is still reparented. For such windows we receive among
others XI_RawMotion and XI_Enter events, but no XI_Motion events. And
the raw motion events are discarded after an enter event, because that
sets has_pointer_focus to TRUE in MetaSeatX11. So when moving the cursor
from the panel to a maximized Firefox window the last event clutter
receives is the enter event at exactly integer coordinates. Since the
panel is 32px tall and the generated enter event is at y position 32,
the picking code will pick a panel actor and the focus will remain on it
as long as the cursor does not leave the Firefox window.
Fix this by excluding the bottom and right border of a box when picking.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4041
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1842>
Compositor behaviour when calling `wl_data_device_manager_get_data_device`
for the same seat multiple times is not very clearly defined in
the spec and both Mutter and Weston currently don't handle
the DnD case properly.
While Weston handles DnD only for the last created data device,
Mutter, because of some internal reshuffling, ends up toggling
between two devices.
Properly handling this case requires some bigger changes. So
in order to behave predictable and in line with Weston,
only take the last created data device into account while
still keeping the previous created ones around.
The main affect client here is Firefox, which gets very
confused by the toggling behaviour and becomes more stable
with this patch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1841>
Virtual Kernel Mode Setting (vkms) is a virtual /dev/dri/card* device
not backed by any actual hardware. It's intended for testing purposes,
e.g. to run tests suites with a reproducable setup, or in continuous
integration pipelines.
Currently mutter don't have any tests that can run on top of vkms, but
will eventually get that. To prepare for the ability to do that, and
having said kernel module loaded without causing wierd issues with any
active session, add an udev rule that tells mutter to ignore any vkms
device.
Otherwise, when vkms is loaded, mutter would detect it, assume it's a
regular monitor, configure it as such, thus add a region of the stage
that ends up nowhere, which isn't very helpful. It might also conflict
with running actual tests that need to interact with vkms if the active
session has taken control of it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1740>
With atomic mode setting, commits don't work when CRTCs aren't enabled,
which they aren't when we're power saving. This means the gamma state
fails to being update. To fix night light and for whatever other reason
gamma ramps was changed during power saving by marking the CRTC gamma
state as invalid when leaving power saving, as well as when resuming.
This means that the next frame will append the CRTC gamma state to the
KMS commit.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1755
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1835>
This GSource is not being properly unref nor the variable holding it
cleared. This on one hand leaks the GSource memory, on the other hand
may trigger warnings in keyboard_repeat() as the source may be
(reentrantly) cleared, yet we don't exit early as
seat_impl->repeat_source is never NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1839>
When a viewport source rect or destination size is set, `stex->dst_width`
gives us the the cropped and/or scaled size. At this step, we need the
uncropped/unscaled size however.
Note: this is only ever relevant if buffer transform and viewport are
used together - otherwise the values are the same.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1836>
The shadow size is factored into the paint volume MetaWindowActorX11
returns in its get_paint_volume() vfunc override, so we should
invalidate the paint volume every time that shadow might change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1829>
Turns out ClutterClones need a bit of extra handling as always, there's
currently nothing that invalidates a clones paint volume when the source
actors paint volume changes.
Since ClutterClones get_paint_volume() implementation simply takes the
source actors paint volume and returns that, we should make sure they
are kept in sync and invalidate the clones paint volume as soon as the
source actor gets its PV invalidated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1829>
When using buffer transforms and viewports together, we currently
apply the transformation (read: rotation) first, resulting in
wrong buffer coordinates for viewport source rects.
Flip the order in whitch we apply our matrix transformations.
This can be tested e.g. via:
`weston-simple-damage --use-viewport --transform=flipped-180`
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1832>
If a subsurface first gets reordered and afterwards detached from
the parent before the parent surface got commited, we currently
would end up reattaching the subsurface to its previous parent.
While clients should avoid this behaviour, it's legit according
to the spec.
We already prevent similar cases where the subsurface is destroyed -
extend that check to detaching, which includes the destroy case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1831>
Currently when reordering subsurfaces, we un- and reparent all child
actors of the window actor. This is unnecessarily wasteful and
triggers bugs in clutter. While the underlying issue should be fixed
eventually, simply reorder the actors with the tools clutter provides
us with, avoiding those bugs and likely being faster as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1831>
Users who customized their workspace shortcuts before updating to
GNOME 40 are experiencing troubles when trying to use the same
keybinding for the horizontal shortcuts, because of hidden conflicts
with the vertical ones.
We can address this by registering the old shortcuts with Settings
without showing them in the UI, so that they are taken into account
by Settings' conflict resolution.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1740
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1814>
The X server generates a property change notification whenever it processes a
property change request, even if the value of the property is not changing. This
triggers libgdk to probe all display outputs, which can be slow depending on
which display driver and hardware are in use.
#0 0x00007f8e4d5e91a0 in XRRUpdateConfiguration () at /usr/lib/libXrandr.so.2
#1 0x00007f8e505208da in _gdk_x11_screen_size_changed (screen=0x5566e4b7e080, event=0x7ffe0e44bd60) at ../gdk/x11/gdkscreen-x11.c:1199
#2 0x00007f8e505066d1 in gdk_x11_display_translate_event (translator=0x5566e4b5b110, display=0x5566e4b5b110, event=0x7f8dec001b20, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkdisplay-x11.c:1201
#3 0x00007f8e505135a0 in _gdk_x11_event_translator_translate (translator=0x5566e4b5b110, display=0x5566e4b5b110, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventtranslator.c:51
#4 0x00007f8e50512c97 in gdk_event_source_translate_event (event_source=0x5566e4b764a0, xevent=0x7ffe0e44bd60) at ../gdk/x11/gdkeventsource.c:243
#5 0x00007f8e50512f57 in _gdk_x11_display_queue_events (display=0x5566e4b5b110) at ../gdk/x11/gdkeventsource.c:341
#6 0x00007f8e50497644 in gdk_display_get_event (display=0x5566e4b5b110) at ../gdk/gdkdisplay.c:442
#7 0x00007f8e5051301f in gdk_event_source_dispatch (source=0x5566e4b764a0, callback=0x0, user_data=0x0) at ../gdk/x11/gdkeventsource.c:363
#8 0x00007f8e516ecf9c in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#9 0x00007f8e51740a49 in () at /usr/lib/libglib-2.0.so.0
#10 0x00007f8e516ec503 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#11 0x00007f8e508ef5fd in meta_run_main_loop () at ../src/core/main.c:928
#12 0x00007f8e508ef60e in meta_run () at ../src/core/main.c:943
#13 0x00005566e450842a in ()
#14 0x00007f8e50649b25 in __libc_start_main () at /usr/lib/libc.so.6
When GNOME is animating a display fade when the night light feature is toggled
on or off, it sends a lot of change requests for the CTM property in the
process, which triggers a lot of display probes from gdk. In the case of the
night light feature, the CTM itself is not actually changing, so these requests
are redundant. Fix this by caching the CTM value in the MetaOutputXrandr and
skipping the server requests if it's not being changed.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3978
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1816>
When we set the matrix, we checked the device mapping mode in the main
thread, then passed along the calculated matrix to the input thread for
application. This could however be racy, as the mapping mode is managed
in the input thread. Fix this by sending the unaltered matrix, having
the input thread checking the mapping mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1806>
The connector state wasn't properly predicted, as it earlied out if
the connector wasn't part of a mode set connector list.
Instead use the old CRTC to check whether it was used in any mode set,
and whether the connector was part of any new mode set, to predict
whether the connector is inactive or active.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
When a device only had mode sets which turned off monitors, not enabling
anything, there would be no KMS update created and posted, and the
active monitors would remain on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1821>
On hybrid graphics system, the primary path used to transfer the stage
framebuffer onto the dedicated GPU's video memory preparing for scanout,
is using the dedicated GPU to glBlitFramebuffer() the content from the
iGPU texture onto the scanout buffer.
After we have done this, we reset the current EGL context back to the
one managed by cogl. What we failed to do, however, was to reset the
current EGL context when we inhibited the actual page flip due to having
entered power save mode.
When we later started to paint again, Cogl thought the current EGL
context was still the correct one, but in fact it was the one used for
the iGPU -> dGPU blit, causing various EGL surface errors, and as a side
effect, eventually hitting an assert.
Fix this by making sure we reset to the Cogl managed EGL context also
for this case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Destroying the EGLSurface frees the underlying container structs. When
we call gbm_surface_release_buffer() with a gbm_surface the EGLSurface
was created from, doing that after the EGLSurface was destroyed results
in attempts to access freed memory. Fix this by releasing any buffer
first, followed by destroying the EGLSurface, and lastly, the
gbm_surface.
This was not a problem prior to CoglOnscreen turning into a GObject, as
in that case, the dispose-chain was not setup correctly, and the
EGLSurface destruction was done in the native backend implementation.
This also changes a g_return_if_fail() to a g_warn_if_fail(), as if we
hit the unexpected case, we still need to call up to the parent dispose
vfunc to not cause critical issues.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
It's handled by CoglOnscreenEgl's dispose() implementation. It was
failed to be invoked in the past because the old non-GObject web of
vtables were not setup correctly, meaning the old generic EGL layer of
the CoglOnscreen de-init was never invoked.
When the type inheritence was cleaned up, this mistake was not cleaned
up, so do that now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1803>
Mutter would deny the application the right to resize itself during an
interactive resize, to avoid the user and the client to fight for the
size.
When the client is not allowed to resize, it would use the client rect
rather than the buffer rect.
As a result, the client window with client side decorations would
quickly shrink to its minimum size.
Use the buffer rect instead, so that the size really remains the same.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1674
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1777>
Meson doesn't seem to handle depending on generated headers, at least
when those headers are pulled in indirectly via another header file.
Luckily, we don't actually need to include the generated D-Bus boiler
plate in meta-monitor-manager-private.h, since the MetaMonitorManager
type no longer is based on the D-Bus service skeleton.
So, by moving the inclusion of the generated D-Bus header file into
meta-monitor-manager.c, we should hopefully get rid of the sporadic
build issues.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1682
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1819>
If there was only a single mode, add the common modes to provide options
to select other resolutions than the built in default. This avoids
issues where the connector listed multiple supported modes, but where
the common modes added would exceed the possible bandwidth. We could
probably make an attempt to filter out more modes from the common mode
list to avoid these issues, but it's likely that the driver already
lists suitable modes, meaning there is no point in adding the common
modes.
The common modes were initially added[0] to add modes to connectors with
a single bundled mode, so we shouldn't regress the original bug fix.
[0] https://bugzilla.gnome.org/show_bug.cgi?id=744544
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1232
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1824>
Lets wait until we have better ways to unredirect client buffers before
we start enabling KMS modifiers for amdgpu and nouveau; we end up with
mismatch between client buffer modifiers and primary plane modifier,
which right now needs to be the same for unredirection.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
The intel DRM driver is known for not being able to handle multi head
setups when KMS modifiers are enabled, due to the implicitly selected
modifiers, while being more suitable for single head setups, cause
bandwidth issues when a certain number of monitor times resolution and
refresh rate is configured.
We don't yet support automatically finding a combination of modifiers
that work, and have because of this disabled KMS modifiers unless the
driver actually needs it.
Lets flip this configuration the other way around, changing the current
udev rule to decide wen to *disable* KMS modifier support, as it so that
only the Intel driver has this problem, while on the other hand, there
several drivers that requires modifiers to function at all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1792>
The input thread is in deep water doing the meta_is_*() check itself,
as that pokes the MetaMonitorManager managed by the main thread. Use
the getter from the MetaViewportInfo instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
We need to pass this info from the main thread, as that pokes the
MetaMonitorManager underneath. Store it in the MetaViewportInfo
so that the input thread can use this information.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
Updating the last_paint_volume while painting has proven itself to be
quite prone to issues: First we had to make sure actors painted by
offscreen effects get their last_paint_volumes updated correctly (see
0320649a1c), and now a new issue turned up
where we don't update the paint volumes while a fullscreen unredirect is
happening.
To stop those issues from happening and to lay the foundation for using
the last_paint_volume for other things, update the last_paint_volume in
a separate step before painting instead of doing it in
clutter_actor_paint().
To save some resources, avoid introducing another traversal of the
scenegraph and add that step into the existing step of updating the
stage_views lists of actors. To properly update the paint volumes, we
need to do that after finishing the queued redraws, which is why we move
clutter_stage_maybe_finish_queue_redraws() to happen before the new
clutter_stage_finish_layout().
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1699
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
The priv->paint_volume field of ClutterActor stores the cached paint
volume in the actors local coordinate system. It consist of the actors
paint volume itself and the union of all children paint volumes.
We want to invalidate those cached paint volumes according to the
following rules:
- If an actors transformation matrix changes, all paint volumes of the
parent-tree need to be invalidated (that's because the parent-volumes
have unioned the actors paint volume). Our own paint volume does not
need invalidation since the transformation matrix is not applied to it.
- If an actors allocation-size changes, its own paint volume and all the
volumes of the parent-tree need to be invalidated. That's because the
allocation-size is used as the size of the paint volume.
- If a clip gets set or clip_to_allocation gets enabled for an actor,
its own paint volume and all the volumes of the parent-tree need to be
invalidated. That's because the clip is factored in when creating the
paint volume.
So far we did this invalidation in various places and the invalidation
up the parent-tree happened inside clutter_actor_real_queue_relayout().
We did not invalidate on changes to the actors transformation matrices
and the invalidation in clutter_actor_real_queue_relayout() was more
like a "big hammer" that probably invalidated unnecessarily a few times.
So introduce proper infrastructure to invalidate those cached paint
volumes of actors only in the cases where they actually need to be
invalidated. To do that, we reuse the transform_changed() function and
introduce a new function queue_update_paint_volume() that invalidates
the paint volumes up the actor tree.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
ClutterActors can override the get_paint_volume() vfunc in case they
draw outside the allocation. That's used by a bunch of actors, for
example ClutterText or StViewport in gnome-shell.
In case of StViewport, the paint volume returned depends on the value of
the StAdjustment, which means when we start to cache paint volumes more
agressively in ClutterActor, we'll need to add API that allows
StViewport to invalidate the paint volume. So introduce
clutter_actor_invalidate_paint_volume() to invalidate the cached paint
volume.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1773>
Use the new API to make sure the shaped texture has a valid size
during the next layout phase.
This is needed here because, quoting the previous commit:
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1718
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
When the texture size is invalidated using `invalidate_size()`, the new
size will only get calculated the next time `update_size()` is
called. This happens e.g. in `meta_shaped_texture_get_preferred_size()`
via `ensure_size_valid()`.
`update_size()` can chain up to `clutter_content_invalidate_size()`
as well as emitting a `size-changed` signal. If this happens during
layout, the result is a 'change the layout conditions during layout'
issue, causing heavy breakage in e.g. the Shell overview.
To fix this, expose `ensure_size_valid()` as API so callers can make
sure the texture has a valid size without creating redundant size
invalidations calls.
Note that if a buffer with a new size is attached we already trigger
`update_size()` explicitely, avoiding such situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1799>
If only a viewport destination size is set, the noop viewport has
to take the buffer scale into account.
If a viewport source but no viewport destination size is set, the
destination size is that of the viewport source, not of the whole
texture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1786>
The action might not have been triggered yet, as per its trigger
threshold. This doesn't mean we shouldn't reset the point(s) accumulated
so far.
This fixes those touchpoints persisting after disable/enable, thus
making gesture recognition fail from there on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1791>
We might want to perform distance/threshold checks in the ::prepare
vfunc, but we didn't record the last motion event yet. This used to
give a delta of 0/0 between the press and last motion coordinates,
despite the ClutterGestureAction having a trigger threshold. This
happens no longer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1791>
The usage of clutter_actor_get_preferred_width/height() for building the
pick box can trigger Clutters size negotiation machinery in case the
allocation of the actor is invalidated, with commit 82f3bdd1 we worked
around that by excluding actors with invalidated allocations from
picking.
There's no need to do that though, when picking we always want to
operate on the last known allocation of the actor, since that is what's
actually painted on the screen.
So instead of not picking at all when an actors allocation is
invalidated, just use the size of the last allocation. We still have to
factor in one extra case, that's when an actor hasn't gotten any
allocation yet: In that case we want to exclude the actor from picking
since the actor is not on the screen yet.
This fixes a regression introduced by the commit mentioned above where
picking wouldn't work on windows that have just been resized.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1674
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1784>
If a client is naive enough to assume that it can set the selection while
it has got no surfaces, mutter will simply ignore the request and leave
the selection unchanged.
This is good and the expected behavior, however the poor client that did
this will enter in an inconsistent state where it "claimed" the selection,
but nobody told it that the wl_data_source is not current.
So, when the client is focused the next time, it will receive wl_data_offers
as usual, but it will still think all the time that it is owning the
selection. In the case of GTK, that takes client-side shortcuts, so any
attempted paste will still bring back the client-side aborted selection.
To fix this, cancel the selection right away if it happened while unfocused,
the client will be able to undo its own failed selection, and not assume
that future offers are its own.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1469
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1772>
It seems to be the preferred format of the Mesa V3D driver on
Raspberry Pi 4. If the compositor doesn't advertise it then Mesa will
fallback from `zwp_linux_dmabuf_v1` to `wl_drm`, incorrectly. Meaning
it will keep using a buffer with modifiers on an interface that does
not have modifiers.
Add support for `DRM_FORMAT_ABGR2101010`. It works, and prevents Mesa
from taking its broken fallback path.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1520
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1798>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
As documented in g_once_init_enter(): "While @location has a volatile qualifier,
this is a historical artifact and the pointer passed to it should not be
volatile.". And effectively this now warns with modern glibc.
Drop the "volatile" qualifier from these static variables as it's expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1785>
For Xwayland, mutter creates the sockets in the standard /tmp/.X11-unix
directory.
Yet, if that directory already exists, it may have been created by
another user with full control over the created socket.
To avoid that issue, if the directory /tmp/.X11-unix already exists,
check that the permissions are as we expect, i.e. the directory belongs
to either root or the user herself, is writable and has the sticky bit.
Thanks to fabian@ritter-vogt.de for reporting that issue.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1708
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1787>
Unlike other subsurface state, placement operations need to get
applied in order. As per spec:
```
Requests are handled in order and applied immediately to a pending
state. The final pending state is copied to the active state the
next time the state of the parent surface is applied.
```
Having placement operations being part of the subsurface state
makes it difficult to support arbitrary orderings. Make them
part of the parents surface pending state instead.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1691
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1768>
Some events such as the proximity one requires a device to be set before
we process them, so ensure we process the event details after we've
added the device to the seat.
This may lead to handle a device-removed signal before the clutter event
but it's anyways not different from what we did before commit 012c0a18
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1779>
The CallyStage objects lifetime is tied to the stage, so if we add a
weak pointer to it, we won't be able to remove it, as we would try to do
so not until the stage itself is being disposed, at which point removing
it fails. However, not removing it will make the stage try to clean up
the weak refs, and since it does this more or less directly after
freeing the cally stage, it ends up writing NULL to freed memory,
causing memory corruption.
Fix this by avoiding adding the weak pointer when that pointer is to the
stage.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
MetaInputSettings unref:ed the seat on destruction, but it never ref:ed
it on construction, meaning it "stole" the reference from the rightful
owner. Make MetaInputSettings less of a thief.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1775>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
In case the shell ignores or can't accept the restart request we should
hide the message that has been just requested to be shown.
As per ::show-restart-message signal documentation, this has to be done by
emitting the signal with a NULL message.
So follow the API properly in such case
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1780>
In non-systemd managed session we are unable to start services on
demand. Instead, gnome-session will start everything at login time,
including any X11 related service (i.e. gsd-xsettings).
However, in order to start gsd-xsettings, Xwayland needs to be started
already. Otherwise it will connect to GNOME_SETUP_DISPLAY and login will
hang at that point.
Fix this by detecting whether mutter is running in a systemd unit. If it
is, we assume that we are systemd managed and the machinery to start the
services works fine. If not, we assume that the session management may
unconditionally try to start X11 related services and Xwayland must be
started in order to not block this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1771>
On Wayland MetaInputSettings is part of the input thread. Connecting
a GSettings binding to the default ClutterSettings could result in the
change notification being emitted on the input thread. This then could
end up triggering the same handler from two different threads at the
same time. In the case of the ClutterText layout cache it was attempting
to unref the same layout twice, leading to a crash.
This can be avoided by simply removing the GSettings bind. This does not
cause changes to this setting to be missed by ClutterSettings because it
itself already sets up a bind.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1696
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1776>
When deciding if `configure` event should be sent,
`meta_window_wayland_move_resize_internal` compares requested window size
with `window->rect` size. However, `window->rect` is only updated when `commit`
is received. So the following sequence produces incorrect result:
1. a window initially has size `size1`
2. `move_resize_internal` is called with `size2`. `configure` is sent
3. `move_resize_internal` is called with `size1` to restore original size,
but `commit` for `size2` haven't arrived yet. So `window->rect` still has size
`size1`, and thus new `configure` is not sent
4. `commit` for `size2` arrives, window changes size to `size2`
Expected window size in the end: `size1`
Actual: `size2`
To fix the issue, take size from pending `configure` events into account.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1627
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1755>
With the surfaceless mode in the headless backend, it's now possible to
initiate the headless mode without any mode setting devices, or render
nodes, without any special CI runner privileges.
The native backend tests include screen cast tests, so make them
possible to run by starting pipewire. Testing shows that enabling audio
support (pulseaudio & jack compat layers) makes the tests dead lock and
eventually timeout, so disable those features for now.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This eliminates the need for any render node or device nodes, thus can
be used without any graphics hardware available at all, or with a
graphics driver without any render node available.
The surfaceless mode currently requires EGL_KHR_no_config_context to
configure the initial EGL display.
This also means we can enable the native backend tests in CI, as it
should work without any additional privileges.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Tests that creating and starting a virtual screen cast monitor works,
and that at least one one buffer is processed.
Currently the content of the buffer isn't checked more than it can be
mmap():ed. Only MemFd buffers are tested for for now, as DMA buffers
would need a surfaceless EGL context to check properly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The new RecordVirtual API creates a virtual monitor, i.e. a region of
the stage that isn't backed by real monitor hardware. It's intended to
be used by e.g. network screens on active sessions, virtual remote
desktop screens when running headless, and scenarios like that.
A major difference between the current Record* API's is that
RecordVirtual relies on PipeWire itself to negotiate the refresh rate
and size, as it can't rely on any existing monitor, for those details.
This also means that the virtual monitor is not created until the stream
negotiation has finished and a virtual monitor resolution has been
determined.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The area source, window source, and monitor source, currently set up the
stream size up front, given the area, maximum allowed window size or
monitor resolution, but for to be introduced sources, the size will be
negotiated using PipeWire, instead of specified via the D-Bus API. This
commit changes the internal source API to allow for this. There are
currently no users of this new behaviour.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
There may be a race between the ability to turn stream relative input
coordinates and turning them into screen coordinates, due to the future
scenario where the entity backing a stream is created and managed ad-hoc
depending on PipeWire stream negotiations.
When an input event is sent during this time, drop it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Make it possible to create persintent virtual monitors using command
line argument. This will not be the only way to create virtual monitors,
the primary way will be using the screen cast API, but using command
line argumenst is convenient for debugging purposes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The testing currently done is:
* Creating a virtual monitor succeeds and gets the right configuration
* Painting a few times results in the expected output
* Changing the content of the stage also changes the painted content
accordingly
* Destroying the virtual monitor works as expected
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This adds a test framework that makes it possible to compare the result
of painting a view against a reference image. Test reference as PNG
images are stored in src/tests/ref-tests/.
Reference images needs to be created for testing to be able to succeed.
Adding a test reference image is done using the
`MUTTER_REF_TEST_UPDATE` environment variable. See meta-ref-test.c for
details.
The image comparison code is largely based on the reference image test
framework in weston; see meta-ref-test.c for details.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Virtual monitors are monitors that isn't backed by any monitor like
hardware. It would typically be backed by e.g. a remote desktop service,
or a network display.
It is currently only supported by the native backend, and whether the
X11 backend will ever see virtual monitors is an open question. This
rest of this commit message describes how it works under the native
backend.
Each virutal monitor consists of virtualized mode setting components:
* A virtual CRTC mode (MetaCrtcModeVirtual)
* A virtual CRTC (MetaCrtcVirtual)
* A virtual connector (MetaOutputVirtual)
In difference to the corresponding mode setting objects that represents
KMS objects, the virtual ones isn't directly tied to a MetaGpu, other
than the CoglFramebuffer being part of the GPU context of the primary
GPU, which is the case for all monitors no matter what GPU they are
connected to. Part of the reason for this is that a MetaGpu in practice
represents a mode setting device, and its CRTCs and outputs, are all
backed by real mode setting objects, while a virtual monitor is only
backed by a framebuffer that is tied to the primary GPU. Maybe this will
be reevaluated in the future, but since a virtual monitor is not tied to
any GPU currently, so is the case for the virtual mode setting objects.
The native rendering backend, including the cursor renderer, is adapted
to handle the situation where a CRTC does not have a GPU associated with
it; this in practice means that it e.g. will not try to upload HW cursor
buffers when the cursor is only on a virtual monitor. The same applies
to the native renderer, which is made to avoid creating
MetaOnscreenNative for views that are backed by virtual CRTCs, as well
as to avoid trying to mode set on such views.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
The order of which function argument expressions are executed is
undefined, so don't rely on this for setting the background colors, as
it results in different colors on different architectures.
For example, it has been observed that the order of execution is
reversed comparing x86_64 and aarch64, making these two architectures
having different background color.
Fix this confusion, and also reproduceability in future reference tests,
by making the order of execution predictable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
It's useful to be able to have very very tiny monitors (e.g. 60x60
pixels) when doing reference testing, as tests have reference images
that the output is compared to. Smaller reference images the less
storage they use.
To avoid annoying pointless warnings when this is done, change the
pedantic workspace work area code to be more forgiving if the work area
happens to match the display size.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
When rebuilding the monitors (e.g. during hotplug), make sure to detach
the disposed monitors from any outputs before creating the new monitors.
While this isn't currently needed, as outputs are too being recreated,
with the to be introduced virtual outputs that are created for virtual
monitors, this is not always the case anymore, as these virtual outputs
are not regenerated each time anything changes.
Prepare for this by making sure that cleaning up disposed monitors
detach themself properly from the outputs, so new ones can attach
themself to outputs without running into conflicts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This makes it possible to pass custom properties to backends when
constructing tests. This will be used to create "headless" native
backend instances for testing the headless native backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
With this commit, it's possible to run mutter without being DRM master.
It's not yet possible to add virtual monitors, but one can for example
already add virtual input devices.
This currently doesn't try to hook up to any logind session, thus will
not have a real seat assigned. Currently it's hard coded to "seat0".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Currently our only entry point for DRM devices is MetaKms*, but in order
to run without being DRM master, we cannot use /dev/dri/card*, nor can
we be either of the existing MetaKmsImplDevice implementation (legacy
KMS, and atomic KMS), as they both depend on being DRM master.
Thus to handle running without being DRM master (i.e. headless), add a
"dummy" MetaKmsImplDevice implementation, that doesn't do any mode
setting at all, and that switches to operate on the render node, instead
of the card node itself.
This means we still use the same GBM code paths as the regular native
backend paths, except we never make use of any CRTC backed onscreen
framebuffers.
Eventually, this "dummy" MetaKmsImplDevice will be replaced separating
"KMS" device objects from "render" device objects, but that will require
more significant changes. It will, however, be necessary for e.g. going
from being headless, only having access to a render node, to turning
into a real session, with a seat, being DRM master, and having access to
a card node.
This is currently not hooked up, but will be in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to
attempt to create a libinput context. This is intended to be used when
mutter is to run headless, as in without any input devices other than
virtual ones.
Currently not hooked up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
This leaves only the atomic mode setting cap check before creating the
impl device, aiming to make it possible to create a non-mode-setting
MetaKmsImplDevice implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Make it possible to pass --headless as a command line argument in order
to turn the native backend "headless". This currently doesn't do
anything, but the intention is that it should not use logind nor KMS,
and work completely headless with only virtual outputs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
Input settings requires a valid seat in order to initialize the a11y
settings (since commit 1609d145), however in X11 we never set it and
even if we create the input settings early (as per commit 7547891a) we
never initialize the seat for it.
This leads to startup critical errors on X11:
clutter_seat_get_pointer_a11y_settings: assertion
'CLUTTER_IS_SEAT (seat)' failed
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1763>
This commit adds the events created in the function
`meta_seat_x11_notify_devices` to the clutter events queue, which
are currently only added to the stage queue making the events not
being picked up by the `clutter_seat_handle_event_post` function.
This results in devices not getting added to the device-list of
`MetaInputSettings`.
Fixes the bug in which mouse and touchpad settings are not working in
the settings app during x11 session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1767>
Since commit 2ceac4a device-related X11 events aren't processed anymore,
causing the input settings not to handle the devices.
This is due to the fact that we may never call clutter_seat_handle_event_post()
for such events.
While this is always happening for the native backend, it doesn't happen in
X11 because the events are removed from the queue as part of
meta_x11_handle_event(), and thus no event was queued to the stage by the
backend events source.
This also makes sure that the event post handler is called after the
event is actually processed, and not before an event is queued.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1564
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
The nested backend may need to have an input setting implementation,
while we don't want to change the host settings (re-using an X11 input
settings) we can add a dummy implementation, until something more
complex is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1769>
The sync ring has an API about "frames", where it is notified about
the end of frames. However, its "insert wait" call is done before
updates, meaning that some "insert waits" will never see the "after
frame" if there was no frame drawn. This will cause mismatching in the
frame counting, causing freezes in the synchronization until something
else triggers an actual frame, effectively "unfreezing" the sync ring.
Fix this by not only notifying the sync ring about frames when there
were actual frames drawn, but also on plain updates which didn't result
in a drawn frame.
Related: https://gitlab.gnome.org/GNOME/mutter/-/issues/1516
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1754>
When a gtk theme uses larger shadows for the unfocused state than for
the focused one, this can cause a crash in meta_frame_left_click_event.
Since whether to call meta_frame_left_click_event is decided based on
the decoration size before focusing and the control that was clicked on
after focusing, this can result in an event handled in
meta_frame_left_click_event being on the client area.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1668
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1748>
With commit 7d78768809 we switched to
storing pointer coordinates in MetaInputDeviceNative instead of
ClutterInputDevice, and while we had set the coordinates of the
ClutterInputDevice in ClutterStage when queueing an event, we now set
the MetaInputDeviceNative coordinates in new_absolute_motion_event().
Here a small mistake snuck in: new_absolute_motion_event() only
translates the coordinates of the event, but we call
meta_input_device_native_set_coords() using the x and y variables
(which remain untranslated), so now the input device coordinates are no
longer translated.
Fix that by translating the coordinates of the x and y variables in case
we're we handling a tablet/stylus event instead of only translating the
event coordinates.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1685
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1760>
This fixes the interpolate test to not use the wall clock, but the
monotonic clock. It also cleans up the timestamp granularity naming, so
that the different granularity is clearer, as in the test, different
timestamps have different granularity.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
This more or less rewrites this test so that it explicitly tests the
"interpolation" when a timeline loops, i.e. that if something occupies
the thread when a timeline was supposed to have looped, we end up in the
right place "in the middle" of the next timeline cycle.
The test more or less does this:
* Start a 3 second looping timeline
* Sleep so that we're in the middle of the first cycle
* Sleep again so that we end up in the middle of the next cycle
The semantics checked are that we see the following frames:
* The first frame with timestamp 0
* The second frame in the middle of the first cycle (timestamp ~= 1.5
sceonds)
* The third frame in the end of the first cycle (timestamp == 3.0
seconds)
* The fourth frame, first in the second cycle, with timestamp ~= 1.5
seconds)
This means we can increase the "grace period" to the double (from 0.5 s
to 1 s), while at the same time decrease the time spent running the test
(from 10 s to 4.5 s). This should hopefully make the test less flaky,
especially in slower runners, e.g. aarch64.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1751>
With commit c985753442 the support for
multiple hardware cursors broke, but those were never properly supported
anyway as we usually assume there's only one hardware cursor around.
With the introduction of the KMS thread in the future, we'll only have
one KMS cursor that gets updated directly from the input thread. So
apart from the fact that it never really makes sense to have two cursors
visible, in this new model having multiple cursors won't work anyway.
So make the cursor we show for stylii a software cursor again.
Eventually the plan is to make the input device that's driving the KMS
cursor interchangeable, so that we can always use hardware cursors.
This reverts commit 165b7369c8.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1645
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1758>
To make the double buffered shadow buffer damaged tiles detection
feasable, a new EGL extension is needed for creating FBO's backed by
a custom CPU memory buffer, instead of DMA buffers, as DMA buffers can
be very slow to read, much slower than just painting the shadow buffer
directly.
Leave the code there, since such an EGL extension is intended to be
added, but hide it behind an env var so that it isn't enabled by
accident.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1724>
This commit assumes that cursor surfaces work in a "mailbox" fashion. If
they are painted multiple times before a successful flip, all commits
but the last get discarded, and the last commit gets presented after the
flip succeeds. This is more or less how it works in the atomic backend,
and also more or less how it works in other backends, with the exception
that the cursor painting might fail without any way of knowing. This
assumption is still better than unconditionally discarding all cursor
surface feedbacks as if the cursor painting always fails.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
Regarding the sequence = 0 fallback: in some cases (moving a cursor
plane on atomic amdgpu) we get sequence = 0 in the page flip callback.
This seems like an amdgpu bug, so work around it by assuming a sequence
delta of 1 (it is equal to 1 because of the sequence != 0 check above).
Sequence can also legitimately be 0 if we're lucky during the 32-bit
overflow, in which case assuming a delta of 1 will give more or less
reasonable values on this and next presentation, after which it'll be
back to normal.
Sequence is also 0 on mode set fallback and when running nested, in
which case assuming a delta of 1 every frame is the best we can do.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
The presentation-time protocol allows surfaces to get accurate
timestamps of when their contents were shown on screen.
This commit implements a stub version of the protocol which correctly
discards all presentation feedback objects (as if the surface contents
are never shown on screen). Subsequent commits will implement sending
the presented events to surfaces shown on screen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
This concerns only the cases when the presentation timestamp is received
directly from the device (from KMS or from GLX). In the majority of
cases this timestamp is already MONOTONIC. When it isn't, after this
commit, the current value of the MONOTONIC clock is sampled instead.
The alternative is to store the clock id alongside the timestamp, with
possible values of MONOTONIC, REALTIME (from KMS) and GETTIMEOFDAY (from
GLX; this might be the same as REALTIME, I'm not sure), and then
"convert" the timestamp to MONOTONIC when needed. An example of such a
conversion was done in compositor.c (removed in this commit). It would
also be needed for the presentation-time Wayland protocol. However, it
seems that the vast majority of up-to-date systems are using MONOTONIC
anyway, making this effort not justified.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
KMS and GLX device timestamps have microsecond precision, and whenever
we sample the time ourselves it's not the real presentation time anyway,
so nanosecond precision for that case is unnecessary.
The presentation timestamp in ClutterFrameInfo is in microseconds, too,
so this commit makes them have the same precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
A flag indicating whether the presentation timestamp was provided by
the display hardware (rather than sampled in user space).
It will be used for the presentation-time Wayland protocol.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
A flag indicating whether the presentation timestamp was provided by the
display hardware (rather than sampled in user space).
It will be used for the presentation-time Wayland protocol.
This is definitely the case for page_flip_handler(), and I'm assuming
this is also the case for the two instances in the GLX code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484>
ClutterText has a bit of a mess around its signalling of changes to the
cursor position: There's the position (deprecated) and cursor-position
property, and there's the cursor-changed and cursor-event (deprecated)
signal. The two properties are supposed to be notified when the cursor
position changes, and the two signals are notified when the cursor
position or size changes.
Now the properties notifications and the signals get fired in two very
different places: The two properties are notified in
clutter_text_set_cursor_position(), while the signals are fired during
the paint cycle when we figured out the final cursor position. The
latter is a pretty bad idea, nobody expects such a signal to be fired
during painting, and also changes to the text that are done in the
signal handler will only be applied on the next paint.
Now StEntry listens to cursor position changes via cursor-changed and
invalidates its text shadow, but since the signal is only notified
during the paint, the old text shadow will still get applied. To fix
this, also emit the cursor-changed signal when we notify the
cursor-position property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1757>
The old calculation was introduced to improve the precision
with commit c16a5ec1cf.
Here, I call the calculation as "revision 2", and the
calculation even older as "revision 1", and the new
calculation introduced with this commit as "reivion 3".
Revision 2 has two problems:
1. The calculation is mixed with fixed-point numbers and
floating-point numbers.
To overcome the precision loss of fixed-point numbers division,
it first "calculates refresh rate in milliHz first for extra
precision", but this requires converting the value back to Hz.
An extra calculation has performance and precision costs.
It is also hard to understand for programmers.
2. The calculation has a bias.
In the process, it does:
refresh += (drm_mode->vtotal / 2);
It prevents the value from being rounded to a smaller value in
a fixed-point integer arithmetics, but it only adds a small
bias (0.0005) and consumes some fraction bits for
floating point arithmetic.
Revision 3, introduced with this commit always uses
double-precision floating-point values for true precision and
to ease understanding of this code. It also removes the bias.
Another change is that it now has two internal values, numerator
and denominator. Revision 1 also calculated those two values
first, and later performed a division with them, which minimizes
the precision loss caused by divisions. This method has risks of
overflowing the two values and revision 1 caused problems due to
that, but revision 3 won't thanks to double-precision. Therefore,
revision 3 will theoretically have the result identical with
the calculation with infinite-precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1737>
Handle the case of a TOUCH_BEGIN event during window dragging separately
instead of treating it like a TOUCH_UPDATE event: Simply return TRUE to
make Clutter stop event propagation if it's the pointer emulating
sequence and let Clutter propagate the event if it isn't.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/427>
Window dragging should be cancelled when the touch sequences we're using
are no longer available. Also listen to TOUCH_CANCEL events if the
window is grabbed and cancel the grab op when a TOUCH_CANCEL event
happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/427>
This removes the responsibility of tracking these from the backend to
the base object. The backends are instead responsible for calling the
function to update the values.
For the native backend, it's important that this happens on the correct
thread, so each time either of these states may change, post a idle
callback on the main thread that sets the, at the time of queuing said
callback, up to date state. This means that things on the main thread
will always be able to get a "new enough but not too new" state when
listening on the 'notify::' signals and getting the property value
after.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1739>
In an x11 session, we don't receive motion events from X when the
pointer is above a window. Since commit 734a1859 we only do picking on
motion events though, which means when clicking the mouse to focus a
window, we don't repick and might still think the pointer is hovering
above another window or actor, ending up not focussing the window.
Fix this by always repicking on BUTTON_PRESS events. While this is not
necessary in the wayland session, button presses happen rarely compared
to motion events, so it's not a performance regression to do it in
Wayland sessions, too.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1660
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1752>
ClutterText allows setting a custom PangoAttrList, and St uses that to
set the text style it's reading from CSS. One style St enforces using
this mechanism is the text color and setting the text color should
obviously not affect the size of the layout. ClutterText does queue a
relayout in that case though because it unconditionally queues a
relayout when updating the PangoAttrList.
We can avoid this relayout by reusing an optimization ClutterText has:
clutter_text_queue_redraw_or_relayout() will only queue a relayout if
the requested size of the layout changed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1750>
Make sure to reset all the state that was set for an interactive grab op
back to the defaults after a grab op has ended.
Especially important here is setting grab_frame_action back to FALSE,
since this will constrain window-titlebars to the panel. We set this to
TRUE on some grabs, for example when resizing, but not when moving
windows. Since this remained being set to TRUE, it would also constrain
non-grab window movements, like calling MetaWindow.move_frame(), which
is used by gnome-shells OSK. By resetting it back to FALSE after a grab,
the OSK can now always move non-maximized windows to the position it
wants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1736>
The cache had the size 9, which was "big enough" in the past, but when
more ways pipelines could be constructed, the size was not enough. The
need to increase the cache size was hard to spot though, since adding
pipeline flag didn't give any hints about the cache being directly tied
to these flag values.
So, when enough flag bits were set when attempting to retrieve and put a
pipeline in the cache, it'd instead overwrite some arbitrary stack
memory, which would sooner or later result in a memory corruption
induced crash. Valgrind could not detect this particular memory
corruption, as it messed up stack memory, not e.g. freed heap memory, so
it instead got confused and thought plain stack values were unreadable.
Fix these two issues by making the cache size the combination of all
pipeline flags + 1, so that we can safely put any flag combination in
the cache.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1747>
Each next and current scanout buffer has a reference on them making sure
they stay alive. When dumb buffers were used on the secondary GPU state,
this didn't happen, leading to crashes due to unref:ing one time too
many, with backtraces such as
0) g_type_check_instance_is_fundamentally_a ()
1) g_object_unref ()
2) secondary_gpu_release_dumb ()
3) import_shared_framebuffer ()
4) update_secondary_gpu_state_post_swap_buffers ()
5) meta_onscreen_native_swap_buffers_with_damage ()
6) cogl_onscreen_swap_buffers_with_damage ()
7) swap_framebuffer ()
8) clutter_stage_cogl_redraw_view_primary ()
9) clutter_stage_cogl_redraw_view ()
10) _clutter_stage_window_redraw_view ()
11) handle_frame_clock_frame ()
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1746>
gnome-shell has this hack where it sets the environment variable
"NO_AT_BRIDGE" to "1" before calling meta_init() and then unsets it
after meta_init() returns.
This variable being set to "1" will then cause the ATK bridge in
at-spi2-gtk to fail to load, which GTK then ignores. This is on purpose,
since accessibility is supposed to be done done by GNOME Shell via
Clutter, not via GTK.
The problem is that, now, by default, setting "NO_AT_BRIDGE" to
"1" during meta_init() only has the desired effect on an X11 session,
where we always connect to the X11 server on startup (i.e. during
meta_init()). With Xwayland on-demand, we do not attempt to create the
GDK display during meta_init(), thus this hack falls apart.
Since there are no real altenatives to this hack, just move it to
mutter, which have a better idea when GDK displays are created or not.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1744>
Commit afa43154 tried to make sure the focus was properly changed when
calling focus_default_window() by checking the focused window just after
trying to set the focus.
However, the X11 “Inter-Client Communication Conventions Manual” version
2.0 (ICCCM 2 for short) states that some X11 client may want to use a so
called “globally active input” model in which case the client expects
keyboard input and set input focus even when it's not one of its own
window.
To comply with this, when dealing with such clients, mutter will not
change the focus and send a WM_TAKE_FOCUS message instead.
That mechanism will defeat the logic introduced by commit afa43154
because the focused window is not changed in this case. As a result, the
input focus will fallback to the no-focus window.
To avoid this, only check that the focus change occurred for windows
using a synchronous focus model.
v2: Split specific test for "globally active input" model (Florian).
v3: Remove the check for window->unmanaging which is useless (Jonas).
Fixes: afa43154 - "core: Make sure focus_default_window() worked"
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/1620
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
X11 clients can use different models of input handling, of which some
may not result focus being set synchronously.
For such clients, meta_focus_window() will not change the focus itself
but rely on the client itself to set the input focus on the desired
window.
Add a new MetaWindow API to check when dealing with such a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1716>
Without these devices, things that depend on the existance of input
device classes won't know about the existance of e.g. pointer devices,
if the only pointer device is from a virtual one.
This requires handling situations where e.g. a device doesn't have a
device node thus can't be matched against a udev device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
Libinput will queue a few initial events when a seat is assigned to the
udev backend; a result of it probing udev adding detected devices. For
us to see these events, we need to dispatch libinput before going idle,
as nothing will show up on the libinput file descriptor until something
else (e.g. keyboard event or mouse movement) wakes us up.
Do this by adding a prepare() function to the libinput GSource, that
checks whether there are any events in the queue already, and return
TRUE if so is the case, causing us to dispatch before going fully idle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
The API for NotifyKeyboardKeycode() does not mention what type of
keycode is expected to be submitted.
So, clarify in the API that the keycode to submit is expected to be an
evdev keycode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
Currently, when a remote desktop user submits a keycode, it will be
interpreted differently, when using the x11 session, instead of a
wayland session.
In a wayland session, submitting a keycode will have the expected
result (as if the key was pressed locally).
In a x11 session, this is not the case. Instead of getting the expected
key, some other key will be pressed (or sometimes even none).
The reason for this is that the native backend interprets the keycode
as evdev keycode and the x11 backend interprets the keycode as xkb
keycode.
To ensure that both backends produce the same behaviour when submitting
a keycode, fix the x11 backend to always interpret the keycode as evdev
keycode, instead of a xkb keycode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1732>
GObject signals pass the emitting GObject as the first argument to
signal handler callbacks. When refactoring the grab-op-begin/end signals
to remove MetaScreen with commit 1d5e37050d,
the "screen" argument was replaced with a "display" argument instead of
being removed completely. This made us call the signal handlers with two
identical MetaDisplay arguments, which is very confusing and actually
wasn't handled in a grab-op-begin handler in gnome-shell.
So fix this by not adding the MetaDisplay as an argument to those
signals, GObject will take care of that for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1734>
We're going to round the workspace backgrounds in the new overview for
gnome-shell 40.
So far corner-rounding was only possible for StWidgets because the
rounded clipping was done using cairo drawing. We now need rounded
clipping for ClutterActors too because backgrounds are drawn using
ClutterActors (or more specifically a ClutterContent). To implement
that, first a ClutterOffscreenEffect subclass together with a fragment
shader from GSK (see gskSetOutputColor() [1] in the GSK GL renderer
code) was investigated, and while that was generic and worked quite
well, it was extremely slow for the case of drawing wallpapers because
of all the FBOs that had to be allocated.
This is the new, more performant approach: Use the same fragment shader,
but perform the rounded clipping right in MetaBackgroundContent while
we're painting the wallpaper. This has almost no performance impact,
with the downside of not being a generic solution.
To allow for rounded clipping not only at the edges of the wallpaper,
but using any given bounding rectangle, the API exposes not only the
radius, but also a bounding rect.
[1] https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/resources/glsl/preamble.fs.glsl
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1717>
d42f1873fc introduced a semi circular
reference between the CoglFramebuffer, and CoglJournal, where
CoglJournal would keep a reference on the CoglFramebuffer when there
were any entries in the journal log.
To avoid risking leaking these objects indefinitely, when freeing
objects without doing anything that triggered a flush, CoglFramebuffer
had a "filter" on cogl_object_unref() calls, which knew
about under what conditions CoglJournal had a reference to it. When it
could detect that there were only the journal itself holding such a
reference, it'd flush the journal, effectively releasing the reference
the journal held, thus freeing itself, as well as the journal.
When CoglFramebuffer was ported to be implemented using GObject instead
of CoglObject, this "filter" was missed, causing not only awkward but
infrequent leaks, but also situations where we'd flush journals when
only the journal itself held the last reference to the framebuffer,
meaning the journal would free the framebuffer, thus itself, in the
middle of flushing, causing memory corruption and crashes.
A way to detect this, by asserting on CoglObject reference count during
flush, is by adding the `g_assert()` as described below, which will
assert instead cause memory corruption.
void
_cogl_journal_flush (CoglJournal *journal
{
...
_cogl_journal_discard (journal);
+ g_assert (journal->_parent.ref_count > 0);
...
}
Fix this by making CoglFramebuffer the owner of the journal, which it
already was, and remove any circle referencing that was there before, as
it is not needed given that the CoglFramebuffer pointer is guaranteed to
be valid for the lifetime of CoglJournal as the framebuffer is the owner
of the journal.
However, to not miss flushing before tearing down, which is important as
this flushes painting calls to the driver that is important for e.g.
using the result of those journal entries, flush the journal the first
time cogl_framebuffer_dispose() is called, before doing anything else.
This also adds a test case. Without having broken the circular
reference, the test would fail on g_assert_null (offscreen), as it would
have been "leaked" at this point, but the actual memory corruption would
be a result of the `cogl_texture_get_data()` call, which flushes the
framebuffer, and causes the 'mid-flush' destruction of the journal
described above. Note that the texture keeps track of dependent
framebuffers, but it does not hold any references to them.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1474
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1735>
Currently, the documentation for NotifyPointerAxis() just mentions that
a smooth scroll event is emitted.
However, this is not entirely correct. For each NotifyPointerAxis(),
mutter emits an emulated discrete scrolling event based on the
submitted accumulated smooth scrolling deltas.
Additionally, it doesn't mention how the motion deltas need to be
interpreted.
So, document the NotifyPointerAxis() notification better by mentioning
the emulation of discrete scroll events, how these discrete scroll
events are calculated and how the motion deltas need to be interpreted.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
When a remote desktop user emits a virtual smooth scrolling event, a
smooth scroll event, that is not emulated, is emitted and on occasion
a discrete scroll event, that is emulated, is emitted.
As base for the discrete scrolling event, the smooth scrolling steps
are accumulated.
When the accumulated smooth scrolling steps surpass the
DISCRETE_SCROLL_STEP, the discrete scrolling event is emitted.
Currently, mutter uses for DISCRETE_SCROLL_STEP the value 10, which is
a terrible value to work with, especially for high resolution mouse
wheels.
When a triple resolution mouse wheel is used, each scrolling step will
have the value 3 1/3.
Three of such events won't however surpass the DISCRETE_SCROLL_STEP.
To fix this situation, add DBL_EPSILON to the calculation step, when
checking for the discrete scroll event to ensure that 3 smooth scroll
events, with each having the value 3 1/3, emit a discrete scrolling
event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
MetaVirtualInputDeviceX11 currently doesn't handle smooth scroll events
at all.
So, if a user of the remote desktop API uses smooth scroll events, then
only the wayland backend handles these events.
The user of the remote desktop API however, might not know which
backend is being used and actually the user should not even have to
care about it.
Actual smooth events cannot be emulated in the X11 events.
What can be done however is accumulating smooth events and then when
the accumulated steps surpass the DISCRETE_SCROLL_STEP value, emit a
discrete scroll event.
So, do exactly that, to make smooth scroll events work when the remote
desktop API is used with the x11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
With 734a185915 an optimization was
introduced to only pick on events which can actually cause the pointer
to move. In case of touch events, the first event (TOUCH_BEGIN) will
already move the touchpoint though, and we'll send our crossing
CLUTTER_ENTER event to the actor this TOUCH_BEGIN happened on.
So fix this embarrassing bug that caused touch input to break by also
picking to find an event-actor on TOUCH_BEGIN events.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1733>
Aside from ENTER/LEAVE, there are only two kinds of events that can move
the pointer, motion events and touch update events. Everything else
keeps the pointer at it's current position.
The reason we pick inside _clutter_process_event_details() is that we
want to set the event actor. Now if an event can't move the pointer, it
also can't change the event actor (well, it can subsequently by
triggering changes to the scenegraph, but that's handled elsewhere), so
there's no need to pick a new event actor when we get those events.
Instead, simply reuse the actor that's already associated with the
current input device as the event actor for non MOTION/TOUCH_UPDATE
events.
Events where a device or a touchpoint goes away (like DEVICE_REMOVED or
TOUCH_END/CANCEL) also affect picking, they don't need a repick, but
instead the actor associated with the device/touchpoint needs to be
unassociated. This is ensured by invoking remove_device_for_event() on
those events and will not be affected by this change.
This should improve performance while scrolling quite a bit, since
scroll events come in unthrottled and we now no longer do a repick on
each one of those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1729>
Given X11 nature, the pointer "leaves" the stage anytime it wanders into
a client window, or any other areas that are not deemed part of the
stage input region.
Yet we want to stay correct in those situations, e.g. have the clutter
side reasonably in sync, picking and highlighting to work properly, etc.
In order to achieve that, emulate motion events on XI_RawMotion. These
are as much throttled as our pointer tracking for a11y, in order to avoid
too many XIQueryPointer sync calls. This emulation only kicks in anytime
that X11 notifies us that we are not "on" the stage.
This replaces some sync_pointer() calls in GNOME Shell code that are
there just to compensate for this trait of X11, e.g. in the message tray
code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Ensure we issue a motion event for the current pointer position,
as there might be situations where compositor modals get X grabs
from other clients stacked on top, or missed events in between
otherwise.
Ensure the Clutter state is still up-to-date afterwards here. This
replaces some sync_pointer() calls done in GNOME Shell code, always
done after modality changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
Do these Wayland operations (that apply on both native and nested backends)
in the MetaCompositorServer subclass. We want to add more backend specific
behavior here in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
In the case that DnD is performed and succeeds, we want to release
the grab early, and let the transfer IPC happen in the back. For
that to happen without a hitch, drag source and offer must be left
related to each other after undoing the grab, even though the default
ungrabbing code does that automatically (indirectly, by unsetting the
drag focus).
In these cases, we used to manually unset the current source, so
this decoupling was skipped. Notably, one missed case is X11 DnD,
so we might end up with the situation there that DnD did succeed,
transfer is ongoing, but the source and offer are already decoupled,
this confused the machinery and missed the finishing XdndFinished
to be emitted to the X11 drag source.
The prior commits prepared for this source/offer decoupling being
a manual operation, this commit avoids doing this automatically
when ungrabbing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
This object is just being detached, with no code unref'ing it. Do
this whenever the XDnD selection goes unowned, usually a good
indication that the drag source no longer is one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1720>
g_set_error_literal() asserts that the provided message is not NULL.
If it is NULL, the function is entirely no-op.
This resulted in a NULL dereference of the GError, which remained
NULL in this case, when trying to print a warning in
clutter_stage_cogl_redraw_view().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1715>
We might have a stage view listener attached to the stage itself if the
actor didn't have a suitable frame clock when the actor was associated
with the timeline. We'd then listen to stage-views-changed signals on
the stage itself to be able to attach to a frame clock when one
appeared.
What went wrong is that if an actor that didn't have a frameclock was
associated with a timeline, but then destroyed, the timeline would
disassociate itself from the actor, but it'd still listen on the
stage-views-changed signal on the stage. This would be in itself
harmless, until the timeline itself is destroyed, as at this point, it
wouldn't clean up the stage-views-changed listener on the stage, as it's
assumed to only be valid when there is an actor attached.
Fix this issue by cleaning up the stage's stage-views-changed listener
when the actor is destroyed, as we wouldn't be able to make use of it by
then anyway.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3323
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1719>
PipeWire recently introduced busy buffers, which actually fixes the last remaining
issue that blocked us from downgrading these cogl_framebuffer_finish() calls into
cogl_framebuffer_flush() ones.
Switch to cogl_framebuffer_flush() in all three stream sources.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1701>
The 0.3.21 release includes busy buffers, which are a requirement
for us to switch to cogl_framebuffer_flush() in the next commit.
Bump pipewire dependency to 0.3.21, and adjust CI to build it from
the corresponding tag.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1701>
Before this commit, next presentation time could end up behind now_us or
ahead of now_us depending on how presentation times happened to be
aligned relative to integer multiples of refresh_interval_us. It's not
clear whether this was originally intended because even if it the next
presentation time ends up behind now_us, it is moved ahead by a while
loop down below in this function.
Even though this difference in behavior didn't really matter, it made
reasoning about the subsequent branches more complex. It would also
potentially introduce bugs if the logic was to be modified. So this
commit makes it so next presentation time is always ahead of now_us.
It also adds a comment with a graph detailing the computations, and
adjusts the variable names to drop unfortunate terminology mistakes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1707>
Last presentation time is mainly used to make sure predicted
presentation time is aligned with display refreshes. Even if it went
back in time, there will be no issue as next presentation time takes
current time into account. Synthetic presentation time is not exactly
aligned with display refreshes, so using it would only result in
inconsistent animations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1707>
When a transfer request is done to the MetaSelectionSourceRemote source,
it's translated to a SelectionTransfer signal, which the remote desktop
server is supposed to respond to with SelectionWrite.
A timeout (set to 15 seconds) is added to handle too long timeouts,
which cancels the transfer request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
Nothing is hooked up, it only does basic sanity checking i.e. whether
the clipboard was enabled when interacting with it. No actual clipboard
integration is hooked up yet.
This also syncs org.gnome.Mutter.RemoteDesktop.xml from
gnome-remote-desktop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1552>
The original implementation of ::touch-mode tested for keyboard
presence to know whether the OSK and other touch-only features were
enabled.
However that didn't pan out, every webcam, card reader and kitchen
sink like to live a second life as EV_KEY devices. This made the
detection of actual external keyboards a much harder task than it
sounds, and was thus removed in commit f8e2234ce5.
Try a different approach here, and test for pointer devices, it
doesn't matter if internal or external devices, the rationales:
- It is significantly easier to get this right, there's virtually
no devices with abs/rel axes that don't try to be a real input
device of some sorts.
- It's not as good as testing for keyboard presence, but it's the
next best thing. These usually come in pairs, except in weird
setups.
- It is better than not having anything for a number of situations:
- Non-convertible laptops with a touchscreen will get touch-mode
disabled due to touchpad presence (plus keyboard). There's
been complains about OSK triggering with those.
- Same for desktop machines with USB touchscreens, the mouse
(and presumably keyboard) attached would make touch-mode
get in the middle.
- Convertible laptops with a broken tablet-mode switch get a
chance to work on tablet modes that do disable input devices
(e.g. detachable keyboards, or via firmware)
- Kiosk machines, tablets, and other devices that have a
touchscreen but will not regularly have a mouse/keyboard
will get the touch-mode enabled.
All in all, this seems to cover more situations the way we expect it,
there's only one situation that the OSK would show where it might
not be desirable, and one that might not show when it better should:
- Tablets and kiosk machines that get one keyboard plugged, but not a
mouse, will still show the OSK, despite being able to type right
away.
- Convertible laptops with broken/unreliable tablet-mode switch (e.g.
ignored by the kernel) rely entirely on the device/firmware
characteristics to work. If after folding into tablet mode the
touchpad remains active, touch-mode will not turn on.
Fixing the tablet-mode switch on these devices should be preferred,
as that'll also make libinput magically disable the touchpad.
The latter can be worked around with the a11y toggle. The former is
merely inconvenient, and nothing prevents the user from plugging a mouse
in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1710>
Technically this is still wrong if the source actor or dnd actor are
transformed in other ways. However geometry scale is the by far most
common case and we currently lack convenience API in Clutter to
easily compute the right values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1683>
When recording the screen and real time encoding it using a gstreamer
pipeline, that pipeline can stall when the encoder is too slow. Log a
debug message using the new SCREEN_CAST debug topic in that case so we
know when framedrops are happening.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1709>
Since commit c255031b6d, we allow some modifier+scroll events to
pass through to Clutter to enable gnome-shell to handle them. That
action shouldn't trigger a modifier-only action at the same time, so
reset the corresponding tracking just like we do for modifier+click.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1695>
Since commit c255031b6d we pass scroll-events through to
the compositor if the window_grab_modifiers are pressed;
in order to allow gnome-shell to check for those events,
expose the struct member as a MetaDisplay property.
Also take the opportunity to pick a more generic name, now
that the modifier is no longer used exclusively for mouse
clicks (unless we maintain the notion of scroll events as
button 4 and 5 "clicks").
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1695>
The other end of the PipeWire stream can set the buffer data type to a
bitmask of supported buffer types. We should respect this, and not
attempt to allocate a DMA buffer if it isn't asked for.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1697>
Instead of getters, pass the width, height and stride around when
relevant. This also removes the redudant "stream_size" and
"stream_height" variables from the src struct, as they are already part
of the video format.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1697>
Previously we were setting the FBO's viewport to be the same dimensions as
the stage itself for compatibility. This works for most cases, but not if
the actor is larger than the stage. In that case it could cause excessive
clipping if the actor's transformed screen position was negative, which
is seen in https://gitlab.gnome.org/GNOME/gnome-shell/issues/2087
Also if a small actor paints to its negative dimensions (like a box-shadow)
then we might be missing those pixels on the left or top, even though
they're inside the paint volume.
Now we set the viewport dimensions to match the area we're actually
rendering so the FBO contents are never over or under clipped.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3068
Although if you try using shadows larger than that (like in
gnome-shell#1090) then you will also need gnome-shell!1417.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1053>
We had been doing it backwards as far back as e3966882e8 which meant
that we were translating by `fbo_offset / resource_scale` stage units
instead of just `fbo_offset`.
Because `fbo_offset` is in stage units already, it's not scaled and so
needs to be applied after the unscaling from texels to stage units.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1053>
Mutter freezes Xwayland commits when resizing windows, and thaw them in
the window actors' after_paint() for X11.
Yet, after_paint() could be never called, as when a new window is mapped
while the overview is active in gnome-shell.
As a result, the content of the X11 window will remain invisible to the
overview.
Add a new window actor API to tell whether commits can be frozen. For
Wayland window actors, this always return FALSE, whereas for X11 window
actors, it checks whether the Clutter actor is mapped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1678>
When (un)maximizing, (un)fullscreening, the move/resize action is
flagged with 'ACTION_MOVE' and 'ACTION_RESIZE' , while e.g.
'appears-focus' does not.
When a client misbehaved and didn't immediately reply to a configure
request with a commit with the corresponding ack_configure, the
following commit would trigger a oddly timed move, making the window
appear to move back to a previous position.
Avoid this issue by only carrying over the target window position if the
configuration actually contained a new position.
We cannot only rely on the flags however, as e.g. a new position should
be respected during interactive resize, even though only 'ACTION_RESIZE'
is passed in such scenarios.
Do the same for the size, except if the window state dictates that the
size is fixed to a certain size, e.g. being fullscreen or maximized.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1445>
It's currently only handled by a surface backend framebuffer (assuming
the right GLX extensions are available). While it's theoretically
possible to do the same with the offcreen by having multiple textures,
it's not supported, so leave the FBO variant with a single warning if we
end up there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The object was still pretending to be CoglFramebuffer itself, by using
naming and calling conventions making it seem like that. Fix that by
passing around the driver instead of the framebuffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Mutter needs to fetch the X11 Window ID from the onscreen and did that
by using an X11 specific API on the CoglOnscreen, where the X11 type was
"expanded" (Window -> uint32_t). Change this by introducing an interface
called CoglX11Onscreen, implemented by both the Xlib and GLX onscreen
implementations, that keeps the right type (Window), while avoiding X11
specific API for CoglOnscreen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Mutter didn't use the APIs for resizeability of CoglOnscreens but
managed the size itself. For the native backend we don't ever resize
onscreens. Thus, remove this unused functionality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The framebuffer driver was lazilly initialized on demand in some cases
(onscreen), and up front other (offscreen). Replace this with a more
predictable up front initialization, done at framebuffer allocation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The CoglGLFramebuffer (not CoglGlFramebuffer) is a private struct for
keeping track of the framebuffer object. To avoid confusing with
CoglGlFramebuffer, rename it CoglGlFbo.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
This way we can have separate types per modes of operation (e.g. if it's
backed by an EGLSurface or single texture), instead of being dependent
on a certain type (onscreen vs offscreen).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Instead of calling "init_onscreen()" on two different separate vtables
from the allocate() funtion, just have the CoglOnscreen sub types
themself implement allocate() and initialize in there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Thins means that e.g. MetaOnscreenNative now inherits CoglOnscreenEgl,
which inherits CoglOnscreen which inherits CoglFramebuffer, all being
the same GObject instance.
This makes it necessary to the one creating the onscreen to know what it
wants to create. For the X11 backend, the type of renderer (Xlib EGL or
GLX) determines the type, and for the native backend, it's currently
always MetaOnscreenNative.
The "winsys" vfunc entries related to onscreens hasn't been moved yet,
that will come later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
To get meta-renderer-native.c down to a bit more managable size, and to
isolate "onscreen" functionality from other (at least partly), move out
the things related to CoglOnscreen to meta-onscreen-native.[ch].
A couple of structs are moved to a new shared header file, as
abstracting those types (e.g. (primary, secondary) render devices) will
be dealt with later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The mutter naming convention for types and their instance variables is:
Type name:
[Namespace][BaseName][SubType]
Instance name:
[base_name]_[sub_type]
This means that e.g. CoglOnscreenGLX is renamed CoglOnscreenGlx, and
glx_onscreen is renamed onscreen_glx. This is in preparation for
GObjectification.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
The GLX winsys code had split up the GLX onscreen implementation into an
Xlib part (with a struct name confusingly enough identical to that of
the onscreen in the actual Xlib winsys). To remove some confusion,
combine the two.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1514>
Makes sure that monitor specs which may be read from EDID data do not
contain characters that are invalid in XML. Makes it possible to restore
monitor configs of monitor models with characters such as '&' in them.
To make this change not break any tests, the sample monitor configs need
to be adjusted as well. Apostrophes don't strictly have to be escaped in
XML text elements. However, we now do escape the elements in
`<monitorspec>` specifically.
Closes: <https://gitlab.gnome.org/GNOME/mutter/-/issues/1011>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1685>
Previously the wl_resource and MetaWaylandGtkSurface corresponding to
any client gtk_surface have been kept around until the exit of the
client due to the client side destroy method not signaling the
destruction to the server. Ideally the protocol would have specified a
destroy request marked as destructor to handle this automatically,
however this is no longer possible due to the destroy method being
implicitly generated in the absence of an explicit request in the
protocol. Adding a destroy request marked as destructor now would
generate a new destroy method that unconditionally would send the
request to the server, which would break clients running on servers not
supporting that request.
So instead of modifying the destroy request add a new "release"
destructor, that indicates to the server that it can release the
resource. This can be optionally be used by clients depending on the
server protocol version.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1307>
The MetaWaylandSurface corresponding to a MetaWaylandGtkSurface can be
destroyed before the MetaWaylandGtkSurface is destroyed. In its destroy
function MetaWaylandSurface however was unsetting the destructor of the
correspnding resource along with the gtk_surface1 interface
implementation. This was done to prevent further gtk_surface1 requests
on a NULLed MetaWaylandSurface, if it has been destroyed before the
MetaWaylandGtkSurface.
It would be enough to just unset the resource implementation, while
keeping the destructor to fix this leak. However the following commit
will rely on the implementation being available after the
MetaWaylandSurface has been destroyed. So instead introduce NULL checks
for all functions that can be called on the gtk_surface1 interface and
do not unset the implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1307>
If the monitor configuration changed, even though the streamed monitor
didn't change, we'd still fail to continue streaming, as we failed to
update the stage watchers, meaning we wouldn't be notified about when
the stage views were painted.
Fix this by reattaching the stage watches, i.e. update the painted
signalling listeners to listen to the right views, when monitor changes
happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1691>
We've inherited, and still keep in place, code that reads ini files
at ~/.config/clutter-1.0/settings.ini and /etc/clutter-1.0/settings.ini
to tweak different aspects of Clutter.
Some of these should use GSettings instead, some others are exposed
nowadays differently for our purposes (e.g. envvars, looking glass, ...).
Overall seems like an unexpected entry point nowadays, so remove the
parsing of these .ini files altogether.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1693>
Make the API used more shared and better named.
meta_monitor_manager_on_hotplug() was renamed
meta_monitor_manager_reconfigure(), and meta_monitor_manager_reload()
was introduced to combine reading the current state and reconfiguring.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
It was named "backend_native" and "backend" which is easily confused with
MetaBackendNative and MetaBackend which tends to have those names.
Prepare for introducing the usage of a MetaBackendNative and MetaBackend
pointers here by cleaning up the naming.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1689>
Fullscreen X11 windows that attempt to change the resolution on Wayland
use a surface viewport to achieve this without affecting the resolution
of the display. This however also means that pointer events will be
delivered in the display coordinates while the code handling the window
frame is not aware of any such viewport scaling. So a right click
outside of the area corresponding to the new resolution will not be
considered to be on the client area. And since the only area that is
ignored when determining whether to perform the right click action, such
as opening the context menu, is the client area, this will result in the
action being performed, despite happening on the (scaled) client area.
While it would be possible to scale the event coordinates so that
get_control() correctly determines the frame element the cursor is on,
viewport scaling only affects fullscreen windows. Since fullscreen
windows have no frame, we can always assume that if the window gets
delivered an event for a fullscreen window, it is on the client area
without doing any additional calculations.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1592
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1661>
We remove pending pings when unmanaging a window, but currently
don't prevent new pings to be scheduled after that.
The previous commit fixed a code path where this did indeed happen,
but as the result of gnome-shell trying to attach a Clutter actor
to a non-existent window actor is pretty bad, also guard can_ping()
against being called for an unmanaging window.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2467
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1676>
This seems to have been the default in the past, but was (accidentally?) modified
by 8adab0275.
For GNOME 40, we'll be returning to our root with horizontal workspaces, so instead
of overriding it in GNOME Shell side, change the default back to what it once was.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1684>
If we are about to replace `redraw_clip` with a clamped version of itself
then we may as well do the same for `queued_redraw_clip`, so you can see
more precisely what the damage of the current frame is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1554>
Initially we generate the new part of fb_clip_region from the new part
of redraw_clip, scale it up and clamp. But the clamping means the new
part of fb_clip_region might now represent a slightly larger area than
the new part of redraw_clip, by one pixel.
In some rare cases where a foreground actor honours redraw_clip, but
the background actor does not (meaning it might fill all fb_clip_region),
you could find 1px rendering glitches in that gap as the background
actor paints there but the foreground actor does not.
To ensure such glitches can never happen we now regenerate the final
redraw_clip as a clamped superset of the final fb_clip_region. That's
the minimum area we must paint to ensure no gaps appear inside
fb_clip_region.
Although the fix here sounds like the intent of the old code, the old
code forgot to include the new part of fb_clip_region in the clamping
of the final redraw_clip. So the new part of redraw_clip was sometimes
kept too small for the new part of fb_clip_region.
We also move the code to the main path because technically it's also
needed when `has_buffer_age == FALSE`.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1500
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1554>
We'll have two persistent client connections alive for the whole test,
one X11 client, and one Wayland client. So in order to be able to set up
the async waiter, do so after setting up the X11 client, as after that
we know we'll have a MetaX11Display ready to use.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1681>
One for the public channel, and one for the private maintainance
channel. Use the public one for test clients, otherwise tests become
flaky, and the private one for MetaX11Display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1681>
This adds a MetaKmsImplDevice backend using atomic drmMode* API in constrast to
non-atomic legacy drmMode* API used in MetaKmsImplDeviceSimple.
This has various behavioral differences worth noting, compared to the
simple backend:
* We can only commit once per CRTC per page flip.
This means that we can only update the cursor plane once. If a primary
plane composition missed a dead line, we cannot commit only a cursor
update that would be presented earlier.
* Partial success is not possible with the atomic backend.
Cursor planes may fail with the simple backend. This is not the case
with the atomic backend. This will instead later be handled using API
specific to the atomic backend, that will effectively translate into
TEST_ONLY commits.
For testing and debugging purposes, the environment variable
MUTTER_DEBUG_ENABLE_ATOMIC_KMS can be set to either 1 or 0 to
force-enable or force-disable atomic mode setting. Setting it to some
other value will cause mutter to abort().
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/548
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
In order to reliably manage the reference count of the user data passed
to page flip listeners - being the stage view - make the ownership of
this data travel through the different objects that take responsibility
of the next step.
Initially this is the MetaKmsPageFlipListener that belongs to a
MetaKmsUpdate.
When a page flip is successfully queued, the ownership is transferred to
a MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. In the
simple impl device, the MetaKmsPageFlipData is passed to
drmModePageFlip(), then returned back via the DRM event. In the future
atomic impl device, the MetaKmsPageFlipData is stored in a table, then
retrieved when DRM event are handled.
When the DRM events are handled, the page flip listener's interface
callbacks are invoked, and after that, the user data is freed using the
passed GDestroyNotify function, in the main context, the same as where
the interface callbacks were called.
When a page flip fails, the ownership is also transferred to a
MetaKmsPageFlipClosure that is part of a MetaKmsPageFlipData. This page
flip data will be passed to the main context via a callback, where it
will discard the page flip, and free the user data using the provided
GDestroyNotify.
Note that this adds back a page flip listener type flag for telling the
KMS implementation whether to actively discard a page flip via the
interface, or just free the user data. Avoiding discarding via the
interface is needed for the direct scanout case, where we immediately
need to know the result in order to fall back to the composite pipeline
if the direct scanout failed. We do in fact also need active discard via
the interface paths, e.g. in the simple impl device when we're
asynchronously retrying a page flip, so replace the ad-hoc discard paths
in meta-renderer-native.c and replace them by not asking for no-discard
page flip error handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Suspending might have changed the CRTC configuration, turning some off,
some on, etc. We need to update our internal representation of this
state, so that we know how to reconfigure upon resuming, e.g. what CRTCs
to turn off again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Destroying an onscreen destroyes the gbm_surface, the gbm_bo's, and the
fb_id's. Doing this (drmModeRmFB() of the fb_id specifically), may on
some hw implicitly disable the CRTC of the plane that framebuffer was
assigned to. This would cause following atomic commit that attempts to
disable the CRTC to fail as disabling an already disabled CRTC is not
allowed.
It'd also mean we'd always disable the plane before having finished next
mode set, leaving it monitor content potentially empty when not really
necessary.
Solve this by keeping the CoglOnscreens (thus the gbm_surface, gbm_bo
and fb_id) alive until the following global mode set has completed, i.e.
the new state has been fully committed and applied.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes "power save" (i.e. when you make a monitor go into power save
mode, or make it come out of power save mode), a per device action when
turning on power saving (power save being set to 'off'), and implicitly
handled when turning off power saving (power save being set to 'on')
when doing a mode set.
This is needed as with atomic mode setting, the configuration of DPMS
(Display Power Management Signaling), is replaced by directly turning on
or off CRTCs, and via the CRTC drm properties. Thus in order to handle
both with a common API, make that API high level enough for both cases
being covered.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Before we received new gamma updates via D-Bus and posted the update to
KMS directly. This won't be possible with atomic KMS, since one can only
update the state of a CRTC once per cycle.
Thus, to handle this, when configured by D-Bus, only cache the value,
and mark it as invalid. The next frame, the native renderer will pick
up the newly cached gamma value and configure the CRTCs accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
We cannot switch DPMS state to 'on' first, then mode set later, when
using atomic KMS. So when we're turning it on, just let the eventual
mode set handle DPMS too.
When switching DPMS to 'off', do it directly, synchronously, both by
setting the DPMS state and switching off CRTCs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Before each frame is maybe redrawn, push any new cursor KMS state to the
pending update. It'll then either be posted during the next page flip,
or when the same frame finishes, in case nothing was redrawn.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This makes it possible to post a symbolic page flip and frame callback,
meant to be used by immediate symbolic page flip reply when emulating
cursor plane changes using legacy drmMode* functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
We will soon need to use CoglOnscreen frame events communicate cursor
plane changes; this means we need to have a way to queue them without
going through any of the current APIs that can do so, i.e. the swap
buffer functions and direct scanout.
Add a function that just adds a frame info to the queue. The one who
adds it is responsible for emitting it too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Just as with the frame clock, add an API to communicate that a frame did
not result in a presentation. This can't happen yet but will when we
emulate atomic cursor plane changes using legacy drmMode API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
In constrast to notify_presented(), notify_ready() also returns the
state machine to the idle state, but without providing new frame
information, as no frame was actually presented.
This will happen for example with the simple KMS impl backend will do a
cursor movement, which will trigger a symbolic "page flip" reply in
order to emulate atomic KMS behavior. When this happen, we should just
try to reschedule again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Don't mode set each CRTC in separate KMS updates, as reconfiguring one
CRTC might cause other CRTCs to be implicitly reset thus as well,
causing KMS return EBUSY if using atomic modesetting.
Prepare for this by compositing each CRTC first including adding steps
to the KMS update, but wait until all views has rendered at least once
before posting the initial update. After this each CRTC is posted
separately.
Using EGLStreams instead of normal page flipping seems to fail when
doing this though, so handle that the old way for the EGLStream case,
i.e. eglSwapBuffers() -> mode set with dumb buffer -> eglStream
"acquire" (resulting in page flip under the hood).
For this we also introduce a new error code so that we don't use client
buffers when doing mode sets, which could accidentally configure the
CRTC in a way that is incompatible with the primary plane buffers.
Do the same also when we're in power save mode, to only have one special
case path for this scenario in the regular swap-buffer path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of setting the frame result in the most generic layer, have the
backends do it themselves. This is necessary to communicate that a
swap-buffer call didn't really succeed completely to present the swapped
buffer, e.g. errors from KMS.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This argument is intended to be used by clutter to be able to
communicate with the onscreen backend, that happens to be the native
backend. It will be used to pass a ClutterFrame pointer, where the
result of page flips, mode sets etc can be communicated whenever it is
available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
ClutterFrame aims to carry information valid during dispatching a frame.
A frame may or may not include redrawing, but will always end with a
result.
A asynchronous page flip, for example, will result in a
CLUTTER_FRAME_RESULT_PENDING_PRESENTED, while a frame that only
dispatched events etc will result in CLUTTER_FRAME_RESULT_IDLE. Instead
of this being implicit, make the ClutterStageWindow implementation
handle this itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
The way drm events are handled depends on whether we're using atomic or
not. Lets move the handling to the implementation, so that later the
atomic backend can handle the event they it need to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If we reassign e.g. a cursor plane twice before it's updated, we need to
make sure the 'fb-unchanged' flag is correctly handled, so that if we
changed the fb first, then updated the assignment again only changing
the position, the new assignment should not be flagged with
fb-unchanged.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
When we e.g. try to post an direct client buffer scanout update, it
might arbitrarily fail; when this happen we still will want to post the
rest of the update when we try again after having composited the primary
plane. To do this, add a way to preserve the metadata of an update if it
failed, only dropping the failed plane assignments. This involves
unlocking a previously locked MetaKmsUpdate, so that e.g. a new primary
plane can be assigned.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Sealing is a one way operation, but in the next commit, the "seal" will
be broken, so to avoid missusing the "seal" terminology, rename related
methods and variables to use the term "lock" instead. E.g.
meta_update_is_sealed() is now meta_update_is_locked().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If a modeset is pending, it's likely that the cursor update will not
work; thus, wait with updating the cursor so that it's applied together
with the mode set update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Something might want to affect the next update that is going to be
posted, but without posting it immediately. For example, changing the
cursor might need to wait for mode setting. Make it possible to get
feedback from posting the update, in order to gracefully handle any
errors.
Note, the API for notifiying about results take out the result listener
from the update, and notifies them in an open coded for loop. The reason
for this is that in the next commit we'll sometimes reuse updates, and
we only want notify about the results once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Page flipping shouldn't necessarily be an actively requested action, but
happen implicitly depending on the given state. Thus, change the "page
flip" update into adding listeners for page flip feedback instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This will later make it possible to pass cursor plane assignments,
together with a complete update including the primary plane, but not
failing the whole update if just processing the cursor plane failed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
If posting an update resulted in an immediate error, don't communicate
this failure using the page flip feedback callbacks, but directly as a
return value.
This makes it possible for the direct client buffer scanout path not to
pass around flags triggering this behavior, meaning we can handle such
direct scanouts better.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a "post all pending updates", pass an update specific to a
single device. This gets rid of the awkward "combine feedback" function,
and makes it possible to queue updates to a multiple devices without
always posting them together.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Custom page flips are meant to allow using e.g. EGLStream API to
indirectly trigger page flip queueing, when the KMS API cannot be used
directly. This is really something that is specific to a device, so
instead of making part of the page flip API, make it a configuration of
the update itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Eventually the type of impl device will depend on the driver details, so
get that information before constructing the impl device. This commit
doesn't introduce any new usage of the details, it just prepares for
the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This commit consolidates DRM buffer management to the MetaDrmBuffer
types, where the base type handles the common functionality (such as
managing the framebuffer id using drmModeAdd*/RMFb()), and the sub types
their corresponding type specific behavior.
This means that drmModeAdd*/RmFB() handling is moved from meta-gpu-kms.c
to meta-drm-buffer.c; dumb buffer allocation/management from
meta-renderer-native.c.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
For now feedbacks from an update are combined, meaning we might lose
error information. The feedback API may have to be reconsidered and
redesigned when planes gets a more front seat position.
This means we need to avoid trying to post updates if we're in power
save mode, as it may be empty.
Note that this is an intermediate state during refactoring that aims to
introduce atomic mode setting support, and we'll stop combining
feedbacks completely in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of a constructor method, use the type directly and handle error
reporting using GInitable.
The DRM capability setting is done before construction, as later it'll
determine what type of impl device should be constructed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of telling MetaKmsConnector fill a MetaKmsUpdate with connector
property changes, make the update itself aware of the changes, making
the impl side translate that to property changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of having MetaKmsPlaneAssignment carry a low level property
list, set the actual state change, and then have the implementation
translate that into the necessary property changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
With the aim at always using the property table to fetch and parse
property metadata, move IN_FORMATS handling to the property table, using
the newly introduced parse vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Values may need to be processed and parsed in custom ways; make this
possible via the property table infrastructure using a callback.
Will be used for e.g. parsing rotation and formats.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Instead of relatively verbosely going through the DRM properties finding
the properties we care about and saving their ID's, add a more
declarative way to fetch property metadata. This'll allow for fetching
more property IDs with relatively less code, which will be useful for
the atomic backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
This contains a copy of a drmModeModeInfo, describing a mode. It also
has an unused pointer to the impl device it is associated with. It'll
later be used to get a blob ID for the mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1488>
Current Xwayland has marked the command line option "-listen" as
deprecated in favor of "-listenfd".
Use the pkg-config variable "have_listenfd" (if available) from Xwayland
to determine if we should use that option, to avoid a deprecation
warning when spawning Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1682>
Mutter listens to two display connections, one for regular X11 clients
and another one for the so called "managed services".
Once an available display number is found for the regular X11 clients,
mutter would then redo the work to find another available display number
for the managed services.
Yet, it does so starting from the same initial display, which is a waste
of time since it just tried all displays to find the first available
one, so all these, including the regular display it just took, are now
in use.
So instead of starting over from the beginning when looking for a
display available for the managed services, continue from the next
display immediately after the one we found precedently.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1680>
Some X11 servers may not always create a lock file, yet mutter uses the
lock file to find a possible display number and then tries to bind to
the socket corresponding to that display number.
If it fails to bind, it will simply bail out. As a result, if an X11
server is already listening on that display but hadn't created a lock
file, mutter won't be able to start Xwayland.
To avoid that possible issue, make mutter retry with another display
for a given number of tries when binding fails even though the display
was supposed to be available based on the lock file presence.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1604
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
The function choose_xdisplay() calls open_display_sockets() which calls
ensure_x11_unix_dir().
We don't need to do that from within the loop though, as the directory
/tmp/.X11-unix is the same regardless of the display number.
Move the call to ensure_x11_unix_dir() from open_display_sockets() to
choose_xdisplay() prior to enter the display loop.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
In case of failure to open the display sockets, we would not propagatre
the error which can cause a crash when trying to show the error message.
Properly propagate the error to avoid the crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1669>
In the shutdown paths we check with the X11 display whether there's
remaining clients. However this happens in paths that happen after
the MetaX11Display vanished in the case of Xwayland crash.
Since in that situation the clients are forcibly vanishing too,
skip the client check.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1677>
This means backend implementations can have more control of the order of
how things are destroyed. To be precise, this will, in the next commit,
allow us to destroy the logind integration after the clutter backend
thus the libinput owning seat, that uses the logind integration to
release input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
We can't post tasks to the input thread when cleaning up the
MetaSeatImpl, as that will make the GTask complain about adding
references to a to be purged object. Avoid this by adding an explicit
meta_seat_impl_destroy() function that handles the destruction of the
MetaSeatImpl properly.
This also does more of the cleanup in the input thread, as that is where
it was managed. Will likely not make a difference as before this
happened after tearing down the thread, but lets tear down things in the
thread they were managed for good measure.
This fixes the last log spew I see right now when terminating mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
Closing automatically Xwayland once all relevant X11 clients are gone is
inherently racy, if a new client comes along right at the time we're
killing Xwayland.
Fixing the possible race conditions between mutter, Xwayland and the X11
clients may take some time.
Meanwhile, make that an experimental feature "autoclose-xwayland".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1673>
<super> is considered a system modifier, and applications cannot use it
for keyboard shortcuts or as button modifier. It doesn't seem too much
of a loss taking <super>+scroll-event away as well, so that it becomes
available to gnome-shell/extensions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1674>
Currently, mutter checks for the presence of X11 windows to decide
whether or not Xwayland can be terminated, when Xwayland is started on
demand.
Unfortunately, not all X11 clients will map a window all the time, an
X11 client may keep the X11 connection opened after closing all its
windows. In that case, we may terminate Xwayland while there are some
X11 client connected still, and terminating Xwayland will also kill
those X11 clients.
To avoid that issue, check the X11 clients actually connected using the
XRes extension. The XRes extension provides the PID of the (local) X11
clients connected to the Xserver, so we need to match that against the
actual executable names, and compare with a list of known executables
that we can safely ignore, such as ibus-x11 or gsd-xsettings.
We also check against our own executable name, considering that the X11
window manager is also an X11 client connected to the Xserver.
Also, XRes returning the PID of local clients only is not a problem
considering that Xwayland does not listen to remote connections.
However, if the user spawns a client remotely on another system using
ssh tunneling (ssh -X), only clients which actually map a window will
be accounted for.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1537
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1671>
Some GSettings schemas moved from g-s-d to gsettings-desktop-schemas
in g-s-d 40.alpha. 40.alpha.1 didn't include the corresponding
adjustment, so do a quick follow-up release to not abort on startup
with the latest g-s-d release.
ClutterClickEvent currently doesn't check if button press and release
happen within the drag threshold, which can be surprising sometimes.
Only emit the "clicked" signal if the button press and release happen
within the area of drag threshold.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1667>
Changes in games between fullscreen and windowed modes may trigger
chaotic situations where the buffer and the frame size temporarily
disagree, producing rectangles with negative width/height. This is
usually followed by other updates that bring the pointer constraint
up to date.
This makes cairo panic and return an "error" empty region, which breaks
deeper down when using the region rectangles to apply the pointer
constraint.
If we hit this situation, ignore the frame rectangle, and just go with
the buffer rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1655>
We didn't tear down the libinput objects in the right thread when
exiting, but did so after the input thread exited.
We also tried to destroy the libinput devices after the libinput context
was destroyed, which isn't allowed.
Fix these two issues by tearing down the libinput objects in a input
thread task that when done exits the input thread. This effectively
"flushes" the input thread tasks while destroying the libinput objects
just before the thread exits.
While it might fine to tear down libinput objects in an arbitrary (main
in this case) thread while making sure nothing pokes at it in parallel
(e.g. the input thread is gone), libinput is by definition single
threaded, and could theoretically make assumptions about this, and we
shouldn't cause any possible surprises here, so make sure to destroy it
all in the right thread.
This fixes an abort() on exit caused by an assert about invalid object
destruction in libinput.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
The "seat" usually refers to the ClutterSeat (MetaSeatNative) object,
and "seat_impl" to the MetaSeatImpl object, but there were still a few
places where this wasn't adhered to so fix those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
When supported, this property allows the window system to apply a 3x3 color
correction matrix in order to transform colors from the window system's native
color space to the measured color space of a display device.
Query for this property and set the 'supports-color-transform' property in the
GetResource reply. Add support for the SetOutputCTM DBus method and plumb that
through to the server's CTM property.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1048>
Add a test case to check whether the stage views and frame clocks are
all correctly freed after working with timelines a bit and then
hotplugging and removing all monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1632>
In clutter_timeline_set_actor() we currently always unset the
priv->frame_clock pointer of the old actor when a new actor gets set.
The priv->frame_clock pointer takes a reference on the ClutterFrameClock
though, so we leak ClutterFrameClocks here.
To fix it, simply rely on update_frame_clock(), which will call
set_frame_clock_internal() unconditionally to update the
priv->frame_clock pointer for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1632>
Currently, the NotifyPointerAxis method always assumes that the scroll
source is CLUTTER_SCROLL_SOURCE_FINGER.
This is however not always true and in some cases a remote desktop
client needs to submit a PointerAxis event with a custom axis step.
This is for example the case with high resolution mouse wheels, where
the NotifyPointerAxisDiscrete method is unsuitable.
In such cases NotifyPointerAxis needs to be called, but with the
intention that the scroll source is still a mouse wheel.
To solve this situation, don't assume the scroll source always to be
CLUTTER_SCROLL_SOURCE_FINGER.
Instead, add further flag options to NotifyPointerAxis, which allow a
remote desktop client to choose the scroll source.
This way a remote desktop client can choose what scroll source is the
most suitable one for the current scroll event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1636>
The monitor texture is the final background image. It doesn't need to
have any alpha channel. Cross-fades (which is the process of rendering
*into* the monitor texture) still work just fine.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1665>
Because the framebuffer itself might be backed by a texture, which might
have mipmapping enabled. If so then rendering to the framebuffer will make
those mipmaps out of date.
Technically we are flagging the framebuffer's mipmaps as dirty *before*
they are, because the journal hasn't been flushed yet. But we need to do
it early because ideally the next flush will both write the offscreen
framebuffer contents and then read them for use in rendering to an onscreen
framebuffer. And the `mipmaps_dirty` flag needs to be set before the read,
so therefore we need to do it before the next journal flush.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3146
where the offscreen framebuffer in question is meta-background's
`monitor->fbo`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1664>
Some effects such as the BrightnessContrastEffect try to skip rendering
by returning early with a FALSE return value in pre_paint() in cases
where the effect would not change the rendering. This stopped working
when effects were ported to paint nodes.
In the case of OffscreenEffects, like BrightnessContrastEffect,
pre_paint() is responsible for setting up the offscreen buffer which is
then used in paint_node(). However if pre_paint() fails, this buffer is
not created and attempting to use it will result in several error
messages and broken rendering.
Instead of trying to call paint_node() of the effect if pre_paint()
failed, just draw the actor.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1576
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1658>
Unfortunately there's situations where we can't fully rely on only
crossing events here. One such situation is pointer visibility changes
due to touch interaction, or e.g. after closing the lid.
In these situations the pointer position stays the same, picks the
same actor, yet we want to see the right surface as the pointer focus
again in the wayland side.
This used to happen on the first motion event after the pointer
visibility change before commit ad3f2b0b86, use motion events again
for picking so we don't break these usecases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
These events may be emitted for touchpoints (in which case they contain
an event sequence). Ignore those as they are not relevant for pointer
picking, and shouldn't influence its focus.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
When using alt-tab to switch between windows, on a key handler we
undo the compositor grab, which triggers a repick, which generates
crossing events, which are handled in place, and trigger these
reentrancy checks.
On one hand, we do intend these crossings to take effect in place,
rather than being queued (possibly after a number of already queued
events). On the other hand, we now outright discourage generating
events from random places (and hope to make it just not possible,
eventually) thus we can afford not to protect against reentrancy
caused by API misuse.
So just drop these checks, and let these crossing events be
properly handled.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
This signal may be left dangling when disconnecting a device, and be executed
later on if the device is connected again, and mapped to other output. Make it
sure the signal handler is disconnected when unplugging the device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1657>
Just because of implementation details, this is only relevant to Wayland,
and is done via ::effects-completed handlers there. Ideally, Clutter should
notice by itself about effects starting, finishing, and affecting picking.
Doing this in generic code seems slightly cleaner in the interim.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
This is the very same code than meta_wayland_pointer_repick(),
made part of Clutter, so triggering repicks on the same pointer
coordinates is made easy.
The intention is to remove meta_wayland_pointer_repick() in favor
of this call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
In the wayland code we are in synchronization with the events that
the ClutterStage is managing at the moment. Asking the ClutterSeat for
the pointer position gets ahead of the current events, and may result
in imprecise coordinates sent in wl_pointer.enter.
To be in consistence with the motion events that might be already
queued, we should ask the stage for the last known coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
Updating the state before emitting the CLUTTER_LEAVE event allows its
handlers to query the pointer actor, and avoid getting the same actor
again. Conceptually, this makes picking more "atomic", and the events a
notification of the change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
To clear a pointer constraint, the Wayland backend passes a NULL
constraint to the native input backend.
The new async API however tries to reference/un-reference the given
object to use it while running in a separate task, which leads to a
warning from GLib trying to g_object_ref()/g_object_unref() a non
GObject pointer.
To avoid that issue, simply set the data only if the given constraints
pointer is not NULL.
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1587
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1652>
I messed up and released 40.alpha at the same time as 3.38.2, when it's
supposed to be in January. In order to re-align with the schedule, change
the upcoming version to 40.alpha2 so we don't have to skip a release and
will be back on track in time of 40.beta.
Turns out GObject implicitly notifies all properties by default as soon
as a property setter is called, no matter if the property actually
changed or not. One can opt-out of this behavior by setting the
G_PARAM_EXPLICIT_NOTIFY flag.
So since almost all our properties get notified explicitely (well,
except ClutterActors deprecated show-on-set-parent property), set this
flag for all properties of ClutterActor and ClutterStage now. This
significantly reduces the number of notify:: signals emitted on
ClutterActors, because in gnome-shell javascript we usually set GObject
properties directly, not by going through the extra setter method.
More cleanups can be done in the future, since this flag is suitable for
almost every property in Clutter and even Mutter.
This fixes a crash where we'd hit a newly introduced assertion in
on_device_actor_reactive_changed() of ClutterStage because
notify::reactive got emitted multiple times.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1651>
Due to a few reasons currently the updating of input devices after stage
relayouts isn't working right now. Since we now have a list of pointer
devices in ClutterStage, we can simply use that list and can avoid
asking the input thread. Also we no longer need to check whether the
devices are pointer devices, since our list only consists of pointer
devices.
So switch to ClutterStages private list of pointer devices, which also
includes the core pointer (as opposed to the list returned by
clutter_seat_peek_devices()). This fixes picking after relayouts.
Note that this doesn't catch every possible change that might need a
repick, actors might also need a repick after transformation changes or
in case their custom clip has been changed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1634>
find_focusable_ancestor() may pick an ancestor window which is not
mapped or hidden, and setting focus on that window will fail.
Be a tad more selective when looking for a focusable ancestor, to reduce
the chance of meta_window_focus() not focusing the happy chosen one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1643>
The function focus_default_window() optionally takes a MetaWindow
argument denoting a window that should not be focused.
That function calls focus_ancestor_or_top_window() which in turn
calls meta_window_focus() to pass focus to another window.
However meta_window_focus() gives no guarantee that the given window
will end up being the one focused, and can fail in various and creative
ways.
If that fails, we could possibly end up with the focus window being the
one to avoid, while the caller assumes focus was changed, going as far
as asserting that fact like meta_window_unmanage() does.
As a result, mutter may abort simply because meta_window_focus() failed
to set focus on the expected window.
To avoid that issue, check that the focus did not end up on the window
that we explicitly did not want, and if that's the case, simply fallback
to the default focus window.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/862
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1643>
If texture allocation failed for a sliced 2D texture, the alloc()
function would free the slices immediately, but not clear the pointer to
the slices array. When the code attempting to allocate the texture then
freed the texture object, the cleanup functions tried to free the slices
array again, since it wasn't NULL.
Fix this by clearing the slices array after freeing it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1580
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1648>
As planned and prepared with the last commits, let ClutterStage take
care of tracking input devices and their respective actors. This means
we now can remove the old infrastructure for this from
ClutterInputDevice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
We're moving keeping track of input devices and their associated actors
out of ClutterInputDevice, this commit basically adds replacements for
clutter_input_device_update() and clutter_input_device_set_actor() to
clutter-main and shuffles the internals of those functions around a bit
for clarity.
clutter_stage_update_device() is made available in clutter-mutter.h
because we need to update the actor of input devices not only from
ClutterStage (when repicking after relayout), but also from
MetaWaylandPointer (inside meta_wayland_pointer_repick()).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
With the introduction of the input thread, we want to avoid modifying
ClutterInputDevices from the main thread, since they're owned and
updated by the thread.
There's one part of ClutterInputDevice that's still modified from the
main thread though, that is device-actors of pointer devices, and we're
going to move that state-tracking into ClutterStage instead.
So start that by adding the infrastructure to ClutterStage to keep track
of those things. It consists of two hashtables which associate devices
and touch sequences with actors, those hashtables get updated using
clutter_stage_update_device_entry() and
clutter_stage_remove_device_entry(), they can be queried by calling
clutter_stage_get_device_actor(), which will replace
clutter_input_device_get_actor().
clutter_stage_get_device_coords() is added and made available in
clutter-mutter.h because we need to get the coordinates when repicking
in meta_wayland_pointer_repick().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
The n_steps variable corresponds to the number of *pairs* of
texture lookups that the blur shader does. For example, when
n_steps = 1, the for-loop reads 1 pixel before and 1 pixel
after the current one.
Our blur shader is heavily inspired in WebRender's blur shader,
the biggest difference being that we calculate the gaussian
samples in the fragment shader itself, and not in the vertex
shader. (This could be an improvement in performance for the
future though!)
WebRender's blur shader calculates n_steps differently than what
we currently do, though. It calculates n_step in such a way that
at least 2 steps are performed for evey non-zero sigma value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1646>
The shader already operates on floating point sigma, and
there's just no reason for us to force it to be an unsigned
integer. It's still important that sigma must be positive
though.
Make sigma a float, and make sure it's a positive number.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1646>
Yet another way to reduce the instruction count of the fragment
shader. Passing a pair of floats once is virtually free, compared
to computing horizontal and vertical on each fragment run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1646>
New entries indirectly added to `pending_queue_redraw` during the loop
would make our iterator invalid and cause `g_hash_table_iter_next` to
fail without having visited all elements. That was seen as assertion
failures but also likely resulted in incomplete paint clips.
Now we steal the iterator's entry before such corruption can happen,
free it manually, and reset the iterator to the beginning on every
iteration. This is actually safe and efficient because we're removing each
entry we visit. So no time is wasted in resuming from the (new) beginning
of the hash table.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1557
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1615>
Add a new pair of APIs corresponding to CoglFramebuffer's draw_rectangles()
and draw_textured_rectangles(). They're generally more performance compared
to adding multiple single-rect operations. These variants are heavily used
by GNOME Shell's CSS implementation.
The op array is built to match cogl_framebuffer_draw_textured_rectangles()
always, which means it's a series of 8 floats composed (x1 y1 x2 y2) and
(s1 t1 s2 t2). To avoid adding new struct fields to ClutterPaintOperation,
which is a performance and memory sensitive structure, simply divide the
array length by 8 (which is guaranteed to be correct).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1637>
Power saving changes in laptop panels enable/disable the attached
touchscreen input device, this is an asynchronous operation that
may be happening while the device is disappearing.
In fact, closing the lid is such perfect storm where both things
happen around the same time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1644>
Currently, the MetaInputDeviceNative owns the libinput_device, with the
small catch that it is eventually finished in the main thread (as the
CLUTTER_DEVICE_REMOVED event keeps the last reference to it).
Make it sure that the libinput_device is destroyed in the input thread,
before giving away the last extra input device references.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1639>
Setting an ortho projection gives us pretty much the same result as
manually calculating the projection matrix. The ortho projection is
actually more "complete" than the custom projection we've been using,
as it also considers z-near and z-far, but in practice the generated
pixels are exactly equal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1642>
There was an attempt to remove an unnecessary inclusion of a header
file, but only got so far as compile testing after having commented out,
but didn't remove the comment before creating a commit. This commit
fixes that mistake.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1640>
In the purely paint node based rendering future, ClutterEffects
simply add more paint nodes to the tree when painting the actor.
This is the leap to achieve that future.
Add paint nodes to pre_paint, paint, and post_paint, and move the
ClutterEffectNode creation to _clutter_effect_paint().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
The paint node tree that ClutterOffscreenEffect generates is
simple:
Root
|------------+
| |
Layer Pipeline
|
Actor
Right now, both pre-paint and ClutterLayerNode push the offscreen
to the framebuffer stack. That's harmless, and will go away soon
anyway.
The actor node is created and added in a separate function because
it'll be reused by the next commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
Add a new ClutterPaintNode parameter to the paint_target() vfunc.
For now, create a temporary ClutterEffectNode that is passed to
paint_target() and immediately painted; next commits will move
this to upper layers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
The blur pipeline is still cached on ClutterBlurEffect, and we
simply update the uniforms when asked to create the pipeline.
Now that ClutterOffscreenEffect will use the blur pipeline, it
doesn't need to override the paint_target() vfunc anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
The most annoying aspect of ClutterOffscreenEffect right now, and
the reason for all its subclasses to override pre-paint, is that
the pipeline creation isn't under subclasses' control. That means
all subclasses must ask ClutterOffscreenEffect to run pre-paint
and create the pipeline, then they all create their own pipelines
to paint.
To reduce this complexity, add a new create_pipeline() vfunc to
ClutterOffscreenEffect. Next commits will port effects to use this
new vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
ClutterLayerNode currently skips pushing the offscreen framebuffer when
no operations are set. This was added at the time because pushing and
popping was a synchronization point in Cogl, slow enough to force the
layer node to have this protective measure. Nowadays, pushing and
popping on the paint context is free.
Make ClutterLayerNode always push and pop in pre and post paint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1355>
Xwayland in its main development branch now provides a pkg-config file
which can be used to determine Xwayland installation path and various
options enabled at build time.
Change mutter build system to optionally use that mechanism if
available. If not (as with Xwayland from the current stable branch),
keep the fallback mechanisms (basically search for the Xwayland and parse
its command line options to determine if initfd is available).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1635>
ClutterBlurNode is a paint node based on ClutterLayerNode
that draws all children in an offscreen framebuffer, blurs
this framebuffer, and finally paints the blurred contents
according the the paint operations added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1627>
Copy-paste error sneaked ClutterTransformNodeClass in
clutter_blit_node_class_init(). It wasn't problematic
because they both typedef to ClutterPaintNodeClass, but
fix it anyway.
Also switch to g_object_ref() in clutter_blit_node_new().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1627>
Until now we would `clutter_input_focus_set_cursor_location` with
cursor-rectangle-in-physical-pixels + actor-location-in-stage-coordinates.
But those use different scaling factors so it only got the right answer
when the framebuffer scale was 1.0.
This directly determines the geometry of the invisible dummy cursor in
gnome-shell ibusCandidatePopup.js:
```
panelService.connect('set-cursor-location', (ps, x, y, w, h) => {
this._setDummyCursorGeometry(x, y, w, h);
});
```
And because it's invisible it wasn't obvious that it was wrong until you
enable `CLUTTER_PAINT=damage-region` and you can see its ghost at the wrong
offset and scale.
So now we `clutter_input_focus_set_cursor_location` using purely unscaled
stage coordinates. And `CLUTTER_PAINT=damage-region` shows that
gnome-shell's `_dummyCursor` is placed precisely over the visible cursor.
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3399
and probably other IBus issues that arise when using framebuffer scaling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1576>
`priv->cursor_rect` is stored in physical pixels, not local coordinates.
So unscale it before returning from `clutter_text_get_cursor_rect`, which
is explicitly documented as returning "actor-relative coordinates".
This went missed with fractional scaling support, and unnoticed as nobody
uses `clutter_text_get_cursor_rect` yet. But that will soon change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1576>
Before now it was assumed that the only negative local coordinates would
be those introduced by `_clutter_actor_box_enlarge_for_effects`, and we
used the difference for `fbo_offset_x/y`. But that was misguided (of me)
because gnome-shell can give us paint volumes at negative coordinates too,
like when rendering `box-shadow` on the top or left edge of an actor.
The maximum extents of negative coordinates we might need to render are
in fact the (enlarged) left and top edges of the paint volume. So use
those as the FBO offset. This places the actor's local origin correctly
within the FBO and thus also ensures it's not over-clipped at the edges
of the FBO, which now line up with the enlarged extents of the paint
volume.
This fixes one third of
https://gitlab.gnome.org/GNOME/gnome-shell/issues/1090
The other fixes required are !1053 and gnome-shell!1417.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1538>
Apparently it can happen that a timeline tries to pick a frame clock
from an actor that's on a stage, but the actor still doesn't find a
frame clock and returns NULL.
This probably is the case when starting a timeline right after attaching
an actor to a newly created stage, so before the first stage-update
cycle. In this case clutter_actor_update_stage_views() will not have run
and the stage-actor will have priv->stage_views set to NULL even though
there are stage views.
To prevent this from happening, use the complete list of stage views
maintained by the backend when picking a frame clock for the stage.
This doesn't fix any issue appearing on master, but is correct
nonetheless.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1631>
$CI_COMMIT_REF_NAME can be a branch name or a tag, depending on the
pipeline, but our checkout script only deals with the former at the
moment.
Address this by rather than looking for a remote branch name, just
try to fetch the ref like we do for merge request pipelines.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1630>
We are currently not very good at communicating what's going in,
in particular for non-merge request pipelines where the output
is usually just "Using origin/master instead" (instead of what?).
Improve this by consistently communicate what we are looking for,
whether we found it, and what we end up doing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1630>
When we're running under a polyinstantiated SELinux environment, we'll
likely start with an isolated and empty /tmp, meannig no /tmp/.X11-unix
directory to add things to. To make it possible to still function in
this kind of setup, make sure said directory exists.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1626>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
Making this an event is overly convoluted, accounting that we
emit the event, then convert it to a ClutterStage signal, then
its only consumer (a11y) sets the active ATK state.
Take the event out of the equation, unify activation/deactivation
of the stage in MetaStage, and use it from the X11 backend too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
It is not possible to express a blit operation using paint
nodes as of now. This is a requirement for GNOME Shell, e.g.,
to implement its blur effect.
Add a new ClutterBlitNode node that takes two framebuffers as
input, and blits the source framebuffer into the current one
according to added rectangles.
Because this paint node uses the rectangles in a different way
compared to all the other nodes, add an auxiliary method to
ensure all blit operations are valid.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
ClutterLayerNode is the "offscreen framebuffer" node, that paints it's
child nodes in a separate framebuffer, and then copies that framebuffer
to the parent one.
It'll be useful to hand ClutterLayerNode which framebuffer and pipeline
to use, as this is a requirement for porting e.g. ClutterOffscreenEffect
and subclasses.
Add a new clutter_layer_node_new_to_framebuffer() API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
Some effects, such as ShellBlurEffect and ClutterOffscreenEffect, need
to make sure the actor is painted fully opaque. With ClutterActorNode,
however, that is currently not possible.
Add a new 'opacity' parameter to clutter_actor_node_new(). It follows
the opacity override heuristic, where -1 means disable, and anything
else is clamped to [0, 255].
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
Introduce a new paint_node vfunc that, if implemented, allows
the effect to add nodes to a transient paint node that is
immediately painted. This is a transitional step until we
have fully delegated paint node rendering.
The most basic implementation of a ClutterEffect.paint_node
vfunc, and also the default implementation, is with an actor
node, as follows:
```
static void
foo_bar_paint_node (ClutterEffect *effect,
ClutterPaintNode *node,
ClutterPaintContext *paint_context,
ClutterEffectPaintFlags flags)
{
g_autoptr (ClutterPaintNode) actor_node = NULL;
actor_node = clutter_actor_node_new (effect->actor);
clutter_paint_node_add_child (node, actor_node);
}
```
This example gives the exact same behavior of simply calling
clutter_actor_continue_paint(). In the future, the paint node
itself will be a parameter of clutter_actor_continue_paint()
and we'll be able to simplify it event more.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
ClutterEffectNode is a private ClutterPaintNode implementation
that does effectively nothing, but helps organizing the paint
node tree. It also helps debugging, since it can output the
effect class and name to the JSON debugging routines.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
The idea of having a paint node tree is that we don't really need
to retrieve the framebuffer from ClutterPaintContext. For example,
ClutterLayerNode draws into an offscreen framebuffer; if any child
of a layer node needs to retrieve a framebuffer to draw, the layer
node's offscreen framebuffer should be used.
However, clutter_paint_node_get_framebuffer() goes straight to the
root node of the tree, skipping any potential paint nodes with a
custom framebuffer.
Modify clutter_paint_node_get_framebuffer() to walk up the paint
node tree until a node with a custom framebuffer appears. In many
cases, this will end up either in dummy or layer node's custom
framebuffer implementations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1340>
Ensure that color_ptr gets set, and avoid color_char usage too in
that case. Fixes:
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c: In function ‘meta_monitor_manager_kms_set_crtc_gamma’:
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:370:7: warning: ‘color_char’ may be used uninitialized in this function [-Wmaybe-uninitialized]
370 | g_string_append_printf (string, " %c: ", color_char);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:351:12: note: ‘color_char’ was declared here
351 | char color_char;
| ^~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:391:36: warning: ‘color_ptr’ may be used uninitialized in this function [-Wmaybe-uninitialized]
391 | (*color_ptr)[i]);
| ~^~~~~~~~~~~
../../../../Source/gnome/mutter/src/backends/native/meta-monitor-manager-kms.c:350:24: note: ‘color_ptr’ was declared here
350 | unsigned short **color_ptr;
| ^~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
Assert that the region is created, thus we passed a valid enum value
to the get_scaled_region() function. Fixes:
../../../../Source/gnome/mutter/src/compositor/meta-surface-actor.c: In function ‘get_scaled_region’:
../../../../Source/gnome/mutter/src/compositor/meta-surface-actor.c:113:10: warning: ‘scaled_region’ may be used uninitialized in this function [-Wmaybe-uninitialized]
113 | return scaled_region;
| ^~~~~~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
Fixes a compiler warning with -Wmaybe-uninitialized enabled:
../../../../Source/gnome/mutter/clutter/clutter/clutter-actor.c: In function ‘clutter_actor_paint’:
../../../../Source/gnome/mutter/clutter/clutter/clutter-actor.c:3808:50: warning: ‘result’ may be used uninitialized in this function [-Wmaybe-uninitialized]
3808 | else if (result == CLUTTER_CULL_RESULT_OUT && success)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
Which might presumably happen in the unlikely case that there's no clip
frusta.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1624>
It was a test case in the Wayland test client directory, but it wasn't a
Wayland test client but a standalone test linking to libmutter. Since it
uses rlimit to implement certain aspects of the test, it can't be made
part of the regular unit tests, as that means any test running after
being stuck with the rlimit set, thus keep it standalone, but at least
run it as part of the test suite.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1557>
The XIOErrorExitHandler expects (Display *, void *) whereas mutter uses
(Display *, MetaX11Display *).
That causes a warning at build time:
warning: passing argument 2 of ‘XSetIOErrorExitHandler’ from
incompatible pointer type [-Wincompatible-pointer-types]
813 | XSetIOErrorExitHandler (xdisplay, x_io_error_exit, display);
Actually, the MetaX11Display is not even used, so we can just use the
expected API and ignore the value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1621>
The stack and stack tracker tend to cause missed frames from time to
time, especially when there are many open windows. Add some
instrumentation to make it this easily verifiable when profiling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
While browsing sysprof profiling reports, I saw surface-commit taking
significant times sometimes; trace attach too, to see whether such
things are due to e.g. texture uploads.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
Constantly manipulating the stack caused severe stalls (several seconds)
with many open windows when switching workspaces. The cause for this was
that each show/hide call dealt with the stack in isolation, meaning if
you hid N windows, we'd manipulate and synchronize the stack N times,
potentially doing synchronous calls to the X server while doing so.
Avoid the most severe stalls by freezing the stack while calculating
showing; this made the worst case go from several seconds to around
10-20 ms, which is still bad, but by far not as bad.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1616>
Figuring out the MetaSeatImpl this much indirectly is fairly awkward when
the keymap is only updated from the MetaSeatImpl, pass instead the seat
impl's xkb_state, as we have it handy in all the places this is called.
This will not break on NULL seats during initialization, should the numlock
state be restored from previous sessions.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1556
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1612>
The API allows for invalid barriers to be created; in an X11 session,
this could result in involutary early exit, so guard against those with
soft asserts. These will be logged in the journal as warnings, but will
avoid the crash unless compiled out.
Note that this doesn't fix the bug, it just makes it more detectable.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1901610
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1611>
Make it impossible to add individual includes of input thread objects.
This must go through meta-input-thread.h now, which should be enough
to make anyone think it twice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
They're a dime a dozen. If it gets called exclusively from the
input thread, it got one. Hopefully these breadcrumbs will be
enough so people don't lose their way here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This (now) doesn't change anything in regards to the API that the UI
thread should access from the MetaSeatImpl. The MetaInputDeviceNative,
MetaInputSettings and MetaKeymap objects are now considered owned by
the input thread, as well as all of libinput objects.
The MetaEventSource now dispatches events in a GMainContext that is
the thread default to this thread, and all UI-thread-accessible API
(seat and virtual input device API) will be handled in a serialized
manner by that same input thread.
The MetaSeatImpl itself is still considered to be owned by the caller
thread, and all the signals that this object emits will be emitted in
the GMainContext that is default at the time of calling
meta_seat_impl_new().
The MetaInputSettings configuration changes will likewise be handled
in the input thread, close to libinput devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of going through the event queue, stage handling code, and
back to the input device via a vmethod call, do this directly in the
MetaSeatImpl. This is not too different from X11, where everything
happens inside the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
All that is left in the "public" struct is all state that ClutterStage
delegates on ClutterInputDevice. That should move somewhere else, but
not here, not now.
All private fields belong to construct-only properties, with only getter
API, and idempotent vmethods (except keyboard a11y, atm). This should
be enough to make ClutterInputDevice obviously thread safe, outside the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This API is the one accessed from different bits of the UI thread,
make it "async" (it's basically one-way setters, so API stays the same
in the surface) and able to run in the MetaSeatImpl main context.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Simplify the handling of numlock state, so it can be entirely handled
within the input thread. Since the saving/restoring is triggered inside
each backend code, there's no need anymore for meta_backend_set_numlock().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Push it a little bit down to the MetaSeatNative. As both the UI thread
and the input thread are interested in dealing with the xkb_keymap and
it is not meant to be used in different threads, keep 2 separate copies
around.
The keyboard map will always be set from the UI thread, so the xkb_keymap
owned by the MetaSeatNative (owned by the UI thread) can be considered
canonical.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Don't let the vfuncs (meant to be called from the UI thread) deal with
xkb state itself. Instead store the current state in struct fields, which
is then fetched in vfuncs.
This makes the keymap able to be used from the UI thread, while being
maintained by the input thread. Same caveats apply than
clutter_seat_query_state(), you are asking for the most up-to-date state,
but it still may be changing under your feet.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Wrap all keyboard state updates, and all pointer/stylus/touch cursor
position with a write lock, and ::query_state() (The only entrypoint
to this state from other threads) with a read lock.
The principle is that query_state may be called from different threads
(UI so far, but maybe KMS too in the future), while the input thread
may (or may not) be updating it. This state is fetched "atomically"
(eg. x/y will be consistently old or new, if the input thread were
updating it at the same time).
There's other places deep in backends/native that read this state,
they all will run in the input thread, so they count as "other readers"
to the other thread. Those changes are already mutually exclusive with
updates, so they don't explicitly need the RW lock.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
While barriers will be added from the main thread, the native barrier
manager will sit close to the MetaSeatImpl in its own thread. Add the
necessary locking so that we can pass MetaBarrierImplNative from the
UI thread to the input thread, and ensure the MetaBarrier signals are
still emitted in the UI thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Depending on the backend, we want to integrate this object at different
levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but
it will be put deep down with MetaSeatImpl in the native backend, in a
separate thread.
Since we can't depend on a single object type, nor are able to track
ClutterSeat signals neatly, make this API something to be called
explicitly by backends.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
These changes will happen in the input event management code, so let them
be emitted via the MetaSeatImpl, as that's what we'll have neat access to.
The ClutterSeat signals are now emitted from there.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Move most of the functional bits (those meant to run on a standalone
thread) to a MetaSeatImpl object. This object is managed by the MetaSeatImpl
and not exposed outside the friend MetaSeatNative/MetaInputDeviceNative/
MetaInputSettings classes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Banish MetaInputSettings from MetaBackend "public" API, it's now meant to
spend the rest of its days in the backend dungeons, maybe hanging
off a thread.
MetaInputMapper replaces all external uses.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Delegate on the MetaInputMapper all matching of inputs and outputs,
including configuration. Other secondary aspects, like output
aspect ratio for tablet letterbox mode, or toggling attached devices
with power saving changes, are also moved here.
This makes MetaInputSettings independent of MetaMonitorManager,
all interaction with it happens indirectly via public API entrypoints.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Rename the set_tablet_keep_aspect() vfunc into a set_tablet_aspect_ratio()
one that takes an aspect ratio double, instead of leaking monitor info
into subclasses to let them all figure out this number themselves.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We have 2 sources (this one in MetaSeatNative, and the one in
MetaBackend) dispatching ClutterEvents to the stage. Make the
MetaSeatNative one exclusively about dispatching the libinput
queue, and leave ClutterEvents to the other.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This will resort to SW rendering if this cursor renderer does not
own the MetaKmsCursorRenderer, so it's pretty much equivalent thus
far, except we may now implement logic to flip the kms cursor renderer
around.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We actually have a set_send_events() vfunc that can enable or disable
devices at the libinput and X11 input driver level, so use that. A
positive side effect is that those layers will leave the device at
a consistent idle state (as opposed to going mute maybe amid user
input).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
We are aiming for a split of HW and SW cursor rendering management.
Given the HW plane is a limited resource and the amount of cursor
renderers may be >1 (due to tablets, even though we currently use an
always-software cursor renderer there), it would ideally be able to
switch between renderers.
Being MetaCursorRenderer not really a singleton, having cursor
inhibitor accounting here doesn't pan out. Make it MetaBackend API
so all cursor renderers get the same picture.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
These use now more of a "pull" model, where they receive update
notifications and the relevant input position is queried, instead
of the coordinates being passed along.
This allows to treat cursor renderers all the same independently
of the device they track. This notifying of position changes should
ideally be more backend-y than core-y, a better location will be
figured out in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Different devices may get standalone cursor renderers, add this API
to adapt slowly to this. The meta_backend_get_cursor_renderer() call
still exists, but shortcuts to the mouse pointer's renderer (as it
actually did before).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Use a new set in MetaInputDeviceNative, this coexists with
ClutterInputDevice coords for the time being. This API will
eventually be only accessed from the input thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This will query a device state; position and modifiers.
Note that ClutterSeat subclasses don't implement the vmethod yet,
so calling clutter_seat_query_state() may crash ATM.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
While multiple built-in panels isn't actually supported in any
meaningful manner, if we would ever end up with such a situation, e.g.
due to kernel bugs[0], we shouldn't crash when trying to set an
'external only' without any external monitors.
While we could handle this with more degraded functionality (e.g. don't
support the 'switch' method of monitor configuration at all), handle it
by simply not trying to switch to external-only when there are no,
according to the kernel, external monitors available. This would e.g.
still allow betwene 'mirror-all', and 'linear' switches.
The crash itself was disguised as an arbitrary X11 BadValue error, due
to mutter trying to resize the root window to 0x0, as the monitor
configuration that was applied consisted of zero logical monitors, thus
was effectively empty.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1896904
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1899260
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1607>
xkb recently gained support for user-specified keymaps, which means we
can no longer assume that the configuration data is necessarily fully
complete or correct; and the configuration language is quite a labyrinth,
so it's easy to get wrong. If setting the keymap fails, leave it in
whatever state it previously had, since that seems preferable to crashing
with a NULL pointer dereference.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/1555
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1605>
Testing points and rays against boxes is substantially cheaper - in
fact, almost trivial - compared to triangles. Check if the actor's
paint volume doesn't intersect with the current pick point / ray,
and skip recursing altogether in those cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1520>
The cached pick mode never actually cached anything, since it is
always, unconditionally reset when painting. Furthermore, next
commits will cull out actors during pick, which makes the pick
stack uncacheable.
Remove the cached pick mode.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1520>
It's currently possible that some last_paint_volumes don't get updated
during a paint cycle, this can happen when a ClutterOffscreenEffect is
used: The offscreen effect might skip painting the content and the
children of an actor because it uses its own offscreened texture
instead. This means the offscreen effect doesn't call
clutter_actor_continue_paint(), and thus the the last_paint_volumes of
the children won't be updated.
Now one might think that isn't a problem, because as soon as a child
changes it's size or position, the offscreened texture would get
invalidated and clutter_actor_continue_paint() would get called. It's
not that easy though: Because the last_paint_volume includes all the
transformation matrices up to eye-coordinates, it has to be updated on
any changes to matrices, which includes position/transformation changes
to any actor up the hierarchy.
Now that's where get into problems with the offscreen effect: In case of
transformation changes to the offscreened actor or an actor up the
hierarchy, the offscreened texture won't get invalidated (that makes
sense, we can simply paint it transformed) and the last_paint_volumes
won't get updated even though they should.
This leaves us around with outdated last_paint_volumes where
last_paint_volume_valid is still set to TRUE. It can cause issues with
culling and clipped redraws.
So fix that by ensuring that all children that would get painted by
Clutter get their last_paint_volumes updated in case a ClutterEffect
decided not to call clutter_actor_continue_paint().
This ignores the case where a paint() vfunc override does the same and
doesn't call clutter_actor_paint() on children. Let's ignore this case
for now, there shouldn't be any implementation which does that and
ideally in a world that's painted solely by ClutterContent, we can get
rid of that vfunc in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1591>
The first comment isn't really needed anymore since
the is_full_stage_redraw_queued() underneath is quite self-explaining.
Also rephrase the second comment a bit, including that
_clutter_paint_volume_get_stage_paint_box() does the aligning to the
pixel grid.
Finally, the last comment also looks out of date since we do that
rounding inside _clutter_paint_volume_get_stage_paint_box(), so remove
it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
We currently pass actors a reference to their associated
ClutterStageQueueRedrawEntry when queueing a redraw. This "splitting" of
the ownership of the entry has introduced quite a few bugs in the past
and is hard to follow.
So give up the "splitting" of the ownership and exclusively handle those
entries inside ClutterStage. To still allow removing the entry when an
actor gets unrealized introduce clutter_stage_dequeue_actor_redraw()
similar to what we already have for relayouts.
To be able to efficiently find entries when actors queue redraws, make
pending_queue_redraws a GHashTable, which fits quite nicely and also
allows removing the QueueRedrawEntries actor pointer in favour of the
key of the hashtable.
Since the struct is now private to ClutterStage, we can also rename it
to QueueRedrawEntry.
While at it, also sneak in the removal of the leading underscore from
clutter_stage_queue_actor_redraw().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
The "queue-redraw" signal is not used anywhere in Clutter and we now
also removed the vfunc implementation of the stage. So stop emitting it
and remove it, but keep the propagate_queue_redraw infrastructure to
make sure clones still get their redraws queued.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
Since we now decoupled the "queue-redraw" signal from creating the stage
clip, we can move signal emission into
_clutter_actor_queue_redraw_full() and emit the signal right away when
queueing a redraw on an actor. With that we now no longer have to
accommodate for the stage pending_queue_redraws list changing while
iterating over it.
To ensure we don't emit the signal too often when multiple redraws are
queued on one actor, use the propagated_one_redraw flag to limit the
number of emissions to a single one for every update cycle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
Putting together the redraw clip of the stage never really fitted nicely
with the "queue-redraw" signal emission, it forces us to emit the
signals in a batch and we also use a weird trick to get the old paint
volume that's already on-screen into the final redraw clip (we call
_clutter_actor_propagate_queue_redraw() on the stage).
So start breaking up this association by making the stage explicitely
request the redraw clip from the actor and removing the
ClutterPaintVolume argument from _clutter_actor_finish_queue_redraw().
This is done by adding a private function
clutter_actor_get_redraw_clip() which returns our old (currently
visible) paint volume and the new paint volume.
This also allows removing the check whether a full stage redraw has been
queued in clutter_actor_real_queue_redraw() and we can now just stop the
signal emission if a propagation happened at least once.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1511>
This adds 64 bit ARM support to parts of the CI pipeline, more
specifically, we now:
- Build a 64 bit ARM container image alongside the 64 bit x86 one.
- Build test mutter on 64 bit ARM
- Run tests on 64 bit ARM
- Check coverage on 64 bit ARM
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1577>
The most common case for Clutter is 2D axis-aligned actors, which
maintain these properties even after projecting to eye coordinates.
In those cases, we can use a simpler hit test by checking against
boxes.
Not only this is simpler, but this maintains an important aspect
of picking that is a requirement for Clutter: watertightness. Even
though the triangles checks do work on x86_64, they do not guarantee
watertightness. This breaks tests on ARM.
Use graphene_box_t to hit-test axis-aligned 2D actors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1599>
The image registry must be enabled for the CI to work, as the container
image from the upstream registry is placed (as a reference, more or
less) in the local registry.
Recently, ci-templates got a bit more helpful if this happened, and will
fail up front and generate a JUnit report with a message describing the
issue.
Update to this version.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1587>
clutter_actor_paint() implements a clear preference for custom clips
over clip_to_allocation: If a custom clip is set, clip_to_allocation is
ignored.
Since the paint volume reflects what Clutter is going to paint, we
should handle it the same when putting together our paint volume: So
first handle custom clips, and if one is set, use that. Then handle
clip_to_allocation, and if that's set, use that. And finally, if both
aren't set, union our allocation with the children paint volumes to get
the building volume.
clutter_actor_paint() also doesn't check whether the custom clip is
empty: If that's the case, it will simply not paint anything. Given that
that's allowed by clutter_actor_paint(), the paint volume should also
follow here and return an empty paint volume in case the custom clip is
empty.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1592>
When a custom clip is set for an actor, this actor is not going to allow
any painting outside that clip. That includes the children, which may
also not paint outside that clip.
Now in case clip_to_allocation is set to TRUE, we already already do the
right thing and simply use the allocation as our paint volume, ignoring
the volumes of our children. The same should be done for the custom
clip, so also stop the process of building the paint volume once we see
that a custom clip is set and simply use that clip.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1592>
In case we only have a single view (or there's only one view left to
check and the actor is visible on previous views) we can take a short-
cut, saving a region allocation and some calculations.
While on it, declare float numbers in '.f' style to make them more
recognizable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1596>
Commit 03c69ed8 ("Do not go past size hints on resize") was meant to
ensure the size hints set by the client would be honored during resize,
as going past those values could cause the window to move on resize.
However, it did so by calling ensure_size_hints_satisfied() which works
with the frame rect rather than the client rect. As a result, the
minimum size enforced would end up being larger than expected with
client-side decorations.
Use meta_window_maybe_apply_size_hints() instead which automatically
adjusts for client size.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1542
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1594>
It's the rules that guard the pipelines, deciding when they are allowed
to run or not. The 'only_default' comes from the fact that in the past
they set the only: field.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1588>
gnome-shell depends on gdm's client library at runtime, but the
new pipeline-built image no longer provides it.
Add it back, but built it from source instead of using the Fedora
package, so we don't draw in all of gdm's runtime dependencies
(which includes a full GNOME session including gnome-shell).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1590>
This allows profilers to trace the callers of whatever is spending the
most time on the GPU, and to measure render times more accurately.
Previously such information was hidden as it completed in the
background (asynchronously) after we call swap buffers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1327>
When using CLUTTER_DEBUG_PAINT_DAMAGE_REGION, the blue swap region is
always a superset of the red redraw region. So painting both in full (since
the previous commit) just meant the red region was overdrawn and came out
purple. That doesn't provide enough visual contrast, changes the user
experience unexpectedly and reduces performance.
So just subtract the redraw region from the swap region. This way the
red redraw region is always red, not purple.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1571>
Previously when CLUTTER_DEBUG_PAINT_DAMAGE_REGION was set, that would lead
to has_buffer_age==FALSE, which would lead to use_clipped_redraw==FALSE
which would mean swap_region was always empty. And so the blue region of
CLUTTER_DEBUG_PAINT_DAMAGE_REGION was always empty, *and* fb_clip_region
was always the full view rectangle which is not useful for debugging.
Now when CLUTTER_DEBUG_PAINT_DAMAGE_REGION is set, we don't let that
affect use_clipped_redraw, which means fb_clip_region is calculated
realistically.
But that's not enough. Calculating fb_clip_region properly with
CLUTTER_DEBUG_PAINT_DAMAGE_REGION would still lead to colouring artefacts
left on screen from previous frames that don't apply to the current frame.
So to fix that we also paint_stage for the whole screen every time when
using CLUTTER_DEBUG_PAINT_DAMAGE_REGION.
So now you will only ever see red and blue shading that's applicable to
the current frame, and no artefacts from the previous frames.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1535
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1571>
It was being painted without scaling and offsetting so would only look
right at scale 1.0 and only on the view with origin (0,0). Now we include
the framebuffer scale and view origin it will be painted in the correct
location.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1571>
ci-templates had a bug where it failed to find the ready-built container
images on the upstream repository due to invalid assumptions about the
relationship between upstream repository and image registry. This
resulted in the container image to be rebuilt, wasting valuable CPU
cycles and storage space. Bump the included ci-templates template to
include the fix for this.
See https://gitlab.freedesktop.org/freedesktop/ci-templates/-/issues/22.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1583>
only/except keywords where deperecated in favor of rules.
Since we started using GNOME/mutter!1525 it introduced
a second pipeline being run for each commit.
Detached pipelines are the only way to access CI_MERGE_REQUEST_*
variables, and if we disable normal pipelines you will need to
create wip/spam MRs in order to run the tests.
This reworked rules makes it so, the normal pipeline needs manual
interaction to be started, and the detached/MR pipleines is always
run.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1578>
Since we schedule frames for each stage view seperately now, surfaces receive
frame callbacks for each stage view they are visible on.
Only emit frame callbacks for the primary stage view.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
Our main use case of `is_obscured()` is frame callback emission.
Since we now support stage views running at differt speeds, we
need to know whether an actor is visible on a specific stage view
in order to schedule frame callbacks accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1468>
Commit e28c1ab4 added a hints_have_changed() function to only
recalculate windows features when the WM_NORMAL_HINTS change.
That function hints_have_changed() however was merely checking whether
the various XSizeHints flags where flipped, which is not sufficient
because the hints may remain the same while the actual values are
changed.
Not checking for the actual value differences would prevent some windows
from being able to switch fullscreen.
Improve the helper function hints_have_changed() to check not only for
flags being flipped, but also for the values being changed for each
relevant XSizeHints flags being set currently.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1534
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1566>
Sometimes the automatically selected primary GPU isn't suitable with no
way to make an well educated guess to do it better. To make it possible
for the user to override the automatically calculated default, make it
possible to override it using a udev rule.
E.g. to select /dev/dri/card1 as the primary GPU, add a file e.g.
/usr/lib/udev/rules.d/61-mutter-primary-gpu.rules (path my vary
depending on distribution) containing the fellowing line:
ENV{DEVNAME}=="/dev/dri/card1", TAG+="mutter-device-preferred-primary"
Reboot or manual triggering of udev rules to make it take effect may be
required.
Related: https://gitlab.gnome.org/GNOME/mutter/merge_requests/1057https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1562>
Instead of aborting with an error, display a half transparent gray
square instead of cursors and log a warning in the journal, allowing the
user to fix their system withotu having to rely on switching to a TTY.
It will be immediately obvious the cursor is silly looking, which will
be a better hint than just aborting.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1428
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1563>
If review fails, it'll fail very early in the pipeline, but we won't see
the test case failure until the whole pipeline succeeds, which might be
10 minutes later.
To avoid sitting there wondering why it failed, let the time consuming
jobs wait until the review stage, which tends to take less than 20
seconds, succeeds. This way the review test result will be presented
earlier.
This changes the pipeline to run the check-commit-log job also for
non-merge requests, with the difference being that it will pass
immediately if it's not a merge request.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1549>
Clutter is a "scope", so everything under should be its own
"sub-prefix", e.g. changes to ClutterActor should be prefixed
'clutter/actor', ClutterFrameClock with 'clutter/frame-clock',
CoglFramebuffer with 'cogl/framebuffer' etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1549>
It'd happen that the test runner would get CPU starved, and not see the
frame-clock changed notification before the timeline stopped. Decrease
the risk for this by moving the initial position of the actor having its
position transitioned to be closer to the view edge. This means the
frame clock will be changed earlier, increasing the chance of the
timeline not stopping before the relayout happens.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1555
For X11 grabs, the pattern matching mechanism would simply ignore
applications which have neither WM_CLASS nor WM_NAME set.
When dealing with an override redirect window however, it is not
uncommon that these window have neither value set as these window are
supposed to be ignored by the window manager.
When the WM_CLASS or the WM_NAME is not set by the client, assume the
value is empty so the pattern matching can allow for these.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1249
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1254>
Monitor tile info is possible to fetch when RANDR version 15 is exposed
by the X11 server. We had inverted the check meaning that only if older
versions were advertised would we attempt to init the tile information.
Fix this guard, thus fix monitor tiling on X11.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1524
As explained in https://gitlab.gnome.org/GNOME/mutter/-/issues/1494,
with commit 29caa5bea5 we stopped queueing
a relayout for the parent of the removed actor in
clutter_actor_remove_child_internal(). This relayout was, as opposed to
the relayout in clutter_actor_real_hide()/clutter_actor_real_unmap(),
queued unconditionally without looking at the parents NO_LAYOUT flag.
Now while that relayout in clutter_actor_remove_child_internal() would
do unnecessary work if the parent had the NO_LAYOUT flag set, it did
also queue a redraw of the parent, which is necessary in any case.
So by removing that relayout in clutter_actor_remove_child_internal(),
we stopped queueing redraws for NO_LAYOUT parents when a child gets
removed from the scenegraph. This caused bugs where the texture of the
child would be left visible on the screen even though the child got
destroyed.
To fix this, make sure again that we always queue a redraw on the parent
when unmapping a child.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1494
Not calling libinput dispatch in the backend constructor defeats the
logic in post init as the device added events have not been processed
yet.
So instead of trying to guess the cursor initial visibility, simply
update it along when devices get added.
Additional benefit, we do not need to walk the all device list looking
for touchscreens anymore, we just need to check the device being added
since the current logic is to hide the cursor as soon as a touchscreen
is found.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
At startup, libinput dispatch is called from the MetaSeatNative
constructed callback.
That means that we may get libinput events even before the default seat
is set.
In turn, processing those events may trigger the use the default seat
while it's still not set yet, and cause a crash of gnome-shell/mutter
at startup.
A simple reproducer for this is to start gnome-shell/mutter with a
tablet connected and the stylus in proximity, the proximity event will
cause gnome-shell/mutter to crash at startup.
To avoid that issue, avoid dispatching libinput events early from the
MetaSeatNative constructed callback, those events will eventually get
processed when the seat and the backend are all setup.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1501https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1534
Commit 8bdd2aa7 would offset the window position by the difference
between the configured window size and the committed size from the
client to prevent the window from drifting while resizing.
This, however, did not take into account the actual geometry scale, so
when using any scale greater than 1, the window would rapidly drift away
due to that offset.
In order to solve this, we need to make sure we store away the pending
window configuration in the stage coordinate space, in order to not
loose precision. When we then calculate the offset given the result from
the client, it'll use the right scalars, while before, one scalar was in
surface coordinates, while the other in stage coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1490
We're just a "ninja coverage" away from getting the full report,
it is not that much extra to the pipeline. Also, fix bugs that
accumulated since the manual task was added, e.g. let the full
built+tested tree available on the coverity stage.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1535
We want the bounding box so `ceilf` seems more appropriate. It was
only written using `roundf` before as a workaround for inaccuracies
coming out of `clutter_actor_get_transformed_size` that would have
tricked `ceilf` into landing on the wrong integer. But that's since
been fixed by 67cc60cbda so we can use `ceilf` now.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1532
Otherwise we might run into a use-after-free and crash on (virtual)
device removal:
Invalid read of size 8
at clutter_input_device_get_device_type (clutter-input-device.c:811)
by update_last_device (meta-backend.c:1282)
by g_main_dispatch (gmain.c:3325)
by g_main_context_dispatch (gmain.c:4016)
by g_main_context_iterate.constprop.0 (gmain.c:4092)
by g_main_loop_run (gmain.c:4290)
by meta_run_main_loop (main.c:708)
by meta_run (main.c:723)
by main (main.c:550)
Address is 32 bytes inside a block of size 504 free'd
at free (vg_replace_malloc.c:538)
by g_type_free_instance (gtype.c:1939)
by clutter_event_free (clutter-event.c:1420)
by _clutter_stage_process_queued_events (clutter-stage.c:830)
by handle_frame_clock_before_frame (clutter-stage-view.c:1064)
by clutter_frame_clock_dispatch (clutter-frame-clock.c:405)
by frame_clock_source_dispatch (clutter-frame-clock.c:456)
by g_main_dispatch (gmain.c:3325)
by g_main_context_dispatch (gmain.c:4016)
by g_main_context_iterate.constprop.0 (gmain.c:4092)
by g_main_loop_run (gmain.c:4290)
by meta_run_main_loop (main.c:708)
by meta_run (main.c:723)
Block was alloc'd at
at malloc (vg_replace_malloc.c:307)
by g_malloc (gmem.c:106)
by g_slice_alloc (gslice.c:1025)
by g_slice_alloc0 (gslice.c:1051)
by g_type_create_instance (gtype.c:1839)
by g_object_new_internal (gobject.c:1939)
by g_object_new_valist (gobject.c:2264)
by g_object_new (gobject.c:1782)
by meta_input_device_native_new_virtual (meta-input-device-native.c:1365)
by meta_virtual_input_device_native_constructed (meta-virtual-input-device-native.c:705)
by g_object_new_internal (gobject.c:1979)
by g_object_new_valist (gobject.c:2264)
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1529
The redraw_pending boolean is used to schedule the first stage update
after starting Clutter. This flag is superfluous because we have the
pending_finish_queue_redraws flag which does the same.
While at it, also remove the redraw_count debug variable, since there
should be better ways to count the number of queued redraws nowadays,
for example Sysprof marks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
Queueing a redraw with a clip is easy enough and this function is
private anyway, so remove it and call _clutter_actor_queue_redraw_full()
instead in the one function using it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
ClutterRedrawFlags are a way to give Clutter additional context
about what it needs to redraw. There currently is only one flag defined,
CLUTTER_REDRAW_CLIPPED_TO_ALLOCATION, this flag would clip the redraw to
the actors current allocation.
Since ClutterActor also provides the clip_to_allocation property (which
affects the paint volume of the actor instead of only one redraw), the
additional CLIPPED_TO_ALLOCATION flag seems unnecessary. It's also only
defined to be used privately in Clutter, which it never is, so let's
remove it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1527
Turns out the g_signal_has_handler_pending() call in
update_stage_views() is actually more expensive than comparing the
sorted list (which is usually very short), so remove that and simply
always emit the signal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1524
This commit introduces a few important changes in order to
acommodate graphene_ray_t. Most of them are positive changes,
so don't panic :)
The first very visible change is that neither the actor box
nor the clip rectangles are projected before being pushed.
This required changing the parameters of the related functions
at both ClutterPickContext, and ClutterPickStack, to receive
boxes instead of vertices. These rectangles are projected on
demand now, so in the best case (first actor picked) only
one projection happens; and in the worst case, it projects
as much as it does now.
The second important change is that there are no more checks
for axis-alignment anymore. That's because picking now happens
in 3D space, using triangles.
Talking about triangles in 3D space, this is what is used now
for picking. We break down each actor rectangle in 2 triangles,
and check if the projected pick point is inside any one of them,
of if the ray intersects any one of them. The same check happens
for the clip rectangles.
Checking the projected pick point is both an optimization for the
2D case, and a workaround to graphene_ray_t problems with float
precision, which is specially visible on edges such as the top
bar.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
ClutterPickStack is a new boxed type that stores the vertices
and clip rectangles. It is meant to be a byproduct of picking,
and takes over most of what ClutterStage currently does.
It introduces a 'seal' system, inspired by MetaKmsUpdate. After
the pick operation is done, and the rectangles are collected,
the pick stack is sealed, and is not allowed to be externally
modified anymore. Internally, it still can invalidate pick
records when an actor is destroyed.
For now, it handles both the clip rectangles, and the matrix
stack, separatedly. Future commits will rearrange this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1509
Because clones may not have identical geometry to their source actors.
So we can't use the geometry of the source actor to decide to take the
more optimized (more clipped) path.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1480
The "paint" signal of ClutterActor has been a pain for everyone involved
long enough now, turns out we actually use it nowhere except tests
anymore (which has been handled in the last commits), so get rid of it
for good before anyone starts using it again.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1522
The "paint" signal of ClutterActor is deprecated and will be removed. We
have a good replacement to get notified about stage paints nowadays,
that is "after-paint" on ClutterStage, so switch to that signal where it
makes sense.
I didn't bother to update the few tests (namely Clutters
conform/texture-fbo.c, conform/text-cache.c,
interactive/test-cogl-multitexture.c and Cogls
conform/test-multitexture.c, conform/test-texture-mipmaps.c) where it's
harder to replace the signal since we don't build those anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1522
The paint-wrapper test wraps around the painting process of an actor to
paint its own texture before and after painting, it does that using the
"paint" signal.
This signal is deprecated and will be removed from Clutter, and since
this "use-case" won't be supported anymore afterwards (the proper way is
to use a ClutterEffect for things like this), remove the test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1522
Rely on the seat stage, or other ways to fetch it. Also rely that
there is actually a single stage, so that we assign the right stage
to all events going out of the seat, in a single place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
Make the upper part agnostic about the device being relative in order
to avoid applying keep-aspect. The X11 bits already are, so make it
sure it's also the case for the native backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
The semantics for libinput events are not as expected here. Besides
it's pointless, as those should arrive per-slot in a burst, and we
cancel on the first event.
We can simply use the Clutter event for this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
As it does seem from a read to libinput code, TOUCH_CANCEL events
actually do contain slot information, and are emitted per-slot.
This means we can avoid iterating over the slots ourselves, they
are still expected to be sent altogether.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
We want to coalesce multiple touch events into the same wl_touch.frame
event. Instead of poking internals to peek the touch events (and their
slots) coming at us before we handle them, simplify things by queueing
the event at a slightly lower priority than events, so we are ensured
to handle all pending input events before sending the event.
If there's no pending events, we can just send the frame event. As it
doesn't make sense to hold any longer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1486
When malformed modes are provided and no valid mode spec is found, mutter
will eventually try to access the last element of an empty list. Warn about
this and exit properly.
https://gitlab.gnome.org/GNOME/mutter/-/issues/1481
We will use a dedicated variable when transitioning to/from fullscreen state
and leave the previously used 'saved_rect' exclusively for transitioning
between floating and maximized state.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/801
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
Since commit eb9cd3857d we initialize the allocation of ClutterActors to
an UNINITIALIZED ClutterActorBox. We do that to ensure the actor even
emits notify::allocation in case it got a new valid allocation of
0,0,0,0.
Now there's still the case where an actor gets removed from the
scenegraph and added again to a different parent, in this case we still
don't emit notify::allocation right now in case the new allocation
equals the old one. There's two good reasons to do so though:
1) To Clutter, there's no difference between a newly created actor and
an actor which got removed from the scenegraph, it's not consistent to
always notify the allocation property in the former situation, but not
always notify it in the latter situation.
2) When an allocation changes, Clutter notifies the subtree of that
actor about an absolute geometry change (see the call to
transform_changed() in clutter_actor_set_allocation_internal()). Now
when an actor gets reparented, obviously the absolute geometry might
change, so to make sure transform_changed() is always called in that
case we need to make sure an allocation change happens.
So simply reset the allocation property of the actor to an UNINITIALIZED
ClutterActorBox as soon as it gets unrealized.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1498
We introduced the absolute_origin_changed flag when preparing for the
removal of ClutterAllocationFlags in commit dc8e5c7f8b. Turns out in the
mean-time commit df4eeff6f2 happened, which renders the whole
absolute_origin_changed flag moot.
That's because we now notify the whole subtree about the absolute origin
change by calling transform_changed() when the allocation of an actor
changes. transform_changed() traverses the subtree and calls
absolute_geometry_changed() on every actor immediately, which renders
the whole propagation of the absolute_origin_changed flag obsolete.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1498
Since we now moved the queuing of relayouts into the mapping and
unmapping functions, we no longer need to do it when adding or removing
a child, that's because removing a child always unmaps the child, and
adding it to a stage (if it's visible) will map it.
So remove those calls to queue_relayout() since they're no longer
needed.
With the above we no longer queue a relayout in
clutter_actor_add_child_internal(), that means there's one place where
we need to explicitely queue relayouts now: That's when using the
set_child_at_index/above/below() APIs, those are special because they
avoid unmapping and mapping of actors and would now no longer get a
relayout.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
In theory there's no big difference between only handling mapped actors
vs only handling visible actors in clutter_actor_allocate(): The
function is called recursively starting with an actor that is attached
to a stage, so it should only be called on mapped actors anyway.
The behavior of skipping hidden actors was introduced as an optimization
with commit 0eab73dc. Since the last commit, we handle
enable_paint_unmapped a bit better and don't do unnecessary work when
mapping or unmapping, so we can now be a bit stricter enforcing our
invariants and only allow mapped actors in clutter_actor_allocate().
We need to exclude toplevel actors from this check since the stage has a
very different mapped state than normal actors, depending on the
mappedness of the x11 window. Also we need to make an exception for
clones (of course...): Those need their source actor to have an
allocation, which means they might try to force-allocate it, and in that
case we shouldn't bail out of clutter_actor_allocate().
Also moving the clutter_actor_queue_relayout() call from
clutter_actor_real_show() to clutter_actor_real_map() seems to fix a bug
where we don't queue redraws/relayouts on children when a parent gets
shown.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2973https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
We currently support only one case where an actor can get mapped or
unmapped during painting, that is using
_clutter_actor_enable_paint_unmapped() (although we could arguably do a
better job explicitely forbidding it in other cases). This function is
called when painting ClutterClone or MetaWindowActors during
screensharing. It temporarily (fake) realizes and maps the actor and all
its children so it can get painted.
Now a problem will appear when we'll start coupling layout and the
mapped state of actors more closely with the next commit: Since
enable_paint_unmapped() is meant to be enabled and disabled during every
clone paint, we also notify the "mapped" property twice on every clone
paint. That means with the next commit we would queue a relayout for the
source actor on every clone paint.
To avoid this unnecessary work, check whether we're being painted while
unmapped using the new unmapped_paint_branch_counter. Then avoid queuing
relayouts or invalidating paint volumes in that case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
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
Add new private API to ClutterActor, returning TRUE in case the actor is
being painted while unmapped. This is useful for implementations of the
paint() vfunc or for signal handlers of the "notify::mapped" signal.
Use this API in CallyActor to properly detect "notify::mapped" emissions
while painting unmapped, this fixes detecting the case where
painting-unmapped is used for screencasting.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Just like the existing in_cloned_branch counter, add a property which
tracks whether the actor is part of a subtree that's being painted while
unmapped. This is going to be useful for a few things, for example
changing the clutter_actor_is_in_clone_paint() API to use
enable_paint_unmapped instead of in_clone_paint.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
clutter_actor_queue_relayout() detects whether a parent has the
NO_LAYOUT flag set by itself and then queues a shallow relayout for us.
There's no need to duplicate that logic when showing actors, so simply
call clutter_actor_queue_relayout() and let that handle it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1366
Apparently clutter_paint_volume_union() has problems building the union
of two paint volumes in eye coordinates, that's probably because of the
negative coordinates that come into play there.
Circumvent that by making even more use of Graphene and letting it take
care of computing the union. We do that by creating two graphene_box_t's
from the axis-aligned paint volumes and intersecting those boxes, then
setting our vertices to the new min and max points of the resulting box.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1507
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
Add a helper function to determine if a seat has a (physical)
touchscreen associated with it.
Currently src/backends/meta-backend.c has a private version of this
(check_has_physical_touchscreen) and further patches in this patch-set
need the same functionality. So add a generic helper for this to
avoid code duplication.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1506
_cogl_util_get_eye_planes_for_screen_poly() is quite a complicated beast. Ever
since Clutter became a compositor toolkit, and specially after we switched to
graphene_frustum_t on paint volumes, we can brutally simplify this function.
The new code assumes camera is at (0, 0, 0) at world coordinates (i.e. before
applying the projection). We also consider that the redraw clip are at stage
coordinates. That means that converting the clip rectangle to world rectangle
is simply a matter of projecting the corresponding vertices using the "view"
matrix. Furthermore, we only need to project the top-left, and bottom-right
vertices, since top-right and bottom-left can be derived from those two.
The frustum setup still uses triplets of vertices to setup the planes, except
now the first vertex is always the camera (hardcoded to 0, 0, 0), and the other
two vertices are the projected clip rectangle vertices.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
The redraw clip region may contain multiple clip rectangles. We currently
only use the extents of this region, but having multiple frusta for each
rectangle is a better alternative, and will allow us to remove the extra
projection we currently do.
Make the clip frustum an array, with multiple frusta.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
The clip planes / frustum are contextual to painting. In the past, for
the lack of a better place, it was added to ClutterStage, but now we
have an appropriate home for such data: ClutterPaintContext.
Move the frustum to the paint context.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
While refactoring the clipping planes / frustum code, it became more and
more evident that we do not need to update them while picking. Picking
nowadays goes through a completely different code path, that does not
rely on paint volume culling.
While it might be interesting to eventually also cull out based on paint
volumes, it certainly won't go through the painting code anymore.
Remove setting up the view when picking, and rename functions appropriatedly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Culling paint volumes don't give this level of detail anymore, and in
fact knowing whether it was partially or fully in was only being used
in a debug path. For the purposes of culling, it doesn't matter if a
given actor is partially or completely inside the frustum; either way,
it must be painted.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Instead of 4 planes, use a graphene_frustum_t to store the clipping
planes.
The cautious reviewer might noticed that we are now setting up 6
planes: the 4 planes we were doing before, plus 2 extra planes in
the Z axis. These extra planes simulate an "infinite" Z far, and
an "on-camera" Z near.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
ClutterStage defines the 8 vertices of a frustum:
4 ----------------------------- 5
| \ / |
| \ / |
| 0 --------------------- 1 |
| | | |
| | | |
| 3 --------------------- 2 |
| / \ |
| / \ |
7 ----------------------------- 6
Then, it uses triplets of vertices to create each clipping plane.
It only sets up 4 planes (it doesn't clip based on depth), defined
by the following vertices:
* 0 - 4 - 5
* 1 - 5 - 6
* 2 - 6 - 7
* 0 - 7 - 4
The first 3 triplets are selected using the for-loop. However, the
last triplet is different, and is done out of the loop. It could
have been made simpler by using the "3 - 7 - 4" triplet.
Simplify the current code by using the suggested triplet, calculated
inside the for-loop.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Instead of our own implementation that upscales, then downscales back,
use graphene_matrix_inverse() directly. This is possible after switching
to a z-near value that doesn't have problems with float precision.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
Picking is specially sensitive for float precision, and tests can
easily fail when something changes, even if ever so slightly. A
simple way to workaround this is by adjusting the projected points
using the same procedure described at 67cc60cbda.
Round projected points for picking to 256ths.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1489
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 first argument is the framebuffer operated on, so in order to stay
consistest, rename 'src' to 'framebuffer'. The second is the
destination. The destination is commonly referred to as 'dst' elsewhere,
so rename 'dest' to 'dst'.
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
Fedora's mutter is built with --auto-features=enabled which enables
-initfd support. But the current meson code doesn't check whether
-initfd is available in Xwayland, leading to the wayland session not
starting up.
Check for -initfd's availability before enabling it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1103
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
Keeping track of the projected position is costly, and adds quite some complexity
to ClutterOffscreenEffect.pre_paint(). As far as research goes, there's not a
single consumer of this function that uses the position for anything - only size
is used.
Remove clutter_offscreen_effect_get_target_rect(), and drop the annoying position
field from ClutterOffscreenEffect as well. This allows us to stop projecting the
position on pre-paint, and simplify things.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1474
ClutterPipelineNode will be used by GNOME Shell in the future.
Fortunately for us, CoglPipeline is already usable from GJS,
so we don't need to skip the constructor for the pipeline node.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1474
Move unreffing the framebuffer to ClutterOffscreenEffect.pre_paint().
This will allow us to properly chain up ClutterOffscreenEffect.paint()
and not reimplement exactly what ClutterEffect does by default.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1474
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
This one is a bit tricky. The tl;dr; is that switching from right-hand
multiplication to left-hand multiplication required applying the stack
from left to root. This actually allowed simplifying the code a bit,
since CoglMatrixEntry only stores a pointer to its parent, and that's
all we need to know for left-hand multiplication.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
In this case, since we are building the entire matrix by ourselves,
reverse the order of operations (translate + scale → scale + translate)
and build it using graphene-specific APIs.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
This is another instance of graphene reversing the order of operations (see
the commit notes of how ClutterActor was ported.) The tl;dr; here is that,
in the CoglMatrix past, we used to do:
(actor transforms) → scale
and now, it's the other way round:
scale → (actor transforms)
due to changing from right-handed multiplications (CoglMatrix) to left-handed
ones (graphene_matrix_t).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
ClutterActor is a particularly heavy user of matrices, and
switching to graphene_matrix_* APIs means we had to change
the order of operations due to left-hand vs right-hand
differences.
When applying the actor transform, there are 2 main branches
that can be followed: the default transforms, and when a
custom transform is set.
To facilitate review, here's the table that I've made to
guide myself:
+--------------- Case 1: Default Transforms --------------+
| CoglMatrix | graphene_matrix_t |
+----------------------------+----------------------------+
| multiply (child transform) | translate (-pivot) |
| translate (allocation)¹ | rotate_x (angle) |
| translate (pivot)¹ | rotate_y (angle) |
| translate (translation)¹ | rotate_z (angle) |
| scale (sx, sy, sz) | scale (sx, sy, sz) |
| rotate_z (angle) | translate (translation)¹ |
| rotate_y (angle) | translate (pivot)¹ |
| rotate_x (angle) | translate (allocation)¹ |
| translate (-pivot) | multiply (child transform) |
+----------------------------+----------------------------+
¹ - these 3 translations are simplified as a single call
to translate(allocation + pivot + translation)
+---------------- Case 2: Custom Transform ---------------+
| CoglMatrix | graphene_matrix_t |
+----------------------------+----------------------------+
| multiply (child transform) | translate (-pivot) |
| translate (allocation)² | multiply (transform) |
| translate (pivot)² | translate (pivot)² |
| multiply (transform) | translate (allocation)² |
| translate (-pivot) | multiply (child transform) |
+----------------------------+----------------------------+
² - likewise, these 2 translations are simplified as a
single call to translate(allocation + pivot)
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
Given that CoglMatrix is simply a typedef to graphene_matrix_t, we can
remove all the GType machinery and reuse Graphene's.
Also remove the clutter-cogl helper, and cogl_matrix_to_graphene_matrix()
which is now unused.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
After the previous commit, the only field in the CoglMatrix structure is
a graphene_matrix_t. That means that CoglMatrix is effectively a graphene
matrix now, and the CoglMatrix struct isn't that much useful anymore.
Remove the CoglMatrix structure and make the CoglMatrix type a typedef to
graphene_matrix_t.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Remove the cached inverse, and dirty flags, and typedef CoglMatrix to
graphene_matrix_t itself. I preverved the type for this commit to help
reducing the commit size, next commits will remove the CoglMatrix type.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
It turns it to be quite easy to inverse the transform, and doing that
on ClutterActor level means we can actually think about removing
CoglMatrix entirely and using graphene_matrix_t everywhere.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
CoglMatrix doesn't have a 1:1 mapping of graphene functions, and
sometimes it's just not worth adding wrappers over it. It is easier
to expose the internal graphene_matrix_t and let callers use it
directly.
Add new cogl_matrix_get_graphene_matrix() helper function, and
simplify Clutter's matrix progress function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Instead of listing all matrix cells as floats, and the inverse
as a 16-length float array, use graphene_matrix_t in the structure
itself.
With this commit, all from/to CoglMatrix conversions are gone. It
is also not possible to initialize a CoglMatrix using the macro
anymore.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Rename cogl_matrix_get_array() to cogl_matrix_to_float(), and
make it copy the floats to an out argument instead of returning
a pointer to the casted CoglMatrix struct.
The naming change is specifically made to match graphene's,
and ease the transition.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Internally, a graphene_matrix_t representing the same transform that
of a CoglMatrix is the same matrix but transposed, so in order to get
the same element given a column and row for a matrix as if it would
be located in Cogl, it is necessary to swap the row and column when
retrieving it from the graphene matrix.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Turns out inverting a matrix was the largest chunk of the CoglMatrix
code. By switching to Graphene, a lot of it can go away. The inverse
is still cached in the CoglMatrix struct itself, to preserve the
optimization.
However, switching to graphene_matrix_t to calculate the inverse has
a challenge: float precision. We had to work around it here, and it
needs an explanation.
The way to detect whether a matrix is invertible or not (i.e.
whether it's not a "singular" matrix, or not) is by checking
if the determinant equals 0. So far, so good.
Both graphene_matrix_t and CoglMatrix use single-precision
floats to store their 4x4 matrices. Graphene uses vectorized
operations to optimize determinant calculation, while Cogl
tries to keep track of the matrix type and has special-purpose
determinant functions for different matrix types (the most
common one being a 3D matrix).
Cogl, however, has a fundamentally flawed check for whether
the matrix is invertible or not. Have a look:
```
float det;
…
if (det*det < 1e-25)
return FALSE;
```
Notice that 1e-25 is *way* smaller than FLT_EPSILON. This
check is fundamentally flawed.
"In practice, what does it break?", the reader might ask.
Well, in this case, the answer is opposite of that: Cogl
inverts matrices that should not be invertible. Let's see
an example: the model-view-projection of a 4K monitor. It
looks like this:
```
| +0,002693 +0,000000 +0,000000 +0,000000 |
| +0,000000 -0,002693 +0,000000 +0,000000 |
| +0,000000 +0,000000 +0,002693 +0,000000 |
| -5,169809 +2,908017 -5,036834 +1,000000 |
```
The determinant of this matrix is -0.000000019530306557.
It evidently is smaller than FLT_EPSILON. In this situation,
Cogl would happily calculate the inverse matrix, whereas
Graphene (correctly) bails out and thinks it's a singular
matrix.
This commit works around that by exploiting the maths around
it. The basis of it is:
inverse(scalar * M) = (1/scalar) * M'
which can be extrapolated to:
inverse(M) = scalar * inverse(scalar * M) = M'
In other words, scaling the to-be-inversed matrix, then
scaling the inverse matrix by the same factor, gives us
the desired inverse. In this commit, the scale is calculated
as 1 / (smallest value in the diagonal).
I'm sorry for everyone that has to read through this :(
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Next commits, and this patchset in general, will make this patchset
obsolete, since it'll only test graphene types against each other.
If at all useful, the Euler test should be moved to graphene.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Use dot products to simplify calculations. Because the 'w' column of
the matrix is always summed, use 1.f in the 'w' component of the point
vector.
Because CoglMatrix is column-major and graphene_matrix_t is row-major,
it is necessary to transpose the matrix before retrieving the rows.
When we switch CoglMatrix to be row-major, this transposition will
go away.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
This is pretty similar to the other conversions, except we need to
store the matrix flags before operating on it, and update it using
this old value after. That's because cogl_matrix_init_from_array()
marks the matrix as entirely dirty, and we don't want that.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
At this point, we are still only changing CoglMatrix APIs internally, and
it should still produce the same output as before.
To achieve this, using graphens matrix implementation, we need to exploit
some knowledge about conventions used in Cogl and graphene respectively.
In Cogl, transformation matrices are equivalent to those of affine
transformation matrices. The convention used by graphene, however, is to
operate on matrices that are transposed compared to their affine
counterparts.
So for example, let's say we want to multiply the affine matrices A and B,
to get C.
A × B = C
The first step is to convert A and B to graphene matrices. We do this by
importing the floating point array, importing it directly using graphene.
Cogl exports its matrix to a column major floating point array. When we
import this in graphene, being row major, we end up with the same matrix,
only transposed.
Cogl Graphene
A <===> Aᵀ
B <===> Bᵀ
We then multiply these imported matrices in reverse
Bᵀ × Aᵀ
which in turn, due to ABᵀ = BᵀAᵀ, gives us
Bᵀ × Aᵀ = (A × B)ᵀ
Our original goal was to find C, thus we know that
A × B = C
That means we can shuffle things around a bit.
A × B = C
Bᵀ × Aᵀ = (A × B)ᵀ
Bᵀ × Aᵀ = Cᵀ
With the same conversion as done when going from Cogl to graphene, only
the other way around, we still end up effectively transposing the matrix
during the conversion.
Graphene Cogl
Cᵀ <===> C
Thus when converting Cᵀ to Cogl, we in fact end up with C.
(Explanation authored by Jonas Ådahl)
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1439
Graphene provides skewing as part of graphene_matrix_t API, and it'll
be easier for the transition to just expose similar API surfaces.
Move the matrix skew methods to CoglMatrix.
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
Writing tests' output to a log file makes them difficult to debug when
the test might be running on an autobuilder or CI system where only
stdout/stderr are recorded. This is particularly troublesome if a
failure is only reproducible on a particular autobuilder.
Recent Automake versions have the convention that detailed output from
failing tests is written to stdout/stderr, not just to log files, when
the VERBOSE environment variable is set; borrow that convention as a
trigger for producing detailed test output.
This was originally cogl!14, but applies equally to mutter's fork of cogl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1273
Signed-off-by: Simon McVittie <smcv@debian.org>
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
This resolves a couple of FIXMEs. The FIXME comments were right in
stating that not *all* journals needed flushing, only the one we
are trying to put on screen needs flushing.
However we can't eliminate all flushes because the winsys swap calls
that follow go directly into OpenGL which knows nothing about cogl
journalling. So the journal *must* be flushed before the swap, to give
OpenGL the correct state.
P.S. If this turns out to cause any bugs then the next best answer is
to just remove the FIXME comments. Because flushing is still the right
thing to do.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1362
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
We already correctly set the font-dpi based on user settings in
MetaSettings at each user change and as part of backend initialization,
so there's no point to set it also during x11 backend post-parsing and
using X11 values, as this may happen at later point and lead to a wrong
clutter font DPI value.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1444
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
When the CoglRenderer didn't set the DMA buffer constructor vfunc, we
return NULL. What we didn't do was set the error, meaning the caller
would crash if it tried to look up why DMA buffer construction failed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1430
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
It'll allow subclasses to get notified of the before-paint
signal without having to connect to it. This will allow
MetaStage to have proper watches being fired there without
the cost of the signal handling machinery.
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
In certain situations it's desirable to keep pipelines around for
the whole lifetime of the session. In order to not leak them and
properly clean them up on shutdown, introduce a new mechanism to
create named pipelines that are bound to their correstponding
context and may be used across file boundries.
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
These are not given directly to the input focus anymore, instead
queued up as events. This way, all actions triggered by the input
method (commit and preedit buffer ones, but also synthesized key
events) queue up the same way, and are thus processed in the exact
same order than they are given to us.
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
Previously we only culled actors that didn't intersect the bounding box
of the redraw clip. Now we also cull those whose paint volume bounds don't
intersect the arbitrary shape of the redraw clip.
This was inspired by the activities overview where idle windows and
workspace previews were being needlessly repainted. In that particular
case this yields more than 10% reduction in render time. But it probably
helps in other situations too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1359
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
Clutter device events are special events coming from the backend when an
input device is added or removed.
When such events are processed, we should make the seat to handle them by
calling vfunc that can be implemented by each backend and eventually
emitting the appropriate signal.
If a device is removed, we can also safely dispose it, as it can be
considered stale at this point.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
Add clutter device added and removed events to allow processing of them as
it happens in the backends, queuing them and performing actions in order.
This allows not to loose any event that is performed just before removing or
disabling a device, and still process the events in order in the event
queue.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1371
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
This was from the old clutter-as-application-library days, where it had
to try find a suitable backend. Now we already have a backend selected
(MetaBackend), and the clutter backend is already predecided depending
on that, so we don't need the code that auto detects an appropriate one
anymore.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1364
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
There is no reason to use Xsettings for the X11 backend, as it comes
from the GSetting store anyway, so move the font setting reading to
ClutterSettings and read directly from GSettings.
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
When we pick the frame clock given the associated actor, that frame
clock in fact comes from a picked actor. In order to not end up with
stale frame clocks, which may happen on e.g. hotplugs, monitor layout
changes, or non-optimal frame clocks, which may happen when the parent
used for picking the clock moves to another view, lets listen to
'stage-views-changed' on the actor used for picking the clock too.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1327https://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
Let's not expose that outside of mutter quite yet; it's not used in
gnome-shell, and to avoid future breakage if it starts to be used, lets
move it to clutter-mutter.h so only mutter and clutter itself can use
it.
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
In order to run gnome-shell as part of the CI pipeline, we need
an additional runtime dependency plus python3 modules to mock
required system services and run gnome-shell-perf-tool.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1401
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
In order to support the DRM formats DRM_FORMAT_ABGR16161616F and
friends, as well as the wl_shm formats WL_SHM_FORMAT_ABGR16161616F and
friends, cogl needs to have knowledge about said formats too.
We don't have a software implementation of the half point data types
however, so the pack/unpack methods remain unimplemented. We don't need
them for now, so it's not crucial that we add them.
For the GLES2 driver, currently only two formats are supported, and
since we don't currently have pack/unpack implementations, the other
formats will for now remain unsupported, until we have a half float
implementation.
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
The clutter_actor_get_transformed_position returns the position of the
top left point of the actor, with the actor transformations. That means
that if the actor is rotated 180º it'll return the "screen" position top
right.
Using this to calculate if the actor is in the screen is causing
problems when it's transformted.
This patch adds a new function clutter_actor_get_transformed_extents,
that will return the transformed actor bounding rect.
This new function is used on the update_stage_views so the actor will
get updated. this way rotated actors will be updated if they are on the
screen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1386
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
Make clutter_actor_allocate_preferred_size() convenient to use from
layout managers by not "automatically" honouring the fixed position of
the actor, but instead allowing to pass a position to allocate the
actor at.
This way we can move the handling of fixed positions to
ClutterFixedLayout, the layout manager which is responsible for
allocating actors using fixed positions.
This also makes clutter_actor_allocate_preferred_size() more similar to
clutter_actor_allocate_available_size().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1310
It's currently a bit hard to get the fixed position of an actor. It can
be either done by using g_object_get() with the "fixed-x"/"fixed-y"
properties or by calling clutter_actor_get_position().
Calling clutter_actor_get_position() can return the fixed position, but
it might also return the allocated position if the allocation is valid.
The latter is not the best behavior when querying the fixed position
during an allocation, so introduce a new function
clutter_actor_get_fixed_position() which always gets the fixed position
and returns FALSE in case no fixed position is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1310
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
In the case of indirect rendering like the first frame to use mutter's
background wallpaper:
Texture_A -> FBO_B (Texture_B) -> FBO_C (screen)
we would be trying to render the contents of both FBO_B and FBO_C in
the same flush, before the contents of Texture_A had made it to FBO_B.
So when FBO_C wants to use mipmaps of Texture_B they didn't exist yet
and appeared all black. And the blackness would remain for subsequent
frames as cogl has now decided the mipmaps of FBO_B are no longer
"dirty" and don't need refreshing:
FBO_B (Texture_B) (mipmaps_dirty==FALSE but black) -> FBO_C (screen)
We must flush FBO_B before referencing Texture_B for use in rendering
FBO_C. This only happens when Texture_A changes (e.g. when the user
changes their background wallpaper) so there's no ongoing performance
penalty from this flush.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1347
With the introduction of the shallow relayout mechanism another small
but severe regression sneaked into our layout machinery: We might
allocate an actor twice during the same allocation cycle, with one
allocation happening using the wrong parent.
This issue happens when reparenting an actor from a NO_LAYOUT parent to
a non-NO_LAYOUT parent, in particular it triggered a bug in gnome-shell
when DND reparents a child from the NO_LAYOUT uiGroup to the overviews
Workspace actor after a drag ended. The reason the issue happens is the
following chain of events:
1. child of a NO_LAYOUT parent queues a relayout, this child is added to
the priv->pending_relayouts list maintained by ClutterStage
2. child is reparented to a different parent which doesn't have the
NO_LAYOUT flag set, another relayout is queued, this time a different
actor is added to the priv->pending_relayouts list
3. the relayout happens and we go through the pending_relayouts list
backwards, that means the correct relayout queued during 2. happens
first, then the old one happens and we simply call
clutter_actor_allocate_preferred_size() on the actor, that allocation
overrides the other, correct one.
So fix that issue by adding a method to ClutterStage which removes
actors from the pending_relayouts list again and call this method as
soon as an actor with a NO_LAYOUT parent is detached from the stage.
With that in place, we can also remove the check whether an actor is
still on stage while looping through pending_relayouts. In case
something else is going wrong and the actor is not on stage,
clutter_actor_allocate() will warn anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1356
When picking which frame clock to use, we traverse up in the actor
hierarchy until a suitable frame clock is found. ClutterTimeline
also listens to the 'stage-views-changed' to make sure it's always
attached to the correct frame clock.
However, there is one special situation where neither of them would
work: when the stage doesn't have a frame clock yet, and the actor
of the timeline is outside any stage view. When that happens, the
returned frame clock is NULL, and 'stage-views-changed' is never
emitted by the actor.
Monitor the stage for stage view changes when the frame clock is
NULL.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
An actor may be placed without being on any current stage view; in this
case, to get the ball rolling, walk up the actor tree to find the first
actor where a frame clock can be picked from.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
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
Right now the stage only had a signal called 'after-paint' which was not
tied to painting but updating. Change this to offer 4 signals, for the 4
different stages:
* before-update - emitted in the beginning before the actual stage
updating
* before-paint - emitted before painting if there will be any stage
painting
* after-paint - emitted after painting if there was any stage painting
* after-update - emitted as a last step of updating, no matter whether
there were any painting or not
Currently there were only one listener, that should only really have
been called if there was any painting, so no changes to listeners are
needed.
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 frame clock wouldn't be useable yet, but none the less, add API to
get the frame clock best suited for driving the actor. Currently this
translates to the fastest one, but that might change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
The frame clock is meant to eventually drive the painting of the view,
in contrast to the master frame clock painting every view on the stage.
Right now it's a useless place holder.
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 association is inactive, as in it doesn't do anything yet, but it
will later be used to determine what frame clock should be driving the
timeline by looking at what stage view the actor is currently on.
This also adapts sub types (ClutterPropertyTransition) to have
constuctors that takes an actor just as the new ClutterTimeline
constructor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
This is so something outside of clutter-stage.c (i.e.
clutter-stage-view.c) can eventually do various things
_clutter_stage_do_update() does now while not redrawing the whole stage.
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
Devices are updated (repicked) as part of the stage update phase, as
their stacking, position and transform might have changed since since
the last update.
The redraw clip was used to avoid unnecessary updating of devices, if
the device in question had it's position outside of the redraw clip. If
the device coordinate was outside of the redraw clip, what was
underneith the device couldn't have changed.
What it failed to do, however, was to update devices if a relayout had
happened in the same update, as it checked the state whether a layout
had happened before attempting to do a relayout, effectively delaying
the device updating to the next update.
This commit changes the behavior to always update the device given the
complete redraw clip caused by all possible relayouts of the same update
as the device update happens in.
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
This will allow anyone to finish any queued redraws making their
corresponding damage end up being posted to the stage views. This will
allow units to check whether, so far, any updates are queued on a
particular stage view.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1285
Add API to add and remove ClutterTimeline objects to the frame clock.
Just as the legacy master clock, having a timeline added to the frame
clock causes the frame clock to continuously reschedule updates until
the timeline is removed.
ClutterTimeline is adapted to be able to be driven by a
ClutterFrameClock. This is done by adding a 'frame-clock' property, and
if set, the timeline will add and remove itself to the frame clock
instead of the master clock.
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 have the neccessary infrastructure to get notified about
changes to the absolute transformation matrix, we can also invalidate
the stage-views list on updates to this matrix.
So rename absolute_allocation_changed() to absolute_geometry_changed()
to make it clear this function is not only about allocations, and call
that function recursively for all children on changes to the
transformation matrix, too.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1343
If we want to invalidate the stage-views list reliably on changes to the
actors transformation matrices, we also need to get notified about
changes to the custom transformations applied using the
apply_transform() vfunc.
So provide a new API that allows invalidating the transformation matrix
for actors implementing custom transformations, too. This in turn allows
us to cache the matrix applied using the apply_transform() vfunc by
moving responsibility of keeping track of the caching from
clutter_actor_real_apply_transform() to
_clutter_actor_apply_modelview_transform().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1343
For ClutterText, the resource scale the text is drawn with affects the
size of the allocation: ClutterText will choose a font scale based on
the resource scale, and that font scale can lead to a slight difference
in size compared to the unscaled font.
We currently handle that by queuing a relayout inside the
"resource-scale-changed" signal handler. This solution is a bit
problematic though since it will take one more allocation cycle until
the allocation is actually updated after a scale-change, so the actor is
painted using the wrong allocation for one frame.
Also the current solution can lead to relayout loops in a few cases, for
example if a ClutterText is located near the edge on a 1x scaled monitor
and is moved to intersect a 2x scaled monitor: Now the resource scale
will change to 2 and a new allocation box is calculated; if this
allocation box is slightly smaller than the old one because of the new
font scale, the allocation won't intersect the 2x scaled monitor again
and the resource scale switches back to 1. Now the allocation gets
larger again and intersects the 2x scaled monitor again.
This commit introduces a way to properly support those actors: In case
an actors resource scale might affect its allocation, it should call the
private function clutter_actor_queue_immediate_relayout(). This will
make sure the actor gets a relayout before the upcoming paint happens
afte every resource scale change. Also potential relayout loops can
be handled by the actors themselves using a "phase" argument that's
passed to implementations of the calculate_resource_scale() vfunc.
The new API is private because resource scales are not meant to be used
in a way where the scale affects the allocation. With ClutterText and
the current behavior of Pango, that can't be avoid though, so we need it
anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1276
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
Now that ClutterActor has a convenient API for getting the stage views
an actor is presented on, we can remove a large part of the code for
resource-scale calculation and instead rely on the stage-views list.
The way this works is a bit different from the old resource scales:
clutter_actor_get_resource_scale() always returns a scale, but this
value is only guaranteed to be correct when called from a vfunc_paint()
implementation, in all other cases the value is guessed using the scale
of the parent actor or the last valid scale. Now in case the value
previously reported by clutter_actor_get_resource_scale() turns out to
be wrong, "resource-scale-changed" will be emitted before the next paint
and the actor has a chance to update its resources.
The general idea behind this new implementation is for actors which only
need the scale during painting to continue using
clutter_actor_get_resource_scale() as they do right now, and for actors
which need the resource scale on other occasions, like during size
negotiation, to use the scale reported by
clutter_actor_get_resource_scale() but also listen to the
"resource-scale-changed" signal to eventually redo the work using the
correct scale.
The "guessing" of the scale is done with the intention of always giving
actors a scale to work with so they don't have to fall back to a scale
value the actor itself has to define, and also with the intention of
emitting the "resource-scale-changed" signal as rarely as possible, so
that when an actor is newly created, it won't have to load its resources
multiple times.
The big advantage this has over the old resource scales is that it's now
safe to call clutter_actor_get_resource_scale() from everywhere (before,
calling it from size negotiation functions would usually fail). It will
also make it a lot easier to use the resource scale for complex cases
like ClutterText without risking to get into relayout loops.
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
We're going to refactor resource scales, making the notification of
changes to the resource scale a lot more important than it is right now
(we won't guarantee queried scales are correct outside the paint cycle
anymore).
Having a separate signal/vfunc for this will make the difference between
the new clutter_actor_get_resource_scale() API (which can return a
guessed value) and the notification of changes to the resource scale
(which will be guaranteed to return an up-to-date value) more obvious.
So replace the "resource-scale" property of ClutterActor with a
"resource-scale-changed" signal that's emitted when the resource scale
is recalculated.
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
ClutterBoxLayout calculates the preferred size of the opposite
orientation (so for example the height if the orientation is horizontal)
by getting the preferred size of the real orientation first, and then
the preferred size of the opposite orientation, using the other size as
for_width/height when doing the request.
Right now, for non-homogeneous layouts this for_width/height does not
adjust for the spacing set on the box layout. This leads to children
being passed a slightly larger for_width/height, which in case of
ClutterText might cause the line to not wrap when it actually should.
This in turn means we can end up with an incorrect preferred size for
the opposite orientation, leading to a wrong allocation.
So fix that and adjust for the spacing just as we do for homogeneous
layouts by subtracting the total spacing from the available size that is
distributed between children.
This fixes the wrong height of the checkbox label reported in
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2574.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1333
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
ClutterStage is the one and only subclass of ClutterGroup, but
it overrides basically everything specific to ClutterGroup to
mimic a ClutterActor. What a waste!
Subclass ClutterActor directly and remove all the now useless
vfunc overrides from ClutterStage. Adapt CallyStage to subclass
CallyActor as well.
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
I noticed my system would fall back to the slow unclipped (and
uncullable) paint path whenever a window touched the left edge of
the screen. Turns out that was a red herring. Just that
`use_clipped_redraw` was uninitialized so clipping/culling was used
randomly.
So the compiler failed to notice `use_clipped_redraw` was uninitialized.
Weirdly, as soon as you fix that it starts complaining that `buffer_age`
might be uninitialized, which appears to be wrong. So we initialize that
too, to shut up the compiler warnings/errors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1323
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
The ClutterBindConstraint will change the preferred size an actor
reports so it returns the same size as the source actor in some cases.
This behavior was introduced recently with 4f8e518d.
This can lead to infinite loops in case the source actor is a parent of
the actor the BindConstraint is attached to, that's because calling
get_preferred_size() on the source will recursively call
get_preferred_size() on the actor again.
So to avoid those loops, check if the source is a parent of the actor
we're attached to and don't update the preferred size in that case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1282
For ClutterClones we need to apply a scale to the texture of the clone
to ensure the painted texture of the source actor actually fits the
allocation of the clone. We're doing this using the transformation
matrix instead of using the scale_x/scale_y properties of ClutterActor
to allow users to scale ClutterClones using that API independently.
Now it's quite a bad idea to get the allocation boxes for calculating
that scale using clutter_actor_get_allocation_box(), since that method
will internally do an immediate relayout of the stage in case the actor
isn't allocated. Another side effect of that approach is that it makes
it impossible to invalidate the transform (which will be needed when we
start caching those matrices) properly.
So since we eventually allocate both the source actor and the clone
ourselves anyway, we can simply use the allocation box inside
clutter_clone_allocate() (which is definitely updated and valid at that
point) to calculate the scale factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181
It seems wrong to use the scale factor of the X axis on the Z axis and
it looks like this has been accidentally changed in commit 570fa3f044.
So use a factor of 1.0 instead to not scale the Z axis at all because
the layout machinery only works in X and Y coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181
There are cases where a layout manager used by an actor also wants to
return a custom size when the actor has no children, for example in case
the layout manager requests a fixed size. This is currently impossible
because we only query the layout manager when calculating the preferred
size if the actor has children.
So fix that and also use the layout managers size negotiation functions
in case the actor has no children.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1322
_cogl_shader_set_source_with_boilerplate and _cogl_shader_compile_real
have enough GL assumptions that it makes sense to push them into the
backend. Taken together their only callers are under driver/gl, so.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
This had been an entirely-too-GL-aware collection of renderer queries,
mostly to work around driver bugs and handle software drivers
intelligently. The driver workarounds have been removed (fix your
driver, and if you can't because it's closed-source, fix that first),
and we now delegate the am-i-software-or-not logic to the backend, so
this can all go
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1194
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
The size of the buffer the texture will be written to by
paint_to_buffer() is determined based on
meta_screen_cast_area_stream_src_get_specs() which uses roundf() to
calculate the width and height after scaling. Because the size of the
texture to be written to that buffer is calculated using ceilf(), it
might exceed the allocated buffer when using fractional scaling.
In 3.36 paint_to_buffer() is used from capture_view() which also uses
roundf() to allocate its buffer. Here this leads to a memory corruption
resulting in a crash when taking screenshots of an area.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2842https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1320
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
The modifier state of the input device is supposed to be set to the
newest state, while the modifier state detail of the event is set to the
last state before the event (so not including the changes triggered by
the event).
So since the modifier state of the event is the last state anyway, the
state of the ClutterInputDevice is supposed to be set by the backend and
not by the stage while queuing the event, so stop setting the state
here.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
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
Switch from clutter_seat_list_devices() to the new peek_devices() method
of ClutterSeat in cases where we're only looping through the returned
list without manipulating it. This way we don't have to unnecessarily
copy around the list of devices.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Add a method to ClutterSeat that allows peeking the list of input
devices and allow looping through devices a bit faster. The API left is
private so we can make use of peeking the GList internally, but don't
have to expose any details to the outside, which means we'd have to
eventually stick with a GList forever to avoid breaking API.
Since we now have the peek_devices() API internally, we can implement
ClutterSeats public list_devices() API using g_list_copy() on the list
returned by peek_devices().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
While it's strongly discouraged, it is possible to queue a new relayout
of an actor in the middle of an allocation cycle, we warn about it but
don't forbid it.
With the introduction of the "shallow relayout" API, our handling of
those relayouts silently changed: Before introducing "shallow
relayouts", we'd handle them on the next stage update, but with the
priv->pending_relayouts hashtable and the
priv->pending_relayouts_version counter, we now do them immediately
during the same allocation cycle (the counter is increased by 1 when
queuing the relayout and we switch to a new GHashTableIter after
finishing the current relayout, which means we'll now do the newly
queued relayout).
This change in behavior was probably not intended and wasn't mentioned
in the commit message of 5257c6ecc2, so
switch back to the old behavior, which is more robust in preventing
allocation-loops. To do this, use a GSList instead of GHashTable for the
pending_relayouts list, and simply steal that list before doing the
relayouts in _clutter_stage_maybe_relayout().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1267
As explained in the last commits, we'll let gnome-shell take care of
this since freezing and thawing needs to be decoupled from the effect
starting and ending.
So stop freezing the MetaWindowActor when starting the effect and
thawing the actor when ending the effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
As explained in the last commit, gnome-shell needs to be able to thaw
window actor updates during its size-change effect is active.
So make meta_window_actor_freeze() and meta_window_actor_thaw() public
API, which will allow the shell to freeze and thaw actor updates itself.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
The size-change animation in gnome-shell needs to sync the window actors
geometry during the animation, it currently does this by notifying the
compositor that the animation was finished before it actually is.
This causes a few bugs in Mutter though, since it will now emit the
"effects-completed" signal on the window actor even though they aren't
completed.
To fix that, we need to decouple freezing and thawing of actor updates
from window effects and allow gnome-shell to thaw actor updates before
it notifies Mutter that the effect is completed.
The first step for this is allowing to sync the actor geometry while an
effect is active, this should be redundant since effects which actually
need to inhibit those updates will freeze the actor anyway. Also a
geometry change happening while another effect is active will kill the
old effect anyway because MetaPluginManager kills all the active window
effects before starting a new one; so the new size-change effect for any
geometry change is going to kill the current effect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1250
ClutterAlignConstraint currently assumes the source actor is positioned
in the same coordinate system as the actor it's attached to and
automatically offsets the adjusted allocation by the origin of the
source actor.
This behavior is only valid though in case the source actor is a sibling
of the constraint actor. If the source actor is somewhere else in the
actor tree, the behavior gets annoying because the constraint actor is
offset by (seemingly) random positions.
To fix this, stop offsetting the constraint actors allocation by the
position of the source.
To still make it possible to align the constraint actors origin with the
origin of the source, no longer override the origin of the allocation
in the AlignConstraint. This allows users to align the origin using a
BindConstraint, binding the actor position to the position of the
source, which is more flexible and also more elegant.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/737
Add a new pivot-point property to the ClutterAlignConstraint, similar to
the pivot point used by ClutterActor, defining the point in the
constraint actor around which the aligning is applied to the actor.
Just as the ClutterActor property, this property is defined using a
GraphenePoint.
By default this property remains set to (-1, -1) and the actor
will always be aligned inside the source actor, preserving the existing
behavior of ClutterAlignConstraint.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/737
Trying to figure out what this comment was actually about, it turns out
that MSC means Media Stream Counter, and as mentioned in an article[0]
is related to DRI3 and the X11 Present extension. Anyway, the comment
has been there raising questions for some years now, I think we can
remove it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The ID and name are just moved into the instance private, while the rest
is moved to a `MetaCrtcModeInfo` struct which is used during
construction and retrieved via a getter. Opens up the possibility to
add actual sub types.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Just as with MetaOutput, instead of the home baked "inheritance" system,
using a gpointer and a GDestroyNotify function to keep the what
effectively is sub type details, make MetaCrtc an abstract derivable
type, and make the implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Instead of the home baked "inheritance" system, using a gpointer and a
GDestroyNotify function to keep the what effectively is sub type
details, make MetaOutput an abstract derivable type, and make the
implementations inherit it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
It's used for two things: avoid reading configs, and actual hotplug
update mode. The former requires the suggested position to be (-1, -1)
to trick the monitor configuration generator to skip using the suggested
position even if hotplug update mode is set to TRUE. The latter should
use the actual hotplug mode coordinates.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Now set as a property during construction. Only actually set by the
Xrandr backend, as it's the only one currently not supporting all
transforms, which is the default.
While at it, move the 'ALL_TRANFORMS' macro to meta-monitor-tranforms.h.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
The output info is established during construction and will stay the
same for the lifetime of the MetaOutput object. Moving it out of the
main struct enables us to eventually clean up the MetaOutput type
inheritence to use proper GObject types.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
MetaCrtcInfo and MetaOutputInfo did not represent information about
MetaCrtc and MetaOutput, but the result of the monitor configuration
assignment algorithm, thus rename it to MetaCrtcAssignment and
MetaOutputAssignment.
The purpose for this is to be able to introduce a struct that actually
carries information about the CRTCs and outputs, as retrieved from the
backend implementations.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
That is is_presentation, is_primary, is_underscanning and backlight.
The first three are set during CRTC assignment as they are only valid
when active. The other is set separately, as it is untied to
monitor configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
It was used during configuration to ensure that we always dealt with
every output and CRTC. Do this without polluting the MetaOutput and
MetaCrtc structs with intermediate variables not used by the
corresponding types themself.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1287
Now that we have a proper way to mark our allocation as uninitialized,
make use of that and only disallow implicit transitions of the
"allocation" property if that is the case.
This fixes a bug where easing the allocation of an actor is impossible
when someone queued a relayout on it (or a child of it) before.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1290
We currently initialize the ClutterActorBox of the actors allocation to
zero, but there's a difference between a valid zero-allocation and an
actor having never been allocated. Currently it's impossible for us to
detect the latter case in a reliable way and we use the needs_allocation
flag for this, which may also be set in other situations.
So initialize the allocation of actors to the newly added UNINITIALIZED
ClutterActorBox, which will make it easier to detect whether an actor
already got its initial allocation.
This also fixes another issue right now: Actors which get allocated a
(valid) zero allocation, will now notify the "allocation" property in
this case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1290
Add support for an artificial UNINITIALIZED marking for ClutterActorBox,
done by setting the boxes origin to Infinity and its size to -Infinity.
That is a value that's considered an invalid allocation by Clutter and
which can never be set by sane code.
This will allow setting the allocation of ClutterActors to an
UNINITIALIZED box when creating actors or when removing them from the
scenegraph and makes it possible to explicitely detect uninitialized
allocations, which is useful in a few cases.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1290
The current code assumes that the actor will always have the same
size and position of the background texture, but part of the implicit
contract of being a ClutterContent is being able to render itself
at any given actor, at any given size.
For example, if the current code is given an actor with 0x0+100+100
as geometry, and no clipped region, it'll render not the whole
background, but the 0x0+100+100 rectangle of the background. In
practice, the actor geometry acts like a "clip mask" over the
background texture, due to the assumption that the actor will
always have the same size of the monitor.
Make the calculation of the texture slices relative to the actor
box.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
MetaBackgroundActor is still necessary for culling purposes,
but now the actual rendering of the background is delegated
to MetaBackgroundContent, as well as the sizing information.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
MetaBackgroundContent is a ClutterContent implementation
that can render a background to any attached actor. Right
now, it preserves all the properties and the rendering
model of MetaBackgroundActor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1302
X11 window stacking operations are by nature prone to race conditions.
For example, we might queue a "raise above" operation, but before it
actually takes place, the sibling the window was to be rased above, is
withdrawn.
In these cases we'd log warnings even though they are expected to
happen. Downgrade these warnings to debug messages, only printed when
MUTTER_VERBOSE is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1300
Test that the stage-views list of ClutterActor is correct when moving an
actor, reparenting it, or hiding an actor up the hierarchy. Also test
that the "stage-views-changed" signal works as expected.
Don't test actor transforms for now because those aren't supported yet.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
We currently go through the whole tree of mapped actors on every paint
cycle to update the stage views actors are on. Even if no actors need
updating of their stage views, traversing the actor tree is still quite
expensive and shows up when using a profiler.
So tone down the amounts of full-tree traversals we have to do on every
paint cycle and only traverse a subtree if it includes an actor which
actually needs updating of its stage views.
We do that by setting the `needs_update_stage_views` flag to TRUE
recursively for all parents up to the stage when the stage-views list of
an actor gets invalidated. This way we end up updating a few more actors
than necessary, but can avoid searching the whole actor tree for actors
which have `needs_update_stage_views` set to TRUE.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
Add a new signal that's emitted when the stage views an actor being
painted on have changed, "stage-views-changed". For example this signal
can be helpful when tracking whether an actor is painted on multiple
stage views or only one.
Since we must clear the stage-views list when an actor leaves the stage
(actors that aren't attached to a stage don't get notified about the
stage views being changed/replaced), we also emit the new signal when an
actor gets detached from the stage (otherwise there would be an edge
case where no signal is emitted but it really should: An actor is
visible on a stage view, then detached from the stage, and then attached
again and immeditely moved outside the view).
Also skip the comparison of the old stage-views list and the new one if
nobody is listening to the signal to save some resources.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
There are certain rendering techniques and optimizations, for example
the unredirection of non-fullscreen windows, where information about the
output/stage-view an actor is on is needed to determine whether the
optimization can be enabled.
So add a new method to ClutterActor that allows listing the stage-views
the actor is being painted on: clutter_actor_peek_stage_views()
With the way Clutter works, the only point where we can reliably get
this information is during or right before the paint phase, when the
layout phase of the stage has been completed and no more changes to the
actors transformation matrices happen. So to get the stage views the
actor is on, introduce a new step that's done on every master clock tick
between layout and paint cycle: Traversing through the actor tree and
updating the stage-views the mapped actors are going to be painted on.
We're doing this in a separate step instead of inside
clutter_actor_paint() itself for a few reasons: It keeps the code
separate from the painting code, making profiling easier and issues
easier to track down (hopefully), it allows for a new
"stage-views-changed" signal that doesn't interfere with painting, and
finally, it will make it very easy to update the resource scales in the
same step in the future.
Currently, this list is only invalidated on allocation changes of
actors, but not on changes to the transformation matrices. That's
because there's no proper API to invalidate the transformation matrices
ClutterActor implementations can apply through the apply_transform()
vfunc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
When the stage views the stage is shown on are changed, ClutterStage
currently provides a clutter_stage_update_resource_scales() method
that allows invalidating the resource scales of all actors. With the new
stage-views API that's going to be added to ClutterActor, we also need a
method to invalidate the stage-views lists of actors in case the stage
views are rebuilt and fortunately we can re-use the infrastructure for
invalidating resource scales for that.
So since resource scales depend on the stage views an actor is on,
rename clutter_stage_update_resource_scales() and related methods to
clutter_stage_clear_stage_views(), which also covers resource scales.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1196
While the layout manager of a ClutterActor does get properly unset when
destroying an actor, we currently forget to disconnect the
"layout-changed" signal from it.
So do that, and while at it, also switch to using the signal id for
disconnecting from the signal instead of
g_signal_handlers_disconnect_by_func(), which caused problems before
because it might traverse the signal handler list.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1281
We currently are confusing g_param_spec_enum and g_param_spec_flags for
the offscreen-redirect property of ClutterActor. Since it's actually a
flag, make it a flag everywhere.
Fun fact: This was already partly done with
d7814cf63e, but that commit missed the
setter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1292
Just like the ClutterBindConstraint, the ClutterAlignConstraint should
listen to "queue-relayout" of its source actor, not
"notify::allocation". That's because the latter will queue a relayout
during an allocation cycle and might cause relayout loops.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1296
When an app disappears after some data from it has been copied to the
clipboard, the owner of the clipboard selection becomes a new memory
selection source. The initial reference this new selection source is
never unref'ed, which leads to this being leaked on the next clipboard
selection owner change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1293
Using XDG_CONFIG_HOME allows users to place their keyboard configuration into
their home directory and have them loaded automatically.
libxkbcommon now defaults to XDG_CONFIG_HOME/xkb/ first, see
https://github.com/xkbcommon/libxkbcommon/pull/117
However - libxkbcommon uses secure_getenv() to obtain XDG_CONFIG_HOME and thus
fails to load this for the mutter context which has cap_sys_nice.
We need to manually add that search path as lookup path.
As we can only append paths to libxkbcommon's context, we need to start with
an empty search path set, add our custom path, then append the default search
paths.
The net effect is nil where a user doesn't have XDG_CONFIG_HOME/xkb/.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/936
Hiding a compositor stage is not something that's really supported, but
will still be used by tests, to get closer to a "fresh" stage for each
test case, when the tests eventually start using the mutter provided
stage.
It'll use that stage simply because creating standalone stages isn't
supported.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
The script parser only included G_PARAM_CONSTRUCT_ONLY parameters when
constructing objects. This causes issues if an object requires a
parameter to be set during construction, but may also change after. Fix
this by including G_PARAM_CONSTRUCT parameters when constructing script
objects as well.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
We would get the MetaDisplay from the backend singleton before creating
the MetaCompositor, then in MetaCompositor, get the backend singleton
again to get the stage. To get rid of the extra singleton fetching, just
pass the backend the MetaCompositor constructors, and fetch the stage
directly from the backend everytime it's needed.
This also makes it available earlier than before, as we didn't set our
instance private stage pointer until the manage() call.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Start follow the convention used in ClutterFrameClock by including the
meaning as well as time granularity in the variable name. The
constructor takes the intended duration of the constructed timeline in
milli seconds, so call the constructor argument `duration_ms`. This is
done in preparation for adding more constuctors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
Also fix a test that dependends on a specific element order in a list
that wasn't defined to have any particular order.
The frames per second is decreased from 30 to 10, to make the test less
flaky when running in CI.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1289
The shadow was disabled for the X11 client as it was far to unreliable
when comparing sizes.
It seems that the Wayland backend has been somewhat unreliable as well,
where some race condition causing incorrect sizes thus a flaky test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1288
A "show" command calls gtk_window_show() and gdk_display_sync(), then
returns. This means that the X11 window objects are guaranteed to have
been created in the X11 server.
After that, the test runner will look up the window's associated
MetaWindow and wait for it to be shown.
What this doesn't account for is if mutter didn't get enough CPU time to
see the new window. When this happens, the 'default-size' stacking test
sometimes failed after hiding and showing the X11 window.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1288
If a test is not expected to succeed, then running it could be considered
to be a waste of resources, particularly if the failure might manifest
as an indefinite hang (see cogl!11), or if the test is likely to dump core
and trigger "expensive" crash-reporting mechanisms like systemd-coredump,
corekeeper, abrt or apport.
Skip the tests that are expected to fail. They can still be requested via
an environment variable, which can be set after fixing a bug to check which
tests are now passing.
Originally cogl!15, adapted for mutter's fork of cogl to use gboolean
instead of CoglBool.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1272
Signed-off-by: Simon McVittie <smcv@debian.org>
For actors which don't have needs_allocation set to TRUE and where the
new allocation wouldn't be different from the old one, the allocate()
vfunc doesn't have to be called. We still did this in case a parent
actor was moved though (so the absolute origin changed), because we
needed to propagate the ABSOLUTE_ORIGIN_CHANGED allocation flag down to
all actors.
Since that flag is now removed and got replaced with a private property,
we can simply notify the children about the absolute allocation change
using the existing infrastructure and safely stop allocating children at
this point.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
With commit 0eab73dc2e we introduced an optimization of not doing
allocations for actors which are hidden. This broke the propagation of
absolute origin changes to hidden actors, so if an actor is moved while
its child is hidden, the child will not get
priv->needs_compute_resource_scale set to TRUE, which means the resource
scale won't be updated when the child gets mapped and shown again.
Since we now have priv->absolute_origin_changed, we can simply check
whether that is TRUE for our parent before bailing out of
clutter_actor_allocate() and if it is, notify the whole hidden sub-tree
about the absolute origin change.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
Since clutter_stage_set_viewport() is only used inside clutter-stage.c
anyway, we can make it a static method. Also we can remove the x and y
arguments from it since they're always set to 0 anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When getting the last allocation using
clutter_actor_get_allocation_box(), Clutter will do an immediate
relayout of the stage in case an actor has an invalid allocation. Since
the allocation is always invalid when the allocate() vfunc is called,
clutter_stage_allocate() always forces another allocation cycle.
To fix that, stop comparing the old allocation to the new one to find
out whether the viewport changed, but instead use the existing check in
_clutter_stage_set_viewport() and implement the behavior of rounding the
viewport to the nearest int using roundf() (which should behave just as
CLUTTER_NEARBYINT()) since we're passing around floats anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When manipulating the allocation of a ClutterActor from an allocate()
vfunc override, clutter_actor_set_allocation() is used to let Clutter
know about the changes.
If the actors allocation or its absolute origin did not change before
that, this can also affect the actors absolute_origin_changed property
used by the children to detect changes to their absolute position.
So fix this bug (which luckily didn't seem to affect us so far) and set
priv->absolute_origin_changed to TRUE in case the origin changes inside
clutter_actor_set_allocation_internal(). Since this function is always
called when our allocation changes, we no longer need to update
absolute_origin_changed in clutter_actor_allocate() now.
Since a change to the absolute origin always affects the resource scale,
too, we also need to move that check from clutter_actor_allocate() here
to make sure we update the resource scale.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
Since the introduction of the shallow relayout functionality it's
possible to start an allocation cycle at any point in the tree, not only
at the stage. Now when starting an allocation at an actor that's not the
stage, we'd still look at the absolute_origin_changed property of this
actors parent, which might still be set to TRUE from the parents last
allocation.
So avoid using the parents absolute_origin_changed property from the
last allocation in case a shallow relayout is being done and always
reset the absolute_origin_changed property to FALSE after the allocation
cycle.
This broke with the removal of the ABSOLUTE_ORIGIN_CHANGED
ClutterAllocationFlag that was done in commit dc8e5c7f.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1247
When we created the DMA buffer backed CoglFramebuffer, we handed it over
to CoglDmaBufHandle which took its own reference. What we failed to do
was to release our own reference to it, effectively leaking it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
The stream will clean up the buffers, so let it do that before we
destroy them under its feet. Note that it'll only do this after the
following PipeWire commit:
commit fbaa4ddedd84afdffca16f090dcc4b0db8ccfc29
Author: Wim Taymans <wtaymans@redhat.com>
Date: Mon Jun 1 15:36:09 2020 +0200
stream: allow NULL param and 0 buffers in disconnect
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1283
wait_reconfigure ensures that the whole configure back and forth
completes before continuing. Doing this after every state change ensures
that we always end up with the expected state, thus fixes flakyness of
the restore-position stacking test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1279
This cannot be made to work reliably. Some factoids:
- Internal devices may be connected via USB.
- The ACPI spec provides the _PLD (Physical location of device) hook to
determine how is an USB device connected, with an anecdotal success
rate. Internal devices may be seen as external and vice-versa, there is
also an "unknown" value that is widely used.
- There may be non-USB keyboards, the old "AT Translated Set 2 Keyboard"
interface does not change on hotplugging.
- Libinput has an internal series of quirks to classify keyboards as
internal of external, also with an "unknown" value.
These heuristics are kinda hopeless to get right by our own hand. Drop
this external keyboard detection in the hope that there will be something
more deterministic to rely on in the future (e.g. the libinput quirks
made available to us directly or indirectly).
Fixes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2378
Related: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2353https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1277
When r is 128 or more, running tests compiled with the undefined behaviour
sanitizer (ubsan) reports:
test-utils.c:312:45: runtime error: left shift of 128 by 24 places cannot be represented in type 'int'
which indeed it cannot. Force the type to be unsigned 32-bit so that we
get defined behaviour.
Similarly, in test-atlas-migration, the left-shifted guint8 is promoted
to int, which again does not have enough non-sign bits available to
left-shift a value >= 128 by 24 bits. Again, force the shift to be done
in unsigned 32-bit space.
This was originally cogl!22, but applies equally to mutter's fork of cogl.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1271
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the cogl_bitmap_new_for_data documentation, the data is not
copied, so the application must keep the buffer alive for the lifetime
of the CoglBitmap. Freeing it too early led to a use-after-free in the
cogl unit tests. With that fixed, the test passes, so remove the known
failure annotation.
This AddressSanitizer trace is from the original cogl, but the bug and
fix apply equally to mutter's fork of cogl:
==6223==ERROR: AddressSanitizer: heap-use-after-free on address 0x62100001a500 at pc 0x7f3e2d4e7f4e bp 0x7ffcd9c41f30 sp 0x7ffcd9c416e0
READ of size 4096 at 0x62100001a500 thread T0
#0 0x7f3e2d4e7f4d (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x96f4d)
#1 0x7f3e260c7f6b in util_copy_box ../src/gallium/auxiliary/util/u_surface.c:131
#2 0x7f3e268c6c10 in u_default_texture_subdata ../src/gallium/auxiliary/util/u_transfer.c:67
#3 0x7f3e26486459 in st_TexSubImage ../src/mesa/state_tracker/st_cb_texture.c:1480
#4 0x7f3e26487029 in st_TexImage ../src/mesa/state_tracker/st_cb_texture.c:1709
#5 0x7f3e26487029 in st_TexImage ../src/mesa/state_tracker/st_cb_texture.c:1691
#6 0x7f3e2644bdba in teximage ../src/mesa/main/teximage.c:3105
#7 0x7f3e2644bdba in teximage_err ../src/mesa/main/teximage.c:3132
#8 0x7f3e2644d84f in _mesa_TexImage2D ../src/mesa/main/teximage.c:3170
#9 0x7f3e2cd1f7df in _cogl_texture_driver_upload_to_gl driver/gl/gl/cogl-texture-driver-gl.c:347
#10 0x7f3e2ccd441b in allocate_from_bitmap driver/gl/cogl-texture-2d-gl.c:255
#11 0x7f3e2ccd441b in _cogl_texture_2d_gl_allocate driver/gl/cogl-texture-2d-gl.c:462
#12 0x7f3e2ce3a6c0 in cogl_texture_allocate cogl/cogl-texture.c:1398
#13 0x7f3e2ce3e116 in _cogl_texture_pre_paint cogl/cogl-texture.c:359
#14 0x7f3e2cdee177 in _cogl_pipeline_layer_pre_paint cogl/cogl-pipeline-layer.c:864
#15 0x7f3e2cd574af in _cogl_rectangles_validate_layer_cb cogl/cogl-primitives.c:542
#16 0x7f3e2cdd742f in cogl_pipeline_foreach_layer cogl/cogl-pipeline.c:735
#17 0x7f3e2cd5c8b0 in _cogl_framebuffer_draw_multitextured_rectangles cogl/cogl-primitives.c:658
#18 0x7f3e2cd60152 in cogl_rectangle cogl/cogl-primitives.c:858
#19 0x5570a71ed6a0 in check_texture tests/conform/test-premult.c:103
#20 0x5570a71ed946 in test_premult tests/conform/test-premult.c:159
#21 0x5570a71df0d6 in main tests/conform/test-conform-main.c:58
#22 0x7f3e2bcd809a in __libc_start_main ../csu/libc-start.c:308
#23 0x5570a71e0869 in _start (/home/smcv/src/debian/cogl/tests/conform/.libs/test-conformance+0x33869)
0x62100001a500 is located 0 bytes inside of 4096-byte region [0x62100001a500,0x62100001b500)
freed by thread T0 here:
#0 0x7f3e2d5581d7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x1071d7)
#1 0x5570a71ed58b in make_texture tests/conform/test-premult.c:69
previously allocated by thread T0 here:
#0 0x7f3e2d558588 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107588)
#1 0x7f3e2d384500 in g_malloc ../../../glib/gmem.c:99
This was originally cogl!12.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1274
Signed-off-by: Simon McVittie <smcv@debian.org>
In clutter_text_queue_redraw_or_relayout() we check whether the size
of the layout has changed and queue a relayout if it did, otherwise we
only queue a redraw and save some resources.
The current check for this also queues a redraw if the actor has no
valid allocation. That seems right on the first glance since the actor
will be allocated anyway, but we actually want to call
clutter_actor_queue_relayout() again here because that also invalidates
the size cache of the actor which might have been updated and marked
valid in the meantime.
So make sure the size cache is always properly invalidated after the
size of the layout changed and also call clutter_actor_queue_relayout()
in case the actor has no allocation.
This fixes a bug where getting the preferred width of a non-allocated
ClutterText, then changing the string of the ClutterText, and then
getting the preferred width again would return the old cached width (the
width before we changed the string).
The only place where this bug is currently happening is in the overview,
where we call get_preferred_width() on the unallocated ClutterText of
the window clone title: When the window title changes while the
ClutterText is unallocated the size of the title is going to be wrong
and the text might end up ellipsized or too large.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1150
Move Wayland support (i.e. the MetaWaylandCompositor object) made to be
part of the backend. This is due to the fact that it is needed by the
backend initialization, e.g. the Wayland EGLDisplay server support.
The backend is changed to be more involved in Wayland and clutter
initialization, so that the parts needed for clutter initialization
happens before clutter itself initialization happens, and the rest
happens after. This simplifies the setup a bit, as clutter and Wayland
init now happens as part of the backend initialization.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
On X11 we don't update the texture in certain circumstances, such as if
the surface is a fullscreen unredirect, or doesn't have a Pixmap. On
Wayland we only want to avoid updating the texture if there is no
texture, but as this is handled implicitly by MetashapedTexture, we
don't need to try to emulate the X11-y conditions in the generic layer
and instead just have the implementations handle update processing
themself.
This doesn't have any functional changes, but removes a vfunc from
MetaSurfaceActorClass.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
It's effectively used by mutter by abusing a ClutterTimeline to scedule
updates. Timelines are not really suited in places that is done, as it
is really just about getting a single new update scheduled whenever
suitable, so expose the API so we can use it directly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We could call clutter_stage_schedule_update() and it wouldn't actually
schedule anything, as the master frame clock only tries to reschedule if
1) there is an active timeline, 2) there are pending relayouts, 3) there
are pending redraws, or 4) there are pending events. Thus, a call to
clutter_stage_schedule_update() didn't have any effect if it was called
at the wrong time.
Fix this by adding a boolean state "needs_update" to the stage, set on
clutter_stage_schedule_update() and cleared on
_clutter_stage_do_update(), that will make the master clock reschedule
an update if it is TRUE.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218
We need to use the framebuffer of the view instead of the onscreen
framebuffer when painting the damage region, otherwise the redraw clips
on rotated monitors won't be shown correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Compare, tile by tile, whether actual damage actually changed any
pixels. While this requires mmap():ing DMA buffers and comparing their
content, we should only ever use shadow buffers when we're using the
software renderer, meaning mmap() is cheap as it doesn't involve any
downloading.
This works by making the shadow framebuffer double buffered, while
keeping track of damage history. When we're about to swap the onscreen
buffer, we compare what part of the posted damage actually changed,
records that into a damage history, then given the onscreen buffer age,
collect all actual damage for that age. The intersection of these tiles,
and the actual damage, is then used when blitting the shadow buffer to
the onscreen framebuffer.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1157https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Move the damage history tracking to a new ClutterDamageHistory helper
type. The aim is to be able to track damage history elsewhere without
reimplementing the data structure and tracking logic.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
This fixes the last "copy everything" paths when clutter doesn't
directly paint onto the onscreen framebuffer. It adds a new hook into
the stage view called before the swap buffer, as at this point, we have
the swap buffer damag regions ready, which corresponds to the regions we
must blit according to the damage reported to clutter.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The rest didn't change, so only actually paint the part of the offscreen
that was composited as part of the stage painting. In practice, this
means that, unless a shadow buffer is used, we now only paint the
damaged part of the stage, and copy the damage part of the offscreen to
the onscreen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
We failed to use the buffer age when monitors were rotated, as when they
are, we first composite to an offscreen framebuffer, then later again to
the onscreen. The buffer age checking happened on the offscreen, and an
offscreen being single buffered, they can't possible support buffer
ages.
Instead, move the buffer age check to check the actual onscreen
framebuffer. The offscreen to onscreen painting is still always full
frame, but that will be fixed in a later commit.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The manual "cleaning" of the viewport and projection state is removed,
and we only ever try to invalidate the state so that it'll be updated
next time. Change the API used to reflect this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
The stage would fetch the front framebuffer and set the viewport and
projection matrix, but if we are going to more than one front buffer,
that won't work, so let the stage just pass the viewport and projection
matrix to the view and have the view deal with the framebuffer(s).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
Will be used for logging to identify what view a log entry concerns. For
the native and nested backend this is the name of the output the CRTC is
assigned to drive; for X11 it's just "X11 screen", and for the legacy
"X11 screen" emulation mode of the nested backend it's called "legacy
nested".
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1237
There's no reason to notify the surface that its geometry changed when
the visibility of the actor changes. This is only needed to update the
outputs of the surface, so do that directly instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
We started listening to notify::mapped with commit
5eb5f72434 in order to emit
wl_surface.leave events consistently when a surface gets hidden. This
caused a problem with the ClutterClones used in the overview, since
those temporarily map and unmap the windows for painting, spamming
wl_surface.leave and enter events to all surfaces.
We can easily fix that by also treating mapped clones as mapped, which
means the surface should also be on a wl_output when the overview is
shown.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1141https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
All existing users of clutter_actor_has_mapped_clones() actually want to
know whether the actor is being cloned by a visible clone, it doesn't
matter to them if that clone is attached to an actor somewhere else in
the tree or to the actor itself.
So make clutter_actor_has_mapped_clones() a bit more convenient to use
and also check the clones of the parent-actors in that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
We started listening to "notify::position" on surface actors with commit
08e4cb54. This commit was done to fix a regression from commit cf1edff9,
which forgot to handle some cases like the actual WindowActor and not
the SurfaceActor (which is a child of the WindowActor) moving (that was
fixed by listening to MetaWindows "position-changed" signal). Also that
commit introduced meta_wayland_surface_update_outputs_recursively(),
which updates the outputs of all (sub-)surfaces in case any position
changed and made sure subsurfaces also get their outputs updated in case
the parent actor moved.
Connecting to the "notify::position" signal, which the above commit also
did is now superflous though because position changes will queue a
relayout and the actors allocation will change during the next
allocation cycle, notifying the "allocation" property which we also
listen to.
So save some resources and stop listening to that signal.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1235
The comment in _clutter_actor_get_allocation_clip() explicitely notices
that it doesn't need the behavior of doing an immediate relayout as
clutter_actor_get_allocation_box() does. The comment is also still valid
since the code calling _clutter_actor_get_allocation_clip() checks for
priv->needs_allocation just before.
So let's just use the allocation directly here instead of going through
that function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1264
We don't have enough Xlib code in mutter ...
Joking aside, it can be useful to make the cursor invisible
without hiding it, for example for replacing the actual cursor
with an actor in gnome-shell; the real cursor should still
update the focus surface in that case, and not sneak into
screenshots or -casts.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1244
We're iterating inside the PipeWire loop when detecting PipeWire errors,
and shouldn't destroy the PipeWire objects mid-iteration. Avoid this by
first disabling the stream src (effectively stopping the recording),
then notifying about it being closed in an idle callback. The
notification eventually makes the rest of the screen cast code clean up
the objects, including the src and the associated PipeWire objects, but
will do so outside the PipeWire loop iteration.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1251https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
In the native backend, the MetaRenderer manages the view by creating one
per CRTC, but until now the MetaStageX11 managed the view for the X11
backend. This caused some issues as it meant meta_renderer_get_views()
not returning anything, and that the view of the X11 screen not being a
MetaRendererView, while in the other backends, all views are.
Fix this by moving the view management responsibility to
MetaRendererX11Cm, and have MetaStageX11 only operate on it via
meta_renderer_x11_cm_*() API. The MetaRendererX11Cm takes care of making
sure the view is always added to the list in the renderer, and turning
X11 screen sizes into "layouts" etc.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
"Legacy" is a misleading name, it's just how the native backend and the
X11 backend behaves differently. Instead rename it to 'add_view()' and
add the sanity check to the caller.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1251
A DMA buffer might not be able to scanout, and in that case the import
with GBM_BO_USE_SCANOUT will fail. Handle that by failing to scanout,
effectively falling back to compositing.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1261
Since PIDs are inherently insecure because they are reused after a
certain amount of processes was started, it's possible the client PID
was spoofed by the client.
So make sure users of the meta_window_get_pid() API are aware of those
issues and add a note to the documentation that the PID can not be
totally trusted.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
Since the PID of a window can't change as long as the window exists, we
can safely cache it after we got a valid PID once, so do that by adding
a new `window->client_pid` private property.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
The shell uses the PID of windows to map them to apps or to find out
which window/app triggered a dialog. It currently fails to do that in
some situations on Wayland, because meta_window_get_pid() only returns a
valid PID for x11 clients.
So use the client PID instead of the X11-exclusive _NET_WM_PID property
to find out the PID of the process that started the window. We can do
that by simply renaming the already existing
meta_window_get_client_pid() API to meta_window_get_pid() and moving
the old API providing the _NET_WM_PID to meta_window_get_netwm_pid().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1180
ClutterBoxLayout's layout policy of using the generic ClutterActor
align/expand properties for children that are expanded and a custom
meta otherwise is confusing, in particular as the x-fill/y-fill
defaults don't match the default CLUTTER_ACTOR_ALIGN_FILL align.
StBoxLayout's own custom child meta (which was deprecated last
cycle) is probably the only consumer. And luckily, the St meta
uses different x-fill/y-fill default that match the ClutterActor
defaults, so removing it will not affect code that doesn't use
the deprecated properties themselves.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1265
This stuff has been deprecated for a very long time, and given that
ClutterBoxLayout is most commonly used via StBoxLayout, the impact of
removing it should be low. It will however open the door to further
cleanups.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1265
We're going to remove the "allocation-changed" signal from ClutterActor
since it's no longer needed now that ClutterAllocationFlags are gone.
So listen to "notify-allocation" instead, which has been the recommended
thing to do for some time now anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The ABSOLUTE_ORIGIN_CHANGED allocation flag is only really useful to
propagate the information of the absolute origin of an actor having
changed inside Clutter. It wasn't used anywhere else besides for some
debug messages and it probably shouldn't be used in custom layout
implementations anyway since 1) actors shouldn't have to be aware of
absolute allocation changes and 2) it doesn't factor in changes to the
transformation matrix of a parent.
Also the propagation of absolute origin changes using this flag broke
with commit 0eab73dc2e and now hidden actors are no longer notified
about those changes.
Additionally, this flag gets in the way of a few potential optimizations
since it has to be propagated even if the allocation box of the child
hasn't changed, forcing a reallocation of the child.
So replace this flag with a simple new private property of ClutterActor
absolute_origin_changed, but keep the exact same behavior for now.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
Since we now only layout the children ourselves in case the actor
implementation doesn't override the allocate vfunc, we can remove
clutter_actor_maybe_layout_children() and move the functionality inside
clutter_actor_real_allocate().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
Now that we no longer have the DELEGATE_LAYOUT we expect all actors
overriding the allocate() vfunc to allocate their children themselves.
Since clutter_actor_set_allocation() is only called from custom
vfunc_allocate() implementations, the condition in
clutter_actor_maybe_layout_children() would always fail, which makes
calling the function useless anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
The CLUTTER_DELEGATE_LAYOUT flag is unintuitive and makes the allocation
process inside Clutter unnecessarily complicated. It's very easy for
actors overriding the allocate() vfunc to layout their children
themselves (in fact most of them do this), and it also never made sense
that clutter_actor_set_allocation() does eventually layout children.
There was no ClutterActor implementation in mutter or gnome-shell which
actually used the DELEGATE_LAYOUT flag, but even without it, it's fairly
easy to archive the same behavior now: In the allocate() override,
adjust the allocation as wanted, then chain up to the parent vfunc
without calling clutter_actor_set_allocation().
So remove the CLUTTER_DELEGATE_LAYOUT flag, which will allow making the
relayout code in Clutter a bit easier to follow.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
We're going to remove allocation flags, so stop depending on the
DELEGATE_LAYOUT flag in ClutterStage and call
clutter_layout_manager_allocate() directly, which is pretty
straightforward.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1245
They all checked that the remote session service talked with the
correct peer, and some of them did check that there is an associated
screencast session.
Add a new check for the session being started (as it's state is
decoupled with screencast session availability) and move all checks
to a function that is called from all input-oriented DBus methods.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1254https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1258
The public API to get the parent actor, clutter_actor_get_parent() does
a type check whether the actor is actually a ClutterActor. In case of
_clutter_actor_apply_relative_transformation_matrix(), which is called
recursively and very often during the paint process, this type check
shows up with almost twice the amount of hits than the actual matrix
multiplication.
So use the parent pointer directly in some code paths that are executed
very often and avoid the expensive type checking there, we can do that
since both places are not public API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1259
It was removed in 3.34 as part of 6ed5d2e2. And we thought that was the
only thread that might exist and use X11. But the top gnome-shell crasher
in 3.36 seems to suggest otherwise.
We don't know what or where the offending thread is, but since:
1. We used XInitThreads for years already prior to 3.34; and
2. Extensions or any change to mutter/gnome-shell could conceivably use
threads to make X calls, directly or indirectly,
it's probably a good idea to reintroduce XInitThreads. The failing assertion
in libx11 is also accompanied by a strong hint:
```
fprintf(stderr, "[xcb] Most likely this is a multi-threaded client " \
"and XInitThreads has not been called\n");
```
https://bugs.launchpad.net/bugs/1877075
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1252https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1256
Reverting the scale and offset applied to the damage history can be done
in one step, using a few less temporary allocations by passing the
offset right away to a new scale_offset_and_clamp_region() function.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since the damage history region is tracked per-view, all the regions it
includes should be inside the current view anyway, so don't
unnecessarily intersect that region with the view.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since we now check for the buffer age before setting up the
fb_clip_region, that region will be set to the full extents of the view
in case the buffer age is invalid. This in turn means we don't have to
do this again later and can simply fill the damage history with the
fb_clip_region that's already set for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Since a NULL redraw_clip means that a full view redraw should be done
and an empty redraw clip may never be set (see the width/height checks
in clutter_stage_view_add_redraw_clip()), the fb_clip_region should
always be set to a reasonable region that's either the whole view or
individual regions inside the view.
So make sure that's actually the case by warning and that the
fb_clip_region isn't empty, which allows dropping another few lines of
code.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
Right now we're checking for the DISABLE_CLIPPED_REDRAWS debug flag
after creating the fb_clip_region and adjusting the redraw_clip. That
means that if may_use_clipped_redraw was TRUE, the redraw_clip will
still be set to the region and thus cause the stage to only be partially
redrawn. Since we don't push a clip to the framebuffer though
(use_clipped_redraw is now FALSE), parts of the view will get corrupted.
To fix that, disable clipped redraws right away if the debug flag is
set. This also allows removing the may_use_clipped_redraw bool and
replacing it entirely with use_clipped_redraw.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
We already have a better way to paint the redraw clip: Painting the
damage region paints the individual rects of the clip region and not
only the bounding rect.
So stop painting an outline around the redraw clip bounding rect when
CLUTTER_DEBUG_REDRAWS is set.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
While this is meant as an optimzation to only use the scissor clip and
not the stencil buffer if there's only one clip rectangle, it's not
needed since this optimization is going to be applied to region clips
anyway inside _cogl_clip_stack_gl_flush() (see cogl-clip-stack-gl.c).
So remove the unnecessary optimization here and rely on cogl-clip-stack
to do it for us.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
This was introduced with commit 9ab338d7b6 because the clipping of
fractionally scaled redraws caused glitches, it seems like this is no
longer needed nowadays, so let's remove it.
This should make obscured region culling work a bit better for
fractionally scaled framebuffers because because we overdraw a slightly
smaller region than the actually damaged one. We still do overdraw
though since the clipping region is stored using integers and thus
any non-integer values have to be extended to the bounding rect.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
It doesn't make sense to set the redraw clip when painting the stage if
clipped redraws are disabled. That's because when visualizing the redraw
clip and any new redraws are clipped, the old visualiziations would
remain visible, leaving multiple confusing rectangles on the screen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1113
When the wallpaper image is larger than the monitor resolution we already
use mipmapping to scale it down smoothly in hardware. We use
`GL_TEXTURE_MIN_FILTER` = `GL_LINEAR_MIPMAP_LINEAR` for the highest quality
scaling that GL can do. However that option is designed for 3D use cases
where the mipmap level is changing over time or space.
Since our wallpaper is not changing distance from us we can improve the
rendering quality even more than `GL_LINEAR_MIPMAP_LINEAR`. To do this we
now set `GL_TEXTURE_MAX_LEVEL` (if available) to limit the mipmap level or
blurriness level to the lowest resolution (highest level) that is still
equal to or higher than the monitor itself. This way we get the benefits
of mipmapping (downscaling in hardware) *and* retain the maximum possible
sharpness for the monitor resolution -- something that
`GL_LINEAR_MIPMAP_LINEAR` alone doesn't do.
Example:
Monitor is 1920x1080
Wallpaper photo is 4000x3000
Mipmaps stored on the GPU are 4000x3000, 2000x1500, 1000x750, ...
Before: You would see an average of the 2000x1500 and 1000x750 images.
After: You will now only see the 2000x1500 image, linearly sampled.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1003
It's very useful to have common functions for easily creating a monitor
test setup for all kinds of tests, so move create_monitor_test_setup()
and check_monitor_configuration() and all the structs those are using to
monitor-test-utils.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
We're going to move some structs from monitor-unit-tests.c to
monitor-test-utils.h and some names are currently clashing with the
struct names here, so rename those to be specific to the
MonitorStoreUnitTests.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
check_monitor_test_clients_state() is a function that's only meant to be
used in the monitor-unit-tests, and since we're going to move the
functions for creating MonitorTestSetups into a common file, this
function is going to be in the way of that. So move the checking of the
test client state outside of check_monitor_test_clients_state().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
We're going to move the functions for building MonitorTestSetups to the
common monitor-test-utils.c file.
To make building test setups a bit more straightforward in case no
TestCaseExpect is wanted, change create_monitor_test_setup() to take a
MonitorTestCaseSetup instead of a MonitorTestCase as an argument.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1243
Commit e06daa58c3 changed the tested values to use corresponding valid
enum values instead of negative ones. Unfortunately that made one value
become a duplicate of an existing one and also in part defeated the original
intention of checking the implementation of
`meta_output_crtc_to_logical_transform`.
Use `meta_monitor_transform_invert` to fix both shortcomings.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1242
One of the important classes in Mutter's handling of client textures is
the `MetaShapedTexture`. This commit adds a few gtk-doc comments which
explain its purpose, with special attention to the viewport methods.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1210
Since we're now connecting to one more signal of MetaWaylandOutput, keep
signal connections in one place and move connecting the
"output-destroyed" signal to surface_entered_output() and disconnecting
it to surface_left_output().
This also allows us to use the "outputs_to_destroy_notify_id" as a
simple set and rename it to "outputs".
While at it, also use g_hash_table_destroy() instead of
g_hash_table_unref() since destroy is more clear than unref and does the
same thing in this case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
When hotplugging a new monitor, we recreate all the MetaWaylandOutputs
and need to emit leave events to the surfaces for the old wl_outputs and
enter events for the newly created ones.
There's a race condition though: We might update the monitors a surface
is on (and thus emit enter/leave events for the wl_outputs) before the
Wayland client is registered with the new wl_output (ie. the
bind_output() callback of MetaWaylandOutput was called), which means we
don't send an enter event to the client in surface_entered_output().
Since MetaWaylandSurface now has the MetaWaylandOutput in its outputs
hashtable, it thinks the client has been notified and won't send any
more enter events.
To fix that, make MetaWaylandOutput emit a new signal "output-bound"
when a client bound to the output and make all surfaces which are on
that output listen to the signal. In the signal handler compare the
newly added client to the client the surface belongs to, and if it's the
same one, send an enter event to that client.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
The "output-destroyed" signal is used for notifying MetaWaylandSurfaces
that an output they are shown just got invalid (for example because a
monitor hotplug happened).
While we delay the destroying of outputs by 10 seconds since commit
1923db97 because of a race-condition, it doesn't make sense to wait 10
seconds until we let surfaces know that an output was destroyed.
So move the emission of the "output-destroyed" signal to
make_output_inert(), which is called before we start the 10 seconds
delay.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1230
When tiling, we want to set the tile monitor. To not have to do this
from the call site, make meta_window_tile() fall back to the current
monitor if nothing set it prior to the call.
This will make it more convenient for test cases to test tiling
behavior.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The test tests that (for both X11 and Wayland) that:
* The client unmaximizes after mapping maximized to a predictable size
* That the client unmaximizes to the same size after toggling maximize
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
This makes sure that a client has properly responded to a configure
event it itself triggered. In practice, this is just two 'wait'
commands, with a 'dispatch' in between, which is needed because a single
one does not reliably include the two way round trip happening when e.g.
responding to a unmaximize configure event triggered by a unmaximize
request.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The 'assert_size' command checks that the size of the window, both
client side and compositor side, corresponds to an expected size set by
the test case.
The size comparison can only be done when the window is using 'csd', in
order for both the client and server to have the same amount of
understanding of the title bar. For ssd, the client cannot know how
large the title bar, thus cannot verify the full window size.
Sizes can be specified to mean the size of the monitor divided by a
number. This is that one can make sure a window is maximized or
fullscreened correctly.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
Gtk is quite buggy and "fluid" in how it handles the shadow margins for
windows under X11. The "size" of the window fluctuate between including and
excluding a shadow margin in a way that causes issues, as there are no
atomic update of any state going on.
In order to avoid running into those particular issues now, lets get rid
of shadows so the margins are always zero, when the client is using the
X11 backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
To get some kind of consistency between what 'resize' means for the
compositor and the client, make the size correspond to the "frame rect"
of the window, i.e. the window geometry in the Wayland case, and the
window size including the titlebar in the X11 case.
This is so that the window size later can be reliably compared both in
the compositor and in the client using the same expected dimensions.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
When toying with the test client to try to reproduce issues (e.g.
writing commands on stdin to create and manipulate windows), when you
write a command incorrectly you'll get a warning printed to standard
out. The problem, however, is that it doesn't include a line break in
the end, meaning when you type the correct command, it won't be on a new
line.
Fix this minor annoyance by adding line breaks to all warning messages.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
The test client could already understand the resize command, but they
could not be added to metatests as the command was not properly plumbed
via the test runner. Establish the plumbing for the resize command so
that resize tests can be added.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1171
We only test the meson-build job, so there's no point to save artifacts for
the other test-build only builds.
So, only save meson logs artifacts (with a default gitlab expiration time)
for the other build-without-* jobs
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1236
While we don't have an high number of tests, we still have some code
coverage and so we can track this via gitlab CI, given that it supports it
natively.
So add gcovr to the DockerFile dependency, build with -Db_coverage=true
meson native parameter, and add another manual job to make ninja to generate
the coverage reports on requests or in any master or tag ref.
Keep the artifacts around to be able to browse the generated HTML files and
eventually print the text reports so that they can be parsed by gitlab.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1236
This removes ClutterAnimation and related tests. ClutterAnimation has
been deprecated for a long time, and replacements exist and are used by
e.g. GNOME Shell since a while back.
This also disables a few relatively unrelated interactive tests, as they
rely on ClutterAnimation to implement some animations they use to
illustrate what they actually test.
As interactive tests currently are more or less untestable due to any
interaction with them crashing, as well as they in practice means
rewriting the tests using non-deprecated animation APIs, they are not
ported right now. To actually port the interactive tests, it needs to be
possible to fist interact with them.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1192
In the past, it was a odd mix of possible different types, all coalesced
into an unsigned integer. Now, hovewer, it's always a
ClutterAnimationType, so lets change the name of getter, setter and
property to what it really is.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1192
When memfd_create isn't used, the file isn't sealed. Therefore, we
should skip test_readonly_seals on the fallback case. This fixes
compilation error on FreeBSD 12, which does not support memfd_create.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1229
We were iterating through evcodes, but using API that expects Clutter button
numbers. Instead of transforming those to Clutter numbers to have those translated
back, use the inner seat API that already takes evcodes.
Fixes stuck buttons keys after a virtual device is destroyed while those are
pressed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1239
The CLUTTER_ACTOR_IN_REPARENT and the CLUTTER_IN_REPARENT flag are never
set and the logic for skipping unmap, unrealize and the emission of the
"parent-set" signal during reparents has been solved differently by
leaving out the CHECK_STATE and EMIT_PARENT_SET flags when calling
add_child_internal() and remove_child_internal().
The only place where those REPARENT flags are theoretically still useful
is in the clutter_actor_verify_map_state() debugging function, but that
is never called during reparent anyway, so simply leave the comment
regarding reparent there.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1228
Move to center uses all monitors for calculating work area.
This can lead to an unexpected behaviour on some monitor
configurations resulting in current window being split between
monitors. We should move window to the center of the active display.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/1073
Inhibiting remote access means any current remote access session is
terminated, and no new ones can be created, until remote access is
uninhibited. The inhibitation is ref counted, meaning there can be more
than one inhibitor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1212
When resizing an X11 window with client side decorations, the shadow is
clipped by the frame bounds so that we don't need to paint the shadow
under the opaque areas covered by the window and its frame.
When the X11 client uses the EMWH synchronization mechanism (like all
gtk-3 based clients), the actual window may not be updated so that the
actual window and it frame may be behind the expected window frame
bounds, which gives the impression of de-synchronized shadows.
To avoid the issue, keep a copy of the frame bounds as a cache and only
update it when the client is not frozen so that the clipping occurs on
the actual content.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1178https://gitlab.gnome.org/GNOME/mutter/merge_requests/1214
The redraw clip that's painted together with the damage region has to be
copied earlier than we do right now. That's because if
PAINT_DAMAGE_REGION is enabled, buffer age is disabled and thus
use_clipped_redraw is FALSE. That means the redraw_clip is updated and
set to the full view-rect. If we copy the queued_redraw_clip after that,
it's also going to be set to the full view-rect. So copy the redraw clip
a bit earlier to make sure we're actually passing the real redraw clip
to paint_damage_region().
Also keep the queued_redraw_clip around a bit longer so it can actually
be used by paint_damage_region() and isn't freed before that.
While at it, move paint_damage_region() from swap_framebuffer() into
clutter_stage_cogl_redraw_view() so we don't have to pass things to
swap_framebuffer() only for debugging.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1104https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1208
It takes coordinates in stage coordinate space, and will result in
a screen cast stream consisting of that area, but scaled up by the scale
factor of the view that overlaps with the area and has the highest scale
factor.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Will be used by the stage to not paint the overlays. We skip all
overlays since overlays are only ever used for pointer cursors when the
hardware cursors cannot or should not be used.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
These phase callbacks are not intended to be inovked when something
secondary is painting the stage, such as a screen cast stream, or
similar. Thus, only invoke the callbacks when there is a view associated
with the paint context, which will not be the case for offscreen
painting.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
Either onto a framebuffer, or into a CPU memory buffer. The latter will
use an former API and then copy the result to CPU memory. The former
allocates an offscreen framebuffer, sets up the relevant framebuffer
matrices and paints part of the stage defined by the passed rectangle.
This will be used by a RecordArea screen cast API. The former to paint
directly onto PipeWire handled dma-buf framebuffers, and the latter for
PipeWire handled shared memory buffers.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If there is a paint context available (i.e. for the phases that are
during the actual stage paint), pass it along the callbacks, so that
the callback implementations can change their operation depending on the
paint context state.
This also means we can get the current view from the paint context,
instead of the temporarily used field in the instance struct.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
A paint flag affects a paint operation in ways defined by the flags.
Currently no flags are defined, so no semantical changes are defined
yet. Eventually a flag aiming to avoid painting of cursors is going to
be added, so that screen cast streams can decide whether to include a
cursor or not.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1207
If drmModePageFlip() or custom_page_flip_func fails, process_page_flip() was
forgetting to undo the ref taken for that call. This would leak page_flip_data.
The reference counting works like this:
- when created, ref count is 1
- when calling drmModePageFlip, ref count is increased to 2
- new: if flip failed, ref count is decreased back to 1
- if calling schedule_retry_page_flip(), it takes a ref internally
- if calling mode_set_fallback(), it takes a ref internally
- all return FALSE paths have an explicit unref
- return TRUE path has an explicit unref
This issue was found by code inspection and while debugging an unrelated issue
with debug prints sprinkled around. I am not aware of any end-user visible
issues being fixed by this, as the leak is small and probably very rare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
When testing a laptop with intel and DisplayLink devices, attempting to set the
DL output as the only active output resulted in GNOME/Wayland freezing. The
main event loop was running fine, but nothing on screen would get updated once
the DL output become the only one. This patch fixes that issue.
DisplayLink USB 3 devices use an out-of-tree kernel DRM driver called EVDI.
EVDI can sometimes fail drmModePageFlip(). For me, the flip fails reliably when
hotplugging the DL dock and when changing display configuration to DL only.
Mutter has a workaround for failing flips, it just calls drmModeSetCrtc() and
that succeeds.
What does not work reliably in the fallback path is Mutter keeping track of the
pageflip. Since drmModePageFlip() failed, there will not be a pageflip event
coming and instead Mutter queues a callback in its stead. When you have more
than one output, some other output repainting will attempt to swap buffers and
calls wait_for_pending_flips() which has the side-effect of dispatching any
queued flip callbacks. With multiple outputs, you don't get stuck (unless they
all fail the exact same way at the same time?). When you have only one output,
it cannot proceed to repaint and buffer swap because the pageflip is not marked
complete yet. Nothing dispatches the flip callback, leading to the freeze.
The flip callback is intended to be an idle callback, implemented with a
GSource. It is supposed to be called as soon as execution returns to the main
event loop. The setup of the GSource is incomplete, so it will never dispatch.
Fix the GSource setup by setting its ready-time to be always in the past. That
gets it dispatched on the next cycle of the main event loop. This is now the
default behavior for all sources created by meta_kms_add_source_in_impl().
Sources that need a delay continue to do that by overriding the ready-time
explicitly.
An alternative solution could have been to implement GSource prepare and check
callbacks returning TRUE. However, since meta_kms_add_source_in_impl() is used
by flip retry code as well, and that code needs a delay through the ready-time,
I was afraid I might break the flip retry code. Hence I decided to use
ready-time instead.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1209
According to the XSetSelectionOwner libX11 documentation:
[...] If the owner window it has specified in the request is later
destroyed, the owner of the selection automatically reverts to None,
but the last-change time is not affected.
This is indeed visible through the selection_timestamp field in
XFixesSelectionNotify events.
Use this to check whether the selection time is recent-ish (thus
likely coming from an explicit XSetSelectionOwner request) and honor
the client intent by setting a "NULL" owner. If the selection time
is too old, it's definitely an indication of the owner client being
closed, the scenario where we do want the clipboard manager to take
over.
This fixes two usecases:
- X11 LibreOffice / WPS clear the selection each time before copying
its own content. Mutter's clipboard manager would see each of those
as a hint to take over, competing with the client over selection
ownership. This would simply no longer happen
- Password managers may want to clear the selection, which would be
frustrated by our clipboard manager.
There's a slight window of opportunity for the heuristics to fail
though, if a X11 client sets the selection and closes within 50ms, we
would miss the clipboard manager taking over.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
The X11 selection source was being preserved after unsetting its
ownership. This is no leak as it would be eventually replaced by
another source, or destroyed on finalize. But it's pointless to
keep it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1206
Test the two modes of MetaAnonymousFile, MAPMODE_SHARED and
MAPMODE_PRIVATE and make sure they don't leak data to other FDs when
writing to an FD provided by `meta_anonymous_file_get_fd` even though
the data of both FDs is residing in the same chunk of memory.
We do all the reading tests using mmap instead of read() since using
read() on shared FDs is going to move the read cursor of the fd. That
means using read() once on the shared FD returned by
meta_anonymous_file_get_fd() in MAPMODE_PRIVATE breaks every subsequent
read() call.
Also test the fallback code of MetaAnonymousFile in case `memfd_create`
isn't used for the same issues.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
Add MetaAnonymousFile, an abstraction around anonymous read-only files.
Files can be created by calling meta_anonymous_file_new(), passing the
data of the file. Subsequent calls to meta_anonymous_file_open_fd()
return a fd that's ready to be sent over the socket.
When mapmode is META_ANONYMOUS_FILE_MAPMODE_PRIVATE the fd is only
guaranteed to be mmap-able readonly with MAP_PRIVATE but does not
require duplicating the file for each resource when memfd_create is
available. META_ANONYMOUS_FILE_MAPMODE_SHARED may be used when the
client must be able to map the file with MAP_SHARED but it also means
that the file has to be duplicated even when memfd_create is available.
Pretty much all of this code was written for weston by Sebastian Wick,
see https://gitlab.freedesktop.org/wayland/weston/merge_requests/240.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1012
Instead of having everything clumped at MetaWaylandDataManager,
split the primary selection to its own struct. This manager is
handled separately from wl_data_device_manager and other selection
managers, so they would be able to interoperate between them, even.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
This is still an openly defined struct, as we will need accessed
by "subclasses". Same principle applies than with the
MetaWaylandDataSource refactor, this is not meant to introduce
functional changes, so just go with it.
On the bright side, the interactions are now clearer, so it could
be made saner in the future.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
The split wasn't 100% clean, and some extra private API had to be
added for it (but well, looking at the API, it's already evident
there's a cleanup/streamlining task due). This is meant to be a
refactor with no functional changes, so just go with it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1193
We already have a signal callback that translates selection ownership changes to
data_device/primary .selection events. Given both will be run when a data source
is being replaced, and this event emission being deleted is kinda short sighted
in that in only knows about Wayland, rely entirely on MetaSelection::owner-changed
emission.
Fixes spurious .selection(null) events being sent when a compositor-local source
takes over the selection without the focus changing (eg. screenshot to clipboard).
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1160https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1204
We are meant to send a .cancelled event after the drop is performed
in certain situations, but only for version>3 clients. Since this is
all version 3 business, only set the drop_performed flag for v3
clients. This drops the need to perform version checks at the time
of cancelling (which is present for other usecases in v1).
Fixes emission of wl_data_source.cancelled for v1 clients.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1177https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1203
For the cases where we read a fixed size from the selection (eg. imposing
limits for the clipboard manager), g_input_stream_read_bytes_async() might
not read up to this given size if the other side is spoonfeeding it content.
Cater for multiple read/write cycles here, until (maximum) transfer size is
reached.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
Flushing the X11 selection output stream may happen synchronously or
implicitly, in which case there is not a task to complete. Check there
is actually a task before returning errors. We additionally set the
pipe_error flag, so future operations will fail with an error, albeit
with a more generic message.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If a write_async() comes up while we are flushing on the background,
the task will be queued, but not deemed a reason on itself to keep
flushing (and finish the task) after a property delete event.
To fix this, do not ever queue up write_async tasks (this leaves
priv->pending_task only used for flush(), so the "flush to end"
behavior in the background is consistent). We only start a
background flush if there's reasons to do it, but the tasks are
immediately finished.
All data will still be ensured to be transfered on flush/close,
this makes the caller in this situation still able to reach to it.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
It does not make sense to check for the stream not being closed,
this might happen multiple times during the lifetime of the stream
for a single transfer. We want to notify the INCR transfer just
once.
Check for the explicit conditions that we want, that the remaining
data is bigger than we can transfer at once, and that we are not
yet within the INCR transfer.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
The stream automatically flushes after data size exceeds the
size we deem for INCR chunks, but we still try to copy it all.
Actually limit the data we copy, and leave the rest for future
INCR chunks.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
INCR transfers are mandated to finish with a final 0-size XChangeProperty
roundtrip after the final data chunk. Actually honor this and ensure we
iterate just once more for this.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
This seemed to work under the assumption that a flush() call can
only result in one INCR roundtrip. This is evidently not true, so
we should hold things off until all pending data is actually flushed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
If say we want 32bit data, but have 2 bytes stored, we would simply
ignore flush requests. Allow (and don't clear) the needs_flush flag
if we have less than the element size accumulated.
Instead handle this in can_flush(), so it's triggered whenever we
have enough data to fill 1 element, or if the stream is closing
(seems a broken situation, but triggered by the caller).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
XMaxRequestSize/XMaxExtendedRequestSize are documented to return
the maximum size in 4-byte units, whereas we are comparing this
to byte lenghts. We can afford 4x the data here.
Since I don't know the payload size of the XChangeProperty request,
be generous and allot 400 bytes for it, we have some to spare.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1198
When closing the lid of a laptop, we reconfigure all the monitors in order
to update the CRTCs and (if enabled) the global UI scaling factor.
To do this, we try first to reuse the current configuration for the usable
monitors, but if we have only monitor enabled and this one is on the laptop
lid we just end up creating a new configuration where the primary monitor is
the laptop one (as per find_primary_monitor() in MetaMonitorConfigManager),
but ignoring the user parameters.
In case the user selected a different resolution / scaling compared to the
default one, while the laptop lid is closed we might change the monitors
layout, causing applications to rescale or reposition.
To avoid this, when creating the monitors configuration from the current
current state, in case we have only one monitor available and that one is
the laptop panel, let's just reuse this configuration.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1200
Try to bypass compositing if there is a fullscreen toplevel window with
a buffer compatible with the primary plane of the monitor it is
fullscreen on. Only non-mirrored is currently supported; as well as
fullscreened on a single monitor. It should be possible to extend with
more cases, but this starts small.
It does this by introducing a new MetaCompositor sub type
MetaCompositorNative specific to the native backend, which derives from
MetaCompositorServer, containing functionality only relevant for when
running on top of the native backend.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
We need to coordinate with MetaCompositor during pre-paint so that we
have control over whether MetaLater callbacks happen first, or the
MetaCompositor pre-paint logic.
In order to do so, make MetaLater listen to a new signal "pre-paint" on
MetaCompositor, that is called MetaCompositors own pre-paint handling.
This fixes an issue where the top window actor was calculated after the
MetaCompositor pre-paint handling, meaning the top actor being painted
was out-of-date.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Since the order of destruction during MetaDisplay tear down is a bit
unordered, there are pieces that try to destruct its compositing
dependent pieces (i.e. queued MetaLater callbacks) after MetaCompositor
has been cleaned up, meaning we need to put some slightly awkward NULL
checks to avoid crashing.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
MetaCompositor is the place in mutter that manages the higher level
state of compositing, such as handling what happens before and after
paint. In order for other units that depend on having a compositor
instance active, but should be initialized before the X11 implementation
of MetaCompositor registers as a X11 compositing manager, split the
initialization of compositing into two steps:
1) Instantiate the object - only construct the instance, making it
possible for users to start listening to signals etc
2) Manage - this e.g. establishes the compositor as the X11 compositing
manager and similar things.
This will enable us to put compositing dependent scattered global
variables into a MetaCompositor owned object.
For now, compositor management is internally done by calling a new
`meta_compositor_do_manage()`, as right now we can't change the API of
`meta_compositor_manage()` as it is public. For the next version, manual
management of compositing will removed from the public API, and only
managed internally.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While at it, fix some style inconsistencies, for now use a single
singleton struct instead of multiple static variables, and
other non-functional cleanups. Semantically, there is no changes
introduced.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This will check whether the current backing buffer is compatible with
the primary plane of the passed CoglOnscreen. Since this will extend the
time before a buffer is released, the MetaWaylandBufferRef is swapped
and orphaned if a new buffer is committed before the previous one was
released. It'll eventually be released, usually by the next page flip
callback.
Currently implemented for EGLImage and DMA-BUF buffer types.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Advertising support for modifiers means we will most likely not not be
able to scan out client buffers directly, meaning it just as likely that
we won't be able to scan out even fullscreen windows without atomic KMS.
When we have atomic support, we should advertise support for modifiers
if atomic is used to drive the CRTCs, as we by then can check whether we
can scan out directly, place in an overlay plane, etc.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
While this is fairly incomplete, as to check things fully we need to use
TEST_ONLY in atomic to try out a complete assignment on the device, but
this works well enough for legacy non-modifier cases.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Make it possible to cause the next frame to scan out directly from the
passed CoglScannout. This makes it possible to completely bypass
compositing for the following frame.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Instead of always swapping buffers and flipping the back buffer, make it
possible to scan out a provided buffer directly without swapping any EGL
buffers.
A buffer is passed as an object implementing the empty CoglScanout
interface. It is only possible to do this in the native backend; and the
interface is implemented by MetaDrmBufferGbm. When directly scanned out,
instead of calling gbm_surface_lock_front_buffer() to get the gbm_bo and
fbid, get it directly from the MetaDrmBufferGbm, and use that to create
the page flip KMS update.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Transitions are used for animating actors when e.g. going from/to
fullscreen, and the like. We need to know such things when deciding
whether to avoid compositing a window actor, so make add API visible to
mutter that checks whether there are any transitions active.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Better to have the relevant object figure out whether it is a good
position to be unredirectable other than the actor, which should be
responsible for being composited.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
This removes the MetaWindowX11::priv pointer. It is replaced with a
meta_window_x11_get_private() helper function, and another method to get
the client rect without going through MetaWindowX11Private.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Surface buffers are created with meta_drm_buffer_new_acquire(), taking a
gbm_surface acquiring the gbm itself, and meta_drm_buffer_new_take()
that takes over ownership of a passed gbm_bo.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
Currently a buffer use count always reaches zero before it is replaced.
This is due to the fact that at the point a new buffer is attached, the
last potential user releases it (the stage) since the currently
displayed frame has a composited copy of the buffer.
This may however change, if a buffer is scanned out directly, meaning it
should not be released until the page flip callback is invoked.
Prepare for this by making the buffer reference a heap allocated struct,
enabling us to keep a pointer to it longer than the buffer is attached.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/798
The CRTC level transform (not necessarily the hw transform) must be
taken into account when calculating the position of the CRTC in the
stage coordinate space, when placing the hw cursor, otherwise we'll
place the cursor as if the monitor was not rotated.
This wasn't a problem in the past, as with rotation, we always used the
OpenGL cursor, so the issue newer showed.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
The port to per CRTC views was incomplete; we still used the logical
monitor layout as the stage view layout, while still using one view per
CRTC.
This worked fine for most cases, e.g. regular monitors, tiled or
non-tiled, transformed or non-transformed. Where it broke, however, was
when a monitor consists of multiple CRTCs. We already have the layout a
CRTC corresponds to on the stage kept with the CRTC metadata, so use
this directly.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1170https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199`
The CRTC level transform (i.e. not necessarily the one set on the
hardware) is what is relevant for calculating the layout the CRTC will
have on the stage, so only use the one that can be handled by the
hardware for the CRTC assignment.
This makes the CRTC layout valid for tiled monitors.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
Previously the tile coordinate was used to offset a CRTC scanout
coordinate within a larger framebuffer. Since 3.36 we're always
scanning out from (0, 0) as we always have one framebuffer per CRTC; we
instead use the tile coordinate to calculate the coordinate the tile has
in the stage view. Adapt calculation to fulfil this promise instead of
the old one.
This also corrects the tiled custom monitor test case.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1199
test_client_new might return early if conditions are not met, leaving some
allocated data around without freeing it.
Since we're not using the client before, there's no need to initialize it early
and just initialize it when it's going to be returned.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1195
Dereference the loop variable rather than the original list head. This
fixes a regression introduced in 4413b86a3 ("backends: Replace
ClutterDeviceManager usage in favor of ClutterSeat", 2019-10-04) which
broke button scrolling with trackballs.
Closes:https://gitlab.gnome.org/GNOME/mutter/-/issues/1120
Most visible with xwayland-on-demand, at the time of setting things up
for X11 selections, we don't forward the current state. This makes the
first started X11 app oblivious to eg. the current clipboard.
Syncing selections up at the time of initializing the X11 selection
stuff ensures that doesn't happen.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1186
click_action_query_long_press() can potentially schedule more than
one timeout, since it doesn't clear any already-existing timeout.
Make sure to clear the long press timeout before scheduling a new
one.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
Like the click action, it makes sense to cancel the ongoing gesture
when the action is disabled. Do so by overriding our new friend,
ClutterActorMeta.set_enabled, and canceling the gesture when disabling
the action.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
ClutterClickAction, like other actions, can potentially be disabled
at any time (that is not during painting). When that happens with
ClutterClickAction, it must release all timeouts and disconnect from
the stage's 'capture-event'.
Override ClutterActorMeta.set_enabled and release the click action
when the action is being disabled.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1188
Various subclasses of ClutterActorMeta need to reacto to being
disabled. Right now, however, the only way to do that is by
overriding GObject's 'notify' vfunc, and doing a string comparison
against "enabled".
Add a new vfunc to ClutterActorMeta in order to replace this bad
practice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1187
On VT switch, the devices are removed, which means for Wayland disabling
the keyboard.
When the keyboard is disabled, the associated `xkb_state` is freed and
recreated whenever the keyboard is re-enabled when switching back to the
compositor VT.
That means the `xkb_state` for Wayland is lost whereas the same for
clutter is kept, which causes to a discrepancy with locked modifiers on
VT switch.
To avoid that issue, preserve the XKB info only to dispose it when the
keyboard is eventually finalized.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/344https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1185
In the unlikely case we have multiple rectangles in our selection
(selection spanning several lines, or across LTR/RTL bounds), paint each
of those instead of setting a CoglPath-based clip/fill.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1126
The motion events of tablets for example need to be mapped on the
selected screen area if the input device is configured to use only a
part of the active logical monitor.
To achieve this behavior each motion event is transformed using the
transformation matrix set for the input device.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1118
At some point we crossed the streams... In a short timespan we had
1f00aba92c merged, pushing WacomDevice to a common parent object,
and dcaa45fc0c implementing device grouping for X11.
The latter did not rely on the former, and just happened to
merge/compile without issues, but would promptly trigger a crash
whenever the API would be used.
Drop all traces of the WacomDevice internal to MetaInputDeviceX11.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1183
With the introduction of "shallow" relayouts, we are now able to enter
allocation cycles not only at the stage but also deeper down the
hierarchy if we know an actors allocation isn't affected by its children
since the NO_LAYOUT flag is set.
Now that means when queuing relayouts it's possible that
`priv->needs_allocation` gets set to TRUE for some actors down the
hierarchy, but not for actors higher up in the hierarchy. An actor tree
where that happens could look like that:
stage -> container -> container2 (NO_LAYOUT) -> textActor
With that tree, if the "textActor" queues a relayout, "container2" will
be added to the relayout hashtable of the stage and the actors "stage"
and "container" will have `priv->needs_allocation` set to FALSE.
Now if another relayout on the stage actor is queued,
`clutter_stage_queue_actor_relayout()` currently removes all the other
hashtable entries in favour of the stage entry, (wrongly) assuming that
will allocate everything. It doesn't allocate everything because in the
example above "container" has `priv->needs_allocation` set to FALSE,
which makes clutter_actor_allocate() return early before allocating its
children, so in the end "container2" will never get a new allocation.
To fix this, stop flushing the relayout hashtable when queuing a
stage-relayout and still add new entries to the hashtable if a stage
relayout is already queued to make sure we still go through all the
previously queued "shallow" relayouts. That shouldn't hurt performance,
too, because as soon as an actor got allocated once, it doesn't need an
allocation anymore and should bail out in clutter_actor_allocate() as
long as it's absolute position didn't change.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1173
We have branched now, time for a shiny new CI image.
Update the Dockerfile to:
- switch to F32
- use a single shared copr
- drop dependencies that are now covered by builddep
- do not include weak deps
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1176
Currently we check whether a window is alive everytime it's focused.
This means that an application that doesn't respond to the check-alive
event during startup always showing the "application froze" dialog,
without the user ever trying to interact with it.
An example where this tends to to happen is with games, and for this
particular scenario, it's purely an annoyance, as I never tried to
interact with the game window in the first place, so I don't care that
it's not responding - it's loading.
To avoid these unnecessary particular "app-is-frozen" popups, remove the
alive check from the focus function, and instead move it back to the
"meta_window_activate_full()" call. To also trigger it slightly more
often, also add it to the path that triggers the window focus when a
user actively clicks on the window.
This means that we currently check whether a window is alive on:
* Any time the window is activated. This means e.g. alt-tab or
selecting the window in the overview.
* The user clicks on the window.
Note that the second only works for an already focused window on
Wayland, as on X11, we don't refocus it. This particular case isn't
changed with this commit, as we didn't call meta_window_focus() to begin
with here.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1182
This fixes an issue where a non-maximized screen casted window would be
stretched to fill the whole screen cast stream, instead of just the crop
that corresponds to the current window size.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1174
It isn't immediately obvious that this is impossible, because there's some
"action at a distance" going on with framebuffers that have their size
set lazily, after their textures get allocated; so let's make this a
critical warning rather than crashing.
In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.
Workaround for <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538>.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1172
Signed-off-by: Simon McVittie <smcv@debian.org>
A texture with no pixels isn't a useful thing to have, and breaks
assumptions elsewhere. For example, CoglFramebuffer assumes that after
a texture has been allocated, it will have width and height both greater
than 0.
In particular, this works around a crash when gnome-shell tries to blur a
background that hasn't yet had any space allocated for it - which it seems
is really an actor layout bug, but more robustness seems good to have.
Workaround for <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2538>.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1172
Signed-off-by: Simon McVittie <smcv@debian.org>
Disabling a click action after a button-press but before a
button-release is captured makes ClutterClickAction connect to
captured-event and never disconnect.
This change fixes it by making sure the captured-event is only
processed if the action is still enabled, otherwise releasing
the action (reset state) and propagating the event.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1170
Nothing should ever disable an actor modifier (e.g. effect) during the
paint sequence, nor should any actor be set or unset on it. If this
would happen, log warnings so that it can be tracked down.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1166
Picking now only happens on allocated actors, but the
callback in the actor-pick test is not waiting for the
stage to run an allocation cycle. Ideally, we'd wait
for this cycle, but for now, forcing an allocation works
as well.
Allocate the overlay actor in the actor-pick test.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1169
When selecting the pick regions for an actor we were not considering
whether the actor was allocated and that was causing issues where the
preferred width/height of the actor was used when deciding whether
the actor should be considered as a pick target.
Check if the actor has a valid allocation, in addition to being mapped
and being in pick mode, in clutter_actor_should_pick_paint().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1169
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
