In profilers with a timeline or flame graph views it is a very common
scenario that a span name must be displayed in an area too short to fit
it. In this case, profilers may implement automatic shortening to show
the most important part of the span name in the available area. This
makes it easier to tell what's going on without having to zoom all the
way in.
The current trace span names in Mutter don't really follow any system
and cannot really be shortened automatically.
The Tracy profiler shortens with C++ in mind. Consider an example C++
name:
SomeNamespace::SomeClass::some_method(args)
The method name is the most important part, and the arguments with the
class name will be cut if necessary in the order of importance.
This logic makes sence for other languages too, like Rust. I can see it
being implemented in other profilers like Sysprof, since it's generally
useful.
Hence, this commit adjusts our trace names to look like C++ and arrange
the parts of the name in the respective order of importance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3402>
When the desktop is focused instead of a window we want to tell the core
about this to handle focus-mode mouse. This is handled by looking for
CLUTTER_LEAVE events where the newly focused window is NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
The following commits will make it possible to pass a NULL window to
display_handle_window_enter/leave to represent the cursor entering the
desktop. This means it can't be a method of the window class anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3258>
To make sure a new wl_subsurface created for the same wl_surface won't
inherit the position from the wl_subsurface being destroyed.
v2:
* Move into permanently_unmap_subsurface
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
Instead of duplicating the code in both.
v2:
* Rename helper to make it clear(er) that it permanently unmaps the
sub-surface
* Move transaction allocation & commit into the helper
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
wl_subsurface_place_above/below need to hook it up to the parent
surface's pending state, so that it gets picked up next time the parent
is committed.
v2:
* Adapt to wl_subsurface_destructor not resetting sub-surface position
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is simpler, and makes sure it's called only once for each surface
in the transaction as committed.
v2:
* Use array for surface states with placement ops (Jonas Ådahl)
v3:
* Use GPtrArray instead of GArray (Robert Mader)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
This is necessary to make sure the unmapped sub-surface is no longer
visible.
v2:
* Use META_IS_WAYLAND_SUBSURFACE (Jonas Ådahl)
* Use same sequence of assignments in both cases
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3364>
- Make Texture a parent GObject class and move the vtable funcs as vfuncs
instead of an interface as we would like to have dispose free the TextureLoader.
- Make the various texture sub-types inherit from it.
- Make all the sub-types constructors return a CoglTexture instead of their respective
specific type. As most of the times, the used functions accept a CoglTexture,
like all the GTK widgets constructors returning GtkWidget.
- Fix up the basics of gi-docgen for all these types.
- Remove CoglPrimitiveTexture as it is useless: It is just a texture underhood.
- Remove CoglMetaTexture: for the exact same reason as above.
- Switch various memory management functions to use g_ variant instead of the cogl_ one
Note we would still want to get rid of the _cogl_texture_init which is something
for the next commit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3193>
There are existing extensions that implement desktop icons as
a combination of a GTK program and a small extension to make
the wayland window behave as if it was of type DESKTOP on X11.
That's quite painful, as it requires reimplementing WM behavior
that is already implemented in mutter itself (stacking, stickiness,
skip-taskbar, ...), as well as modifying gnome-shell to consider
the window in addition to "real" DESKTOP windows (workspace-switch
animations, ctrl-alt-tab, ...).
In addition to that, other extensions may also have special handling
of DESKTOP windows, and their code cannot easily be monkey-patched
to handle "alternative" desktop icons.
This whole game of whack-a-mole can easily be avoided by allowing
desktop-icons extensions to mark their desktop windows as DESKTOP,
so do just that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3305>
Change the order of events to adhere to the Wayland specification for
wl_keyboard.enter, which mandates:
> The compositor must send the wl_keyboard.modifiers event after
> this event.
Mutter currently sends the modifiers event before the enter event,
which may break applications that require information about the focused
surface in order to properly handle the modifiers.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2231
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3341>
With EI support wired to XTEST, and oeffis being enabled in Xwayland
means that XTEST will always go through the XDG portal.
While this the intended behavior for the general use case of Xwayland
running rootless on a desktop compositor, that breaks when Xwayland is
running on a nested compositor, because the portal is for the entire
session and not limited to the nested Wayland compositor.
Enable XDG portal support in Xwayland only when we managed to connect
to the GNOME session manager, which means we are running in a full
desktop session, and not in any form of nested mode.
This is determined by simply using the status returned by set_gnome_env()
which will fail if not connected to a GNOME Session manager.
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1586
See-also: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1170
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3047
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
The function set_gnome_env() is used to pass environment variables
though DBus using the "org.gnome.SessionManager".
If that fails, it means we are not running in a full environment, which
might be useful to determine whether Xwayland should enable the portal
support.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3303>
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>
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>
Dropped obsolete Free Software Foundation address pointing
to the FSF website instead as suggested by
https://www.gnu.org/licenses/gpl-howto.html
keeping intact the important part of the historical notice
as requested by the license.
Resolving rpmlint reported issue E: incorrect-fsf-address.
Signed-off-by: Sandro Bonazzola <sbonazzo@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3155>
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>
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>
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>
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>
To be able to later support more complex YUV formats, we need to make
sure that MetaShapedTexture (the one who will actually render the
texture) can use the MetaMultiTexture class.
Co-Authored-By: Robert Mader <robert.mader@collabora.com>
Co-Authored-By: Daniel van Vugt <daniel.van.vugt@canonical.com>
Co-Authored-By: Sebastian Wick <sebastian.wick@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2191>
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>
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>
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>
Implement the stable rounding algorithm as described in the discussions
for the fractional-scale-v1 protocol.
This adds an override of the ClutterActor::apply_transform vfunc for
MetaSurfaceActorWayland that ensures the size and position of the
contents of the surface are rounded according to the stable rounding
algorithm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
Otherwise binding new wl_output's might try to send enter to the
destroyed resource. Fixes the following crash:
#0 wl_resource_get_client at ../src/wayland-server.c:801
#1 handle_output_bound at ../src/wayland/meta-wayland-surface.c:1287
#3 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3812
#6 ffi_call_unix64 at ../src/x86/unix64.S:104
#7 ffi_call_int at ../src/x86/ffi64.c:673
#8 ffi_call at ../src/x86/ffi64.c:710
#9 wl_closure_invoke at ../src/connection.c:1025
#10 wl_client_connection_data at ../src/wayland-server.c:438
#11 wl_event_loop_dispatch at ../src/event-loop.c:1027
#12 wayland_event_source_dispatch at ../src/wayland/meta-wayland.c:125
#15 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#17 meta_context_run_main_loop at ../src/core/meta-context.c:482
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2196527
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2992>
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 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>
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>
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>
