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>
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>
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>
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>
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>
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>
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>
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>
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>
'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 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>
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>
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>
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>
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 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 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>
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>
