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