This is helpful when we add callbacks that should be dispatched in the
KMS impl thread.
This invalidates an assumption about callbacks not being in the impl
context, so some asserts for that are also removed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This signal is emitted before terminating the thread, but also when
resetting the thread type. This is to allow thread implementations to
make sure they have no stale pending callbacks to any old main contexts.
This commit "terminates" the impl thread even if there is no actual
thread; this is to trigger the "reset" signal, also when switching from
a user thread to a kernel thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means we can add COGL_TRACE*() instrumentation that is grouped
correctly in sysprof. If kernel threading is enabled, they will end up
in a "Compositor (KMS thread)" group (ignoring translations).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Real time scheduling is needed for better control of when we commit
updates to the kernel, so add a property to MetaThread that, if the
thread implementation uses a kernel thread and not a user thread, RTKit
is asked to make the thread real time scheduled using the maximum
priority allowed.
Currently RTKit doesn't support the GetAll() D-Bus properties method, so
some fall back code is added, as GDBusProxy depends on GetAll() working
to make the cached properties up to date. Once
https://github.com/heftig/rtkit/pull/30 lands and becomes widely
available in distributions, the work around can be dropped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Also add an API to inhibit the kernel thread from being used, and make
MetaRenderDeviceEglStream inhibit the kernel thread from being used if
it's active.
The reason for this is that the MetaRenderDeviceEGlStream is used when
using EGLStreams instead of KMS for page flipping. This means the actual
page flipping happens as a side effect of using EGL/OpenGL, which can't
easily be done off thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This will be necessary in order to default to 'kernel' and then switch
to 'user' if the thread instance can no longer be properly multi
threaded.
To avoid having the same thread impl creating and destroying
GMainContext's, this also means always creating a GMainContext for the
thread-impl. When running in user-thread mode, the GMainContext is
wrapped in a wrapper source and dispatched as part of the real main
thread GMainContext, and when in kernel-thread mode, it runs
independently in the dedicated thread.
This has the consequence that the wrapper source will always have the
priority of the highest impl context GSource, but only after it has
dispatched once. Would we need it earlier than that, we either need a
way to introspect existing sources in a GMainContext and their
priorities, or manually track known sources in MetaThreadImpl.
The wrapper source will never be below 0, as that'd mean it could reach
INT_MAX priority if it had no more sources attached to it, meaning it'd
never be dispatched again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While doing this, rename the old synchronous functions to more clearly
communicate that they expect to actually process the update during the
call, not just post it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
While the default when passing NULL will be the main context of the main
thread, make it possible to specify another main context, so that
result handlers can be invoked on the right thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Callbacks could be queued to be invoked either on the impl side or the
main thread side of the thread; change this to take a GMainContext,
which effectively means a callback can be queued to be invoked on any
thread that has a GMainLoop running on its own GMainContext.
Flushing is made to handle flushing callbacks synchronously on all
threads. This works by keeping a hash table of queued callbacks per
thread (GMainContext); when flushing (from the main thread), callbacks
on the main thread context is flushed, followed by synchronization with
all the other threads.
meta_thread_flush_callbacks() is changed to no longer return the number
of dispatched callbacks; it becomes much harder when there are N queues
spread across multiple threads. Since it wasn't used for anything, just
drop the counting, making life slightly easier.
Feedback to thread tasks are however always queued on the callers
thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This means each test is run 4 times:
* with atomic mode setting using a kernel thread,
* with atomic mode setting using a user thread,
* with legacy mode setting using a kernel thread, and
* with legacy mode setting using a user thread.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This isn't a problem for user space threads, as there are no race
conditions, but when kernel thread support is introduced, we must make
sure that e.g. the main loop is actually running before quitting it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
This uses the queue that was introduced when migrating impl task
management from MetaThread to MetaThreadImpl, with the exception that
it's now fully used as an actual queue. It now has a GSource that sits
on the right GMainContext that is dispatched whenever there are tasks to
execute.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It's the impl side that wants to add impl side idle sources, or fd
sources, etc, so make it part of MetaThreadImpl.
This changes things to be GAsyncQueue based. While things are still
technically single threaded, the GAsyncQueue type is used as later we'll
introduce queuing tasks asynchronously, then eventually queuing across
thread barriers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
It currently does exactly what MetaKms and MetaKmsImpl did regarding the
context separation, which is to isolate what may eventually run on a KMS
thread into a separate unit. It works somewhat like a "user thread",
i.e. not a real thread, but will eventually learn how to spawn a
"kernel thread", but provide the same API from the outside.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
Remote desktop version 2 added a new method ConnectToEIS .
ConnectToEIS allows clients to requests a file descriptor from the
compositor which can then be used directly from libei.
Once established, the communication between compositor and application
is direct, without the need to go through the portal process(es).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Accessibility should be handled on the receiving end, if needed. Make
sure this is the case by listening on some signals, verifying they are
only triggered if we're not capturing input.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This adds the actual input capturing rerouting that takes events and
first hands them to the input capture session, would it be active.
Events are right now not actually processed in any way, but will
eventually be passed to a libei client using libeis.
A key binding for allowing cancelling the capture session is added
(defaults to <Super><Shift>Escape) to avoid getting stuck in case the client
doesn't even terminate the session.
The added test case makes sure that the pointer moves again after
pressing the keybinding.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
When a relative pointer motion gets constrained (e.g. a monitor edge or
barrier), save the constrained relative motion delta too.
This will later be used to send the remaining motion delta to input
capture clients.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
An input only grab is a ClutterGrab on the stage that doesn't have an
explicit actor associated with it. This is useful for cases where event
should be captured as if focus was stolen to some mysterious place that
doesn't have anything in the scene graph that represents it.
Internally, it's implemented using a 0x0 sized actor attached directly
to the stage, and a clutter action that consumes the events. An
input-only grab takes a handler, user data and a destroy function for
the user data. These are handed to the ClutterAction, which handles the
actual event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
Adding a barrier and later enabling the input capture session will
create MetaBarrier instances for each added input capture barrier.
The barriers are created as "sticky" which means that when a pointer
hits the barrier, it'll stick to the point of entry, until it's
released.
The input capture session is also turned into a state machine with
explicit state, to more easily track things.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This allows for a sticky barrier to hold the pointer until it is
released, but the owner of the barrier doesn't need a barrier event to
release it. It will be used to implement input capturing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
A sticky barrier means that a pointer in motion intersecting a barrier
doesn't move once having hit it. The intention with this is to allow an
input capture clients to continue a motion once a barrier is hit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This API aims to provide a way for users to capture input devices under
certain conditions, for example when a pointer crosses a specified
barrier.
So far only part of the API is implemented, specifially the session
management as well as zone advertisement, where a zone refers to a
region in the compositor which edges will eventually be made available
for barrier placement.
So far the remote access handle is created while the session is enable,
despite the input capturing isn't actually active yet. This will change
in the future once it can actually become active.
v2: Remove absolute/relative pointer, keep only pointer (ofourdan)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
This was a temporary fix until there was a better crossing event
delivery mechanism that accounted for actor changes beneath the pointer.
We nowadays have that, and don't seem to need this extra kick to get
crossing events triggered (and cursor changes, etc) when windows appear
or disappear under the pointer.
This commit is effectively a revert of commit
a64dba4d7a.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6808
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3104>
With window_is_terminal gone, "strict" and "smart" focus mode have no
behavioural difference. Let's broaden the scope of strict focus mode,
such that windows never automatically focus unless they are an ancestor
to the transient.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
As noted in the comments of window_is_terminal, this is a hack. This
code has not been touched for the better part of a decade. App res_class
tends to differ between Wayland and X11, so it is likely that none of
these apps have been recognised as terminals under Wayland ever. Also,
there are reports that strict focus mode also does not work under X11,
likely due to changes in these terminal apps over the years resulting
in different res_class than those manually specified in here. Let's remove
this hack and change strict focus mode accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3063>
Instead of using `clutter_actor_get_resource_scale()`, we now deduce the
intended buffer scale from the window by dividing the unscaled size by
the final actor size. This is more correct as while the return value of
`clutter_actor_get_resource_scale()` depends only on the monitor where
the surface resides, the actual scale of the surface is determined
solely by the application itself. `get_resource_scale` will differ from
the actual buffer scale if the application only supports 100% scaling
(Xwayland), or is performing scaling with wp_viewporter (clients using
fractional_scale_v1).
This also fixes a mismatch between the calculated buffer sizes between
`meta_window_actor_get_buffer_bounds` and
`meta_window_actor_blit_to_framebuffer` which causes broken
screencasting for Chromium 114 and later when using the native Ozone
Wayland backend.
Additionally, this commit also changes
`meta_window_actor_blit_to_framebuffer` from using a simple translation
to using an inverted matrix transformation of the transformation matrix
between the parent of the window actor and the surface actor to ensure
maximum sharpness for fractionally scaled windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3053>
Previously, restarting mutter in an X11 session resulted in
the previously set color temperature not being applied.
Fix that by applying the color temperature right after
the org.gnome.SettingsDaemon.Color proxy has been created.
Furthermore, only call `update_all_gamma()` from `on_gsd_color_ready()`
when the temperature has actually changed. Otherwise there is no need
since the current temperature has already been (or will soon be) applied
to all ready color devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3008>
We'd get a re-entry like scenario when destroying the PipeWire stream
object, where PipeWire would call the stream process vfunc. When this
happened, we had already destroyed the stream, so don't try to dequeue
or anything, just do an early exit. Fixes the following crash in the
test case client:
#0 pw_stream_dequeue_buffer() in /usr/lib64/libpipewire-0.3.so.0.367.0
#1 on_stream_process() at ../src/tests/screen-cast-client.c:348
#2 do_call_process() in /usr/lib64/libpipewire-0.3.so.0.367.0
#3 flush_items() in /usr/lib64/spa-0.2/support/libspa-support.so
#4 loop_invoke() in /usr/lib64/spa-0.2/support/libspa-support.so
#5 impl_send_command.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#6 suspend_node.lto_priv.0() in /usr/lib64/libpipewire-0.3.so.0.367.0
#7 pw_impl_node_set_state() in /usr/lib64/libpipewire-0.3.so.0.367.0
#8 client_node_removed() in /usr/lib64/pipewire-0.3/libpipewire-module-client-node.so
#9 pw_proxy_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#10 pw_stream_disconnect() in /usr/lib64/libpipewire-0.3.so.0.367.0
#11 pw_stream_destroy() in /usr/lib64/libpipewire-0.3.so.0.367.0
#12 stream_free() at ../src/tests/screen-cast-client.c:530
#13 main() at ../src/tests/screen-cast-client.c:803
#14 __libc_start_call_main() at ../sysdeps/nptl/libc_start_call_main.h:58
#15 __libc_start_main() at ../csu/libc-start.c:360
#16 _start() in /home/jonas/Dev/gnome/mutter/build/src/tests/mutter-screen-cast-client
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3095>
If the timelines don't get destroyed they keep references to frame
clocks. Later tests check for the destruction of those frame clocks and
then can fail if the frame clock is implemented slightly differenty.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3084>
In remote desktop sessions, streams can be created and destroyed
on-the-fly.
If a stream is gone, it is not necessarily an error.
So, don't treat that situation like an erroneous one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2911>
The previous logic didn't work correctly at least when priority-based
preeption wasn't supported by the DRM driver, such as in the case
of amdgpu. The call to glGetQueryObjecti64v would block on client
work which is already in progress (most likely for the next frame)
and delay notifying the ClutterFrameClock about presentation.
Conveniently, the Wayland transactions mechanism guarantees that all
fences of a dma-buf buffer are signalled before the buffer is
included in a frame, which means that dma-buf buffers are ready for
presentation when being directly scanned-out.
Direct scanout is only supported for dma-buf buffers too, which means
that all buffers going through direct scanout are effectively ready
and require no GPU rendering before presentation.
Assuming zero rendering time for dma-buf buffers going through direct
scanout simplifies the code and removes the need for
glGetQueryObjecti64v, thus avoiding the aforementioned issue where it
could block for longer than expected.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2766
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3080>
Depending on the ordering of the surface-associated resources
being destroyed, we may fall into the following situation:
- wl_surface is destroyed
- destruction notifications for the surface runs
- The MetaWaylandKeyboard attempts to synchronize the window
focus
- The MetaWindow is not destroyed yet, so the focused window
remains the same, and the MetaWaylandKeyboard keeps the same
focus MetaWaylandSurface.
- wl_surface finalizes destruction, MetaWaylandSurface now has
a NULL resource
- xdg_toplevel destructor kicks in, it unmanages the window
- The current focus window is again looked up, forced to look
a different window
- The MetaWaylandKeyboard focus now changes, tries to leave the
old surface, but it has a NULL resource already, and raises
a protocol error.
If the order is inverted, the window being unmanaged triggers a
focus change into a different window, the MetaWaylandKeyboard
triggers a focus change while the MetaWaylandSurface is still
intact, it succeeds, and the window gets properly destroyed.
In order to make this independent of the order, it makes sense
to make MetaWaylandKeyboard do like the other objects tracking
focus surfaces, and have it care of its own little parcel. The
surface destructor changed to simply unsetting the keyboard focus
to NULL (guaranteeing that the old focus is left while the surface
resource is still up), and leaving potential focus changes to
the xdg_toplevel_destructor->unmanage->update_focus paths.
Doing that alone is basically a revert of commit 228d681b, thus
is still subject to keyboard focus being lost after a popup is
destroyed. Change the approach to trigger the focus sync (and
new focus surface lookup) so it happens from xdg_popup_destructor
specifically to popups and alike xdg_toplevel.
Fixes: 228d681b ("wayland: Trigger full focus sync after keyboard focus surface is destroyed")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2853
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3077>
Current behavior pushes a window which receives focus to the start of
the MRU list on every workspace it is on. By focusing a sticky window
the default focus on all other workspaces changes as well. This is fine
for sticky windows explicitly marked as sticky by the user but if a
window is on a secondary output and workspaces are only on the primary
output the behavior is unexpected. Instead we want the window to be the
default focus only on the current workspace but also keep those windows
in a relative MRU order to each other on all workspaces.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2681
Fixes: 058981dc1 ("workspace: Focus the default window only if no window is focused")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2909>
This avoids use-after-free when handle_start() is called following
handle_stop() during the lifetime of the MetaProfiler. This happens
on repeated profiling sessions using Sysprof.
Fixes: e16d68372 ("profiler: Add API to register profiler threads")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3076>
We need to juggle with some things here to keep key event ordering
and accounting consistent.
The keyboard internal state changes (and maybe modifier event emission)
happening through meta_wayland_seat_update() should ideally happen
from the same key events that reach the client through wl_keyboard.key,
so that wl_keyboard.modifier events are emitted in the right relative
order to other key events.
In order to fix this, we need to decide at an earlier point whether
the event will get processed through IM (and maybe be reinjected),
thus ignored in wait of IM-postprocessed events.
This means we pay less attention to whether events are first-hand
hardware events for some things and go with the event that does
eventually reach to us (hardware or IM).
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5890
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Given the presence of IMs and the different paths in event handling to reach
one of them, we cannot make guesses about whether should stick to the original
hardware-triggered event, or wait/prefer a second hand IM event that might or
might not arrive. We also have no say for other IM foci unrelated to wayland
(e.g. ClutterText) triggering the double event emission.
So go with it and maintain our own internal state for keys, we already kinda
do, but mainly for warning purposes, at the time of updating the
MetaWaylandKeyboard state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
Currently, we let the same function handle key event filtering as they
are passed to the IM, and the IM events resulting in actions like text
commit or preedit changes.
Split these two aspects into filter/process functions, and port
ClutterText to it. MetaWaylandTextInput still handles everything in
a single place, but that will be split in later commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3044>
This means initializing the pointer position in MetaSeatImpl
synchronously too, otherwise it's not guaranteed querying the seat state
will result in the expected position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3071>
I have a monitor which can report two preferred modes: 5120x1440@240
and 3840x1080@60. Since they are enumerated in this order by KMS,
init_output_modes would end up using 3840x1080@60 (and it was impossible
to select any 5120x1440 mode in the GNOME display settings).
Fix this by using meta_kms_connector_get_preferred_mode, which returns
the first KMS mode with DRM_MODE_TYPE_PREFERRED.
v2:
* Use meta_kms_connector_get_preferred_mode. (Jonas Ådahl)
Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3055>
This will consist of device-added events, meaning before init finishes,
we can derive some state that depends on the set of input devices
available on startup, such as cursor visibility.
This avoids cursor visibility switching between hidden and visibility
during startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This opens up for a possibility to handle initial events (devices
discovered on startup) during initialization, meaning we can figure out
a more correct initial state that depends on available input devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
This is different from "warping" as it doesn't necessarily result in a
pointer motion event. This can be helpful during initializing so we can
avoid faked pointer events that would otherwise need to be special cased
to not appear as actual pointer movements.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
The stage already maintains its own list of stage-views via
clutter_stage_peek_stage_views(), it's a bit superfluous to copy that list
around all the time into priv->stage_views of ClutterActor. Let's deal with
that by returning clutter_stage_peek_stage_views() when
clutter_actor_peek_stage_views() gets called for the stage.
In order to make sure ClutterActor::stage-views-changed still gets emitted
correctly for the stage, always emit that signal on the ClutterStage when
the stage views get invalidated. This now depends on the backend only
actually invalidating the views and calling
clutter_stage_clear_stage_views() when things have actually changed, but
that should be the case.
This needs a change in one of the stage-views tests, namely the one which
tests stage-view-changed emission on the stage: Here we now see an emission
of stage-views-changed, but that signal emission actually seems correct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
There were two issues with using the shape region to derive an input
region.
Firstly, the shape region is against the client rectangle, while the
surface actor needs it to be against the buffer rectangle. Fix this by
offsetting the shape region before passing it along.
Secondly, we can't just intersect the shape and input region, since that
leaves out the window decorations. Fix this by only intersecting the
input region covering the client part, and the shape region, and then
union that with the input region covering the rest.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3045>
Don't try to handle things by threads enabling/disabling the main trace
context on-demand, just have a clear start/stop API. For the D-Bus API,
it becomes more straight forward, and for the persistent variant too, as
it avoids having to pass garbage input when it's known that arguments
will be discarded.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Persistent profiling was started via an env var, but that's rather hard
to discover and remember without grepping; change to use a command line
argument.
The profiler is started early, even during (though late in)
configuration, but configuration should ideally be instant and pointless
to configure.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2998>
Under X11 hiding the backend implies also unmapping the stage window, if
we do that after that we've closed the display we may end up in a
BadWindow error because such window seems to be destroyed together with
the compositor output parent (even though we are not notified about), so
to prevent this, reparent the backend window during compositor unmanage,
setting it back as a root window child.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2835
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3020>
We currently lock the capability of the MetaOrientationManager to emit
the ::orientation-changed signal, but otherwise keep reading the current
orientation and returning it if we are asked politely through
meta_orientation_manager_get_orientation().
This may bring issues e.g. around suspend/resume, since there may be other
parts of the code trying to get the current orientation without receiving
::orientation-changed signals, this may result in the display orientation
being effectively rotated, then stay locked after that.
In order to fix this, make the MetaOrientationManager return a fixed
orientation while locked, only updated after changes in the lock state.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2600
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3021>
This is missed, leaving the cursor renderer disconnected from the stage
updates that could trigger further frame callbacks on the cursor, leaving
some clients like Xwayland stuck with cursors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3025>
We do in fact allow these combinations of configuration since the Settings
Wacom panel revamp. We no longer need to look up Wacom device features,
since this is allowed for all the devices that have these settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
We avoided setting the device matrix applying to the tablet tool (used if the
tablet is in absolute coordinates mode) if the device is configured for relative
motion, but forgot to apply the matrix if changing the device back to absolute
mode, this made the device seemingly forget its attached display until later
configuration changes.
In order to avoid the hassle of looking up the right display again on unrelated
configuration changes, make the matrix be always set on the device, but only
actually used in absolute coordinates mode. This makes the device able to
seamlessly switch between modes and remain mapped to the right display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
This was somewhat ineffective since it was applied after figuring out
the x/y absolute coordinates. Change the order (filter first, then
figure out abs coords), and use coordinates from the correct device
while at it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3012>
A window may become undecorated while the frame window is
frozen due to updates. In that case we would both miss a
reply for the frame window, and any other means to trigger
the window actor being thawed.
Check the frozen state after destroying the frame, so that
meta_window_x11_are_updates_frozen() may end up changing
opinion if the frame window was caught in this situation.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2639
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2996>
`meta_surface_actor_is_obscured_on_stage_view` currently fails to
account for non-identity scaling of actor size (e.g. window actor
geometry scale or surface pixel alignment).
Fix this by using the new `meta_region_apply_matrix_transform_expand` to
calculate the unobscured region in stage coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
This allows MetaCullable to work with actors using arbitrary transforms
which will be needed for implementing surface pixel alignment for
fractional-scale-v1.
This also deletes meta_cullable_is_untransformed as it's no longer
necessary, and we can also stop manually scaling the region objects
while performing opaque region culling in surfaces since it's now
handled transparently by the new `meta_cullable_cull_out_children`
implementation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
Implement the stable rounding algorithm as described in the discussions
for the fractional-scale-v1 protocol.
This adds an override of the ClutterActor::apply_transform vfunc for
MetaSurfaceActorWayland that ensures the size and position of the
contents of the surface are rounded according to the stable rounding
algorithm.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
Always ensure that the MetaSurfaceContainerActorWayland is aligned to physical
pixel boundary in preparation for fractional-scale-v1 protocol support.
This introduces an override of ClutterActor::apply_transform vfunc for
MetaSurfaceContainerActorWayland that always ensures the actor content is aligned
to physical pixel boundary.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726>
A failing allocation is non-fatal here, however if it fails later in a
lazy allocation triggered by `cogl_framebuffer_create_timestamp_query()`
we end up crashing. Thus force the allocation early, like we already do
in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3004>
While it's obviously good to trap possible errors from X calls, we are
mixing the Clutter error trap with the MetaX11Display one for these
calls.
This may result in situations where a X call within a Clutter error
trap fails, but it's actually handled in these sections using the
MetaX11Display error trap. This one will consider the serial out
of the "handled" parts and raise an error.
It is better to stay consistent here, and use the same error traps
than the rest of the X11 backend.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2796
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3002>
When the X11 display is actually XWayland there's no point to delay the
compositor selection, given that mutter itself is the compositor and
doing this may cause the first X11 client that starts not to receive the
right information (and in some cases misbehave).
Since some toolkits are not handling the compositor selection changes
properly at later times, let's make their life easier by just
initializing the selection as early as the other X11 properties, given
that in this case there's nothing to replace.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2472
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2970>
Since c390f70edc ("backend: Set up and use ownership chains")
the type of the ClutterInputDevice object's "meta-input-settings-xdevice"
data is `DeviceHandle`, but that commit failed to change the one place
where the object data is queried. As a consequence, that part still
considers it to be an `XDevice`, so everything that uses the return
value of `device_ensure_xdevice()` works with invalid data. Furthermore,
`device_handle_free()` incorrectly uses the `user_data` as the argument
for `XCloseDevice()` leading to a double free.
Fixes: c390f70edc ("backend: Set up and use ownership chains")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2995>
Otherwise binding new wl_output's might try to send enter to the
destroyed resource. Fixes the following crash:
#0 wl_resource_get_client at ../src/wayland-server.c:801
#1 handle_output_bound at ../src/wayland/meta-wayland-surface.c:1287
#3 signal_emit_unlocked_R.isra.0 at ../gobject/gsignal.c:3812
#6 ffi_call_unix64 at ../src/x86/unix64.S:104
#7 ffi_call_int at ../src/x86/ffi64.c:673
#8 ffi_call at ../src/x86/ffi64.c:710
#9 wl_closure_invoke at ../src/connection.c:1025
#10 wl_client_connection_data at ../src/wayland-server.c:438
#11 wl_event_loop_dispatch at ../src/event-loop.c:1027
#12 wayland_event_source_dispatch at ../src/wayland/meta-wayland.c:125
#15 g_main_context_iterate.isra.0 at ../glib/gmain.c:4276
#17 meta_context_run_main_loop at ../src/core/meta-context.c:482
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2196527
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2992>
Otherwise drivers would be free to alter the buffer content. While no
driver is known to do so, it's probably good to make things explicit.
See also `import_simple_dmabuf()` in Weston.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2990>
The DMA buffer paths vs MemFd paths differ slightly in when content is
recorded. This was in some places done by trying to record but bail if
the dequeued buffer had the wrong type. This is problematic for two
reasons: we'd update the timestamp even if we refused to record, making
the follow-up attempt fail, and we'd dequeue and queue buffers that
didn't get any content, meaning the receiving end would see empty
buffers potentially with only cursor updates.
Fix this by keeping track if a stream is DMA buffer able or not, and
don't attempt to record at all in the places we would previously require
DMA buffers. This avoids both issues: we don't dequeue/queue pw_buffers
that we refuse to record to, and we won't update the recorded timestamp
when we didn't intend to record to begin with.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2783
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2987>
Hides libdisplay-info under a build time default-off flag,
provides provision to parse essential edid parameters with
APIs provided by libdisplay-info. This implementaion increases
readibility, avoids code duplication and decreases complexity
of edid parsing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2642>
We are attempting to show windows that do not yet have a
surface/buffer, this makes GNOME Shell avoid transitions
for these windows.
Since on Wayland X11 windows are also Wayland surfaces,
this check is also valid for these, and is thus made more
generic to also cater for these windows.
Eventually, meta_window_update_visibility() is called
when the surface gets its buffer, so the window can be
neatly animated.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2611
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
This ATM triggers missed .commit events for the window in question,
to be addressed in Xwayland. Since the test does not seem to specifically
rely on this window being CSD, make it a regular window instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2975>
Going for the default GL renderer is known to trigger rendering
artifacts using the NVidia proprietary driver. Since we don't have
too many expectatives about frames being flashy (not to the point
of mandating GL), resort to the cairo renderer in the mean time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2976>
Just like the HDR Metadata property the Colorspace property values only
indicate that the display driver supports signaling certain colorimetry.
It does not indidcate that the sink actually supports processing the
colorimetry. For this we have to look up the colorimetry support in the
EDID.
The default colorimetry is always supported. If we want bt.2020 we might
get either the RGB or YCC variant even if we ask for the RGB variant but
there is nothing we can do about it so let's just pretend it's a driver
issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2919>
If the used EGL backend supports it. In practice this should currently
only affect the nested backend.
Enabling modifiers can help with app development. An example is
`weston-simple-dmabuf-v4l`, which requires the linear modifier to be
available.
Note that Weston behaves similar already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2972>
This will be used to extract the resolution and refresh rate from
strings like "1920x1080@60.0" or "1280x720". This aims to replace the
use of the locale dependent sscanf() function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2902>
This 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>
When selecting the default focus window, is_focusable() was not
considering the new conditions for whether a window should be shown or
hidden that were added to meta_window_should_be_showing() in 39942974.
As a result the default focus window could end up a window already
hidden or hidden once meta_window_flush_calc_showing() is called by
meta_window_focus() when focusing the default window. This would cause
meta_window_focus() to fail, which is an issue if it prevents us from
unfocusing a window when it is getting unmanaged.
Fixes: 399429742 ("x11: Integrate frames client into Mutter")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2644
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2962>
create_and_send_dnd_offer() sets the compositor of the offer to the one
from the MetaWaylandDataSource. This then later gets used in
display_from_offer() when trying to get the context from the compositor.
meta_wayland_data_source_xwayland_new() however was not setting the
compositor, so this was causing crashes when dragging things from X11
windows on Wayland.
Fixes: 2731f0cda ("wayland: Setup and use ownership chains")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2723
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2956>
This ensures that applications are notified when a drag gets cancelled
because the user dropped or press ESC while in overview.
This fixes an issue with Chromium on Wayland refusing to acknowledge
wl_pointer::enter events after accidentally dropping a
Chromium-originated object in GNOME Shell overview.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2953>
Ensure the frame window is created at the right fullscreen state
before showing it and assigning it to the client window.
A peculiarity of this property on frame windows is that it is
typically single-handedly updated from the Mutter side, in synchronization
with client window state. It can only differ during creation, since
GTK still likes to apply its own state.
Also, the only relevant property seems to be _NET_WM_STATE_FULLSCREEN,
since the others are less relevant to the role of the frames client,
and get applied to the MetaWindow as a whole, instead.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2712
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2961>
After this got changed from gdk_x11_get_xatom_name() to XGetAtomName(),
this no longer returns a const char* and it now also needs to be freed.
Fixes: e66f4396e ("x11: Avoid GDK API in X11 selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
This was pointlessly being converted between atom and string and back,
which with the switch from gdk_x11_get_xatom_name() to XGetAtomName()
also introduced a leak for every XGetAtomName() call.
Fixes: e66f4396e ("x11: Avoid GDK API in X11 selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
The private format and type member variables were not being used by any
of the callers, so they can simply be removed. This also fixes a leak of
type which was introduced when switching from gdk_x11_get_xatom_name()
to XGetAtomName().
Fixes: e66f4396e ("x11: Avoid GDK API in X11 selections")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
After this got changed from gdk_x11_get_xatom_name() to XGetAtomName(),
this no longer returns a const char* and it now also needs to be freed.
Fixes: 014cde646 ("wayland: Do not use GDK functions on XDnD implementation")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2957>
We might end up trying to apply a pending state late if it was delayed
by DMA buffers not being ready. Trying to discard the pending state from
the transaction when dismissing is hard, because we might be applying a
chain of transactions that would disqualify subsequent transactions if a
former one dismisses the popup, so lets just drop what the apply would
otherwise do, if we're not going to use it anyway.
This fixes the following crash:
0) meta_wayland_surface_get_window (surface=0x0)
1) meta_wayland_xdg_popup_apply_state (surface_role=0xf5ee80, pending=0xf662a0)
2) meta_wayland_surface_role_apply_state (surface_role=0xf5ee80, pending=0xf662a0)
3) meta_wayland_surface_apply_state (surface=0xf5e640, state=0xf662a0)
4) meta_wayland_transaction_apply (transaction=0xf56170, first_candidate=0x7fffffffcee8)
5) meta_wayland_transaction_maybe_apply_one (transaction=0xf56170, first_candidate=0x7fffffffcee8)
6) meta_wayland_transaction_maybe_apply (transaction=0xf56170)
7) meta_wayland_transaction_dma_buf_dispatch (buffer=0xf448a0, user_data=0xf56200)
8) meta_wayland_dma_buf_source_dispatch (base=0xf5f140, callback=0x0, user_data=0x0)
9) g_main_dispatch (context=0x41baa0)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
If the popup was dismissed (i.e. has no MetaWindow anymore), it'll also
have no parent surface. With no parent surface, we'd try to fetch a
transaction from NULL and crash, but if we don't try if we were
dismissed, we won't reach here anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2940>
With the frames client, we do no longer handle events for the
frame window inside Mutter. This means we do not get events
"for free" to handle focus on a just clicked frame window.
This results in a background window not ending up focused if
clicked on its frame.
In order to fix this, make the passive button grab extend to
the frame window if a window has one. This brings back
focus-on-click behavior, while treating windows further as
a unitary surface.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2727
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2954>
Pass the timestamp of the frame as the target timestamp of the
record. This makes the rudimentary frame throttling mechanism
inside MetaScreenCastStreamSrc work with the timing variability
that dynamic dispatch times introduced.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Instead of always, unconditionally scheduling an idle callback for
frame recording, try to record a DMA-BUF only frame, and only if
that's not possible, schedule the idle callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
When a stream source subclass asks for a DMA-BUF only frame record,
it is legitimate to return FALSE in do_record_frame() - meaning that
a frame was not recorded - but not return an error - meaning nothing
actually failed.
This avoids spamming the journal with warnings on a legitimate case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
Add meta_screen_cast_stream_src_maybe_record_frame_with_timestamp()
which operates on arbitrary timestamps; and make the current function
meta_screen_cast_stream_src_maybe_record_frame() just call into the
new variant, passing g_get_monotonic_time() as the timestamp.
This will be useful later we start using the target timestamp of the
frame for screencasting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2804>
This change will export the damaged regions (when available) out
to the pipewire client. This change is currently specific to
virtual streams only (where I was able to test the change) and
maintains the current behavior for other screencast stream types.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
This change allows clipped redraws for offscreen. The net
effect of this change is to preserve the original redraw clip when
possible (rather than overwriting it with the full view redraw) in
the paint context.
This eventually helps in retrieving the fine grained updated regions of
the frame since last redraw and sending it to the pipewire client
(as shown in a subsquent CL).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2775>
Returning FALSE does not indicate an error, but a valid backlight
value of 0. Consumers expect a negative value to indicate no
backlight support, so return -1 in case of error, just like we
already do for invalid values.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2947>
The window tracker is filtering XEvents manually as it only requires a
subset of the ones that Gdk listens to in the root window, and this is
nice, but we were restricting the set a bit too much because due to this
we were not notified when an xsettings manager was available, and thus
in case gsd-xsettings was launched after meta-window-tracker (a normal
scenario under X11), no xsetting was actually applied to the decoration
windows.
As per this, the default settings were used for everything and never
updated, until a restart of the window-tracker.
In order to be able to monitor the XSettings changes at startup, we also
need to select the StructureNotifyMask as gtk always do by default.
See also:
https://gitlab.gnome.org/GNOME/gtk/-/blob/4.11.1/gdk/x11/gdkscreen-x11.c#L947-950Fixes: #2580
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2948>
The anchor position calculations are somewhat unnecessarily complex
based on root coordinates of pointer and frame positions. This requires
tracking both things, and we don't always get it quite right with the
latter (e.g. window repositions, resizes or overshrinks, leaving the
anchor position visually outside the window).
In order to improve this, capture the window-relative coordinates
when starting the window drag, and ensure the window is always repositioned
in that position, relative to its current size.
This avoids these glitches when unmaximizing a window (e.g. dragged from
the bottom through super+button1 press), or moving windows between monitors
with different scales.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2730
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
Since we only track changes to window_drag->anchor_window_pos
during move operations through on_grab_window_size_changed(), this
rectangle is in essence the same than window_drag->initial_window_pos
all the time. Just use that and move away from the anchor_window_pos
rectangle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2942>
scan_visible_region() scans through each value of a uint8_t array and checks
whether that value is 255. Right now it always checks one value too much
though, resulting in a buffer overflow. Fix that by checking the array
bounds before actually accessing the array.
Found by running gnome-shell with address sanitizer and starting
GIMP.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2856>
Both GRAB_OP_KEYBOARD_MOVING and GRAB_OP_KEYBOARD_RESIZING_* are
defined as GRAB_OP_WINDOW_BASE with FLAG_KEYBOARD set, but the
latter have additional bits set to indicate the direction.
That is, the GRAB_OP_KEYBOARD_MOVING bitmask cannot be used to
differentiate between move- and resize operations. Instead,
check that no direction bits are set.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2684
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2908>
The unknown color space's only purpose is to signal that the current KMS
state has a unknown color space set. It is not one of the color spaces
that can be set. We already only try to set a color space if the default
color space is supported so we should use the default color space as a
fallback instead of the unknown color space.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2693
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2915>
With the move away from GTK3, and the indirect dependency on GTK4
grown in the GNOME Shell side, we've indirectly gotten a small sneaky
behavioral change: The GTK4 library will, right on dlopen, get
DESKTOP_AUTOSTART_ID for itself and delete it from the environment.
This happens before our own X11 session management code is
initialized, which confuses the hell out of it, into thinking
initialization is actually shutdown, gnome-session does not follow
along with this request, which leaves GNOME Shell into a confused
startup state where it never calls SmcSaveYourselfDone() and grinds
startup to a halt until gnome-session decides to move things forward.
In order to fix this, get the DESKTOP_AUTOSTART_ID before we lend
control to GNOME Shell bits and GTK4 is possibly initialized, and
feed it directly to our X11 session manager bits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2906>
We might get told to restore the old monitor configuration by the
monitor configuration prompt, in case the user pressed "revert" or
equivalent. This might be in response to a button press, and those
happen during frame clock dispatch. If we would restore an old
configuration during dispatch, it means we would reconfigure the
monitors including their stage views while dispatching, which means we'd
destroy the frame clock while it's dispatching.
Doing that causes problems, as the frame clock isn't expecting to be
destroyed mid-function. Specifically,
We'd enter
clutter_frame_clock_dispatch (clutter-frame-clock.c:811)
frame_clock_source_dispatch (clutter-frame-clock.c:839)
g_main_dispatch (gmain.c:3454)
g_main_context_dispatch (gmain.c:4172)
g_main_context_iterate.constprop.0 (gmain.c:4248)
g_main_loop_run (gmain.c:4448)
meta_context_run_main_loop (meta-context.c:482)
main (main.c:663)
which would first call
_clutter_process_event (clutter-main.c:920)
_clutter_stage_process_queued_events (clutter-stage.c:757)
handle_frame_clock_before_frame (clutter-stage-view.c:1150)
which would emit e.g. a button event all the way to a button press
handler, which would e.g. deny the new configuration:
restore_previous_config (meta-monitor-manager.c:1931)
confirm_configuration (meta-monitor-manager.c:2866)
meta_monitor_manager_confirm_configuration (meta-monitor-manager.c:2880)
meta_plugin_complete_display_change (meta-plugin.c:172)
That would then regenerate the monitor configuration and stage view
layout, which would destroy the old stage view and frame clock.
meta_stage_native_rebuild_views (meta-stage-native.c:68)
meta_backend_native_update_screen_size (meta-backend-native.c:457)
meta_backend_sync_screen_size (meta-backend.c:266)
meta_backend_monitors_changed (meta-backend.c:337)
meta_monitor_manager_notify_monitors_changed (meta-monitor-manager.c:3595)
meta_monitor_manager_rebuild (meta-monitor-manager.c:3683)
meta_monitor_manager_native_apply_monitors_config (meta-monitor-manager-native.c:343)
meta_monitor_manager_apply_monitors_config (meta-monitor-manager.c:704)
After returning back to the original clutter_frame_clock_dispatch()
frame, various state in the frame clock will be gone and we'd crash.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2901>
Commit 7e9d9c7eb9 added new API to replace GTK for accelerator
parsing.
Unfortunately there is another case in gnome-shell, where we have
to get the label from the logical binding name rather than the
modifier+keysym combination.
Add another small method to cover that use case.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2899>
Normally, mutter implicitly allows a window being shown to take
focus. This is normally desired, except it steals input from
GNOME Shell self. Avoid focusing the just shown window in those
situations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
When a X11 application is started, typically what happens is:
- A startup notification token is created, with a _TIME%d suffix
- The application being spawned receives it through the environment
- (dbus piping, maybe)
- The application replies the startup notification token, and
fetches the timestamp from it
- The application makes a _NET_ACTIVE_WINDOW client message request
with this timestamp
- Mutter handles this client request and activates/focuses the window
Prevent this last step if windows are not interactable (e.g. there is
a compositor grab) and ignore the focus request. This specifically
applies to X11 clients requesting focus themselves, and unlike previous
approaches, doesn't try to prevent focus changes that do come through
interaction with Mutter/GNOME Shell.
This should only break if applications do not observe _NET_ACTIVE_WINDOW
and perform XSetInputFocus on themselves, but in that case the X11
keyboard focus is stolen from our hands already.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2878>
This is the mask that lets us receive among other events the rather
important CreateNotify, that tells us about new winows. This has went by
rather unnoticed except for cases where multiple windows show up very
quickly directly after the frames client spawned, because the drag icon
surface cache eventually already did select that particular mask.
Make things more reliably by explicitly setting the mask for the events
we rely on to function.
This fixes flaky stacking tests that map multiple X11 windows in a row.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2894>
2d8fa26c8e ("core: Pass "frame action" grab operations as an
"unconstrained" grab op") changed the behaviour to treat non-grab
related window moving that has the "user action" flag set to still apply
the "constrain_titlebar_visible" constraint.
The fact that it wasn't applied before was relied upon by some
extensions. While it should arguably exist a better API that for such
extensions to use that have a bit more predictable behavior, until that
is so, restore the old semantics.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2891>
Linear sampling can influence the value of surrounding pixels beyond
the scaled framebuffer extents calculated during stage view rendering,
resulting in flickering graphical artifacts due to unaccounted pixel
changes. This is exhibited in xfreerdp and wlfreerdp at 150% display
scaling.
Fix this by ensuring that all pixels that may be affected by linear
scaling is included in the framebuffer redraw clip by padding the actor
redraw clip.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2771>
We have the drm/InfoFrame encoding and our MetaOutputHdrMetadata
encoding. Check that we can correctly convert between each other by
doing a encode/decode and decode/encode roundtrip and then checking for
equality.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The existence of the KMS property just means that we can send an
InfoFrame but we also have to make sure the sink actually supports the
metadata type 1 and the selected transfer function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
Allows to prepare KMS updates to set the color space and HDR Static
Metadata on the output.
For some reason we need ALLOW_MODESET on commits which change the HDR
Static Metadata InfoFrame on AMDGPU. There is no technical reason why
one needs to mode set to send an InfoFrame and the driver should just
manage without ALLOW_MODESET. Until this is resolved in the kernel we
just prepare KMS updates which might mode set.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The HDR Static Metadata InfoFrame contents are described in CTA-861.3
and the kernel maintains a representation of that in `struct
hdr_metadata_infoframe` in `include/uapi/drm/drm_mode.h`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The Colorspace property informs the display about the colorimetry of the
content. Only variants supported by the sink are exposed in the
property. The strings representing the color spaces are undocumented but
can be found in the `hdmi_colorspaces` list in
`drivers/gpu/drm/drm_connector.c` in the Linux kernel (v 6.2).
The HDR_OUTPUT_METADATA property is a blob with the InfoFrame content.
We have to query support for the different values in the struct from the
EDID/DisplayID ourselfs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
This adds a new 'experimental-hdr' string property to the MonitorManager
which can be changed from looking glass.
Currently when the string equals 'on', HDR (PQ, Rec2020) will be enabled
on all monitors which support it. In the future support for more
transfer functions and color spaces as well as HDR metadata can be
added.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
The color space and HDR metadata are eventually sent as metadata to the
display. The color space informs the display of the colorimetry of the
frames we produce, the HDR metadata informs the display of the transfer
function and additional mastering display colorimetry and luminance to
guide tone and gamut mapping.
The only color spaces we support right now are the default color space
and Rec bt.2020 which is typically used for HDR content. Other supported
color spaces can be added when needed.
The default color space corresponds to whatever colorimetry the display
has when no further changes are made to the calibration of the display.
The colorimetry is communicated to sources via EDID/DisplayID.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2879>
A Wayland client repeatedly requesting activation of its surface using
the xdg-activation protocol would make mutter constantly update the
cursor.
To avoid needlessly updating the cursor back and forth between busy and
default, add a timeout to delay the update.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
When a client (either Wayland or X11) is started, the window activation
will update the cursor to the "busy" cursor.
Mutter will then set the X11 cursor on the X11 root window to match that
so that X11 applications which do not explicitly set a cursor inherit
from that default (busy) cursor.
Updating the X11 cursor too often can hammer the X11 connection and
cause a deadlock with Xwayland.
Reload the X11 cursor in a later handler to avoid that issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2849>
We relied on them being valid longer to keep track of used GPUs. If we
don't have the CRTC (or output) we don't have a way to fetch the pointer
to the MetaGpu that drives the associated monitor.
This avoids a crash when trying to fetch said pointer from what would be
the NULL MetaCrtc pointer.
Fixes: 08593ea872 ("onscreen/native: Hold ref to the output and CRTC until detached")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2667
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2887>
Ensure we preserve the fast zero-copy paths in Xwayland fullscreen
windows, instead of maybe rendering the client surface on top of the
frame surface, and providing the latter to the compositor.
To achieve this, additionally synchronize frame state when
recalculating features (e.g. after fullscreen/unfullscreen), and
account for this new condition when creating or destroying frames.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2797>
We were relying on gdk_cairo_region() to convert a cairo_region_t
into a path ready to fill/stroke in a cairo_t. This is a small
and detached helper that we can do ourselves, so put it together
with all other region helper functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
Do the few remaining things that GDK is doing for us:
- Open and close the X11 Display
- Set up a GSource on the Display FD to handle events
- Allocate and free the content of XGenericEventCookie,
to "unroll" the few XInput2 events that Mutter still
does handle.
And remove the GdkDisplay we've so long relied on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
From reading the comment in the top of the file, not for the first
time. Keep our own error handler and maintain our own list of
failable x11 sequences in MetaX11Display, so we can move away from
GTK's.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
These are done on the backend X11 connection, so it is unclear
what is the interplay through the borrowed global XSetErrorHandler()
that triggers issues for us here.
Anyways, better to be explicit, and use error traps the MetaBackendX11
style, in coherence with the rest of the things happening in that
display.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2864>
When an onscreen is "attached" it means it has an active CRTC and output
it interacts with, e.g. listens to configuration changes to update gamma
and privacy screen state.
MetaOutput and MetaCrtc are rather short lived objects meaning they are
disposed of and regenerated each time the compositor reloads monitor
resources, and while MetaOutput are indirectly kept alive due to the
MetaMonitor holding on to them during reloading, the same does not apply
to MetaCrtc, so to avoid trying to disconnect our signals from
disappeared outputs and CRTCs when we dispatch, hold our own references
to these objects.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2665
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2885>
On exit, explicitly detach the onscreens during disposal. This means no
functional changes, but allows for doing more cleanup on detach that
doesn't need to be repeated on disposal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2885>
As implemented in colord 1.4.6, cd_icc_load_handle() has three possible
results:
1. success, taking ownership of the profile;
2. failure because cmsGetProfileContextID returns NULL, *not* taking
ownership of the profile;
3. failure in cd_icc_load(), taking ownership of the profile.
The previous commit ensures that we are not in case 2.
In case 3 where cd_icc_load() fails, ownership was already given to
the colord CdIcc object, so it will be freed when the g_autoptr unrefs
the CdIcc, and we must not free it again: that would be a double-free,
potentially resulting in memory corruption.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2659
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2877>
We want to avoid using too high scales too easily, which started to
happen 2f1dd049bf ("monitor-manager: Rework default scale factor
selection"). Instead of using the closest non-fractional scale, which
effectively is what we'd do, only round upwards if we're closer than
0.25 (25%).
Since there are some wiggle room for scales to make the logical
resolution on the integer pixel grid, make sure to compensate. This
compensation is done by adding an extra 0.2 to scale difference.
For example the following fractional scales will get these corresponding
integer scales:
* 1.25 -> 1.0
* 1.5 -> 1.0
* 1.75 -> 2.0
* 2.0 -> 2.0
* 2.50 -> 2.0
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2880>
Instead of testing headless start using the dummy backend, do so with
the real native backend, and use the drm-mock library instead to emulate
monitors being disconnected at startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
This new filter allows test cases to manipulate what the kernel reports,
e.g. mark connected connectors as disconnected to emulate monitors
connecting and disconnecting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
As part of https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/525
(introduction of transactional KMS API), the logic determining whether a
GPU can have outputs was changed from whether any connectors existed to
whether any connected connectors existed. That effectively meant that we
wouldn't attempt to start at all if there were no monitors connected
while starting up.
This was unintentional, so lets revert back the expected behavior.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2821>
In order to make things more and more asynchronus and to each time we
paint be an isolated event, that can be potentially be applied
individually or together with other updates, make it so that each time
we draw, we use the transient MetaFrameNative (ClutterFrame) instance to
carry a KMS update for us.
For this to work, we also need to restructure how we apply mode sets.
Previously we'd amend the same KMS update each frame during mode set,
then after the last CRTC was composited, we'd apply the update that
contained updates for all CRTC.
Now each CRTC has its own KMS update, and instead we put them in a per
device table, and whenever we finished painting, we'll merge the new
update into any existing one, and then finally once all CRTCs have been
composited, we'll apply an update that contains all the mode sets for all
relevant CRTCs on a device.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
MetaRendererViewNative is a MetaRendererView which contains logic
specific to views of the native backend. It will be used by following
commits.
In the future, per-view logic from MetaRendererNative can be moved to
MetaRendererViewNative where it makes more sense to have it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2855>
Add a tiny library that sabotages errors in drmMode*() API calls. This
will be used to artificially trigger arbitrary errors, e.g. cause the
next commit to fail with EBUSY.
The three mocked methods are added as they will be used in a future
commit.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
Instead of using the "discarded" page flip callback when the
"discarding" happened during actual immediate processing, communicate
the same via the KMS update feedback.
The "discarded" page flip callback is instead used only for when a
posted page flip is discarded. In the atomic backend, this only happens
on shutdown, while in the simple backend, this also happens when a
asynchronous retry sequence eventually is abandoned.
This allows further improvements making KMS handling fully async.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
At first it was called seal(), but then updates could be amended after
being posted, given a flag. That flag has been removed, so we can go
back to sealing, since it's once again acts more as a seal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
We test direct client buffer scanout using a TEST_ONLY commit on atomic,
and with various conditions in non-atomic, but if we end up failing to
actually commit despite this, handle the fallout asynchronously. What
this means is that we'll reschedule a new frame immediately.
For this to work, the same scanout buffer needs to be avoided for the
same CRTC. This is done by using the newly added signal on the
CoglScanout object to let the MetaWaylandBuffer object mark the current
buffer as non-working for the onsrceen that it failed on. This allows to
re-try buffers on the same onscreen when new ones are attached.
This queues a full damage, since we consumed the qeued redraw rect. The
redraw rect wasn't lost - it was accumulated to make sure the whole
primary plane was redrawed according to the damage region, whenever we
would end up no longer doing direct scanout, but this accumulation only
works when we're not intentionally stopping to scanout. For now, lets
just damage the whole view, it's just an graceful fallback in response
to an unexpected error anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we call schedule(), which will schedule an update some time in the
future, and then schedule_now(), we should reschedule the frame clock to
update immediately, and not some time in the future.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
If we get a "ready" page flip feedback, it means the page flip was
symbolic, i.e. not real, e.g. as a result of an update that didn't
change the state of the primary plane. Warn if there is a "next fb"
meaning we expected to have a new buffer that we flipped to.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This is intended to be used only for plane assignment, and CRTC like
changes, so that one can e.g. change a cursor plane on a pending update
that changes the primary plane, before it has been committed to KMS.
The kms-updates test overrides the get-state function MetaKmsCrtc. This
is needd to not have the update mechanism not clamp the gamma size to 0,
as vkms reports the gamma length 0. By pretending it's 3, we can test a
simple and small gamma lut is merged correctly when merging updates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2854>
This looks like a bug: There's no reason why windows which advertise
min-size hints that are exactly the size of the workarea should not be
allowed to maximize, so change the checks here to allow for that.
The commit message of 7f64d6b9 also makes the point that this was not
intended, as it says "larger than".
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2873>
Surfaces belonging to a screen-casted window should always be considered
visible even if they are not visible on any stage view - be it because
they are on a different workspace, minimized or occluded.
Doing this in an optimal fashion is highly complex right now -
interdependent with (and somewhat similar to) ClutterClones. Thus treat
stream-casted surfaces similar to those with clones, with the small
difference that even a fully invisible surface still gets a primary view
- the fastest one. This ensures that clients never refresh too slow for a
screen-cast, at the cost of sometimes refreshing too fast.
The later only happens on certain multi-monitor setups and should thus be
acceptable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
There is an increasing number of cases where we want the frame callback
logic to run for a stage-view and the complexity needed to avoid these,
combined with the likelyhood of bugs, arguably does not justify the
benefit any more.
Thus unconditionally schedule updates for all stage-views when frame
callbacks are requested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
Screen-casted windows need to be considered visible in various situations
but existing APIs such as `clutter_actor_is_effectively_on_stage_view()`
don't do so. Add new API that allows checking if a surface belongs to a
screen-casted window for the respective cases.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2789>
The introduction of the META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED
flag threw off some checks around keyboard-driven resize. This
was partly because there were some == checks that did not account
for that flag maybe being enabled, but also the handling
of META_GRAB_OP_KEYBOARD_RESIZING_UNKNOWN into a definite
resize direction was maybe unsetting that flag. Fix both things
at the same time.
Fixes: 2d8fa26c8e ("core: Pass "frame action" grab operations as an "unconstrained" grab op")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2629
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2871>
From the scale factors available to it, Mutter will now try to select
the scale factor that makes the UI's size as close as possible to the
size it would be, w/o scaling, on a display at 135 PPI (for mobile
displays) or at 110 PPI (for stationary displays)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2653>
After !2489, the active workspace's MRU list is now used to pick
the next focus window instead of the stack order.
This list is currently only updated on focus, which can lead to
surprising behavior when closing a window after activating its
ShellApp in the shell.
That is because raising a window (as part of shell_app_activate())
will only change the stacking order, so when closing the active
app window, the focus will switch to whatever had focus before the
app was activated, not the app's next window.
In order to allow gnome-shell to address this, add a new
raise_and_make_recent() method that also adjust the MRU order.
https://gitlab.gnome.org/GNOME/mutter/-/issues/2540
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2866>
The pointer to the manager, the peer name and the ID are things that are
always metadata related to a session, so make them properties on the
interface instead of duplicating them. The implementations still need to
keep track of them, but their existance is shared.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This class is intended to be used as a base class for D-bus interface
implementations that deal with "session" objects, i.e. a D-Bus object
representing a certain session of some kind, e.g. a screen cast session.
It handles things such as hooking up to the D-Bus client watcher,
generates IDs, handles shutdown procedures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
It's currently not set by anything, and will only be used by
non-abstract implementations of a future D-Bus interface session
manager. When interface implementations gets ported to this new type,
their MetaDbusSession implementations will set this vfunc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
This means the MetaDbusSession interface takes a more active role
instead of being something that more or less sends signals to the
interface implementor. This will allow better control when using
MetaDbusSession to manage these sessions, instead of their non-abstract
variants.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2713>
Allows for creating LUTs at some fixed size which maintains enough
precision for concatenating or otherwise manipulating the LUT without
having to care about the precision of the hardware.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
If the device supports the atomic API the property based API is used to
write gamma updates and the legacy API is used in the non-atomic case.
The current state is read from the legacy API always though which can be
different from the property API. This commit always uses the correct API
to update the state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2861>
This API will be used by GNOME Shell to handle X11 events
in the relevant places, as a substitute to gdk_window_add_filter().
It is ATM still a bit ironic, since the Mutter X11 event handler
is itself a GdkFilterFunc, but it may move away from that eventually.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2779>
With detach meaning having the onscreen stop listening on configuration
changes on the corresponding backing mode setting objects. We need to do
this as there is a time between rebuilding the views, and that the new
mode sets are called, where the old onscreen is kept alive, but the
stage view is gone. At this point in time, if privacy screen or gamma
configuration changes, e.g. by the night light temperature changing, the
onscreen would attempt to schedule an update on the now gone stage view.
This commit also renames the "keep onscreen alive" to "detached
onscreens" to more clearly communicate that it's detached onscreens from
their corresponding mode setting objects.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2621
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2863>
For the coordinates of pointers or stylii, we translate the ones we store
using the viewport matrix already. For touch events otoh, we store coords
untranslated and translate them later only for event emission.
Let's be consistent here and store the coordinates of touch events
translated, just like we do for pointer events.
This fixes touch window dragging on rotated monitors. MetaWindowDrag calls
clutter_seat_query_state(), which uses those stored coordinates. So in case
of a touch sequence the coords returned by query_state() would be
untranslated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2859>
In the case where we early-out from meta_window_drag_begin(), the
effective_drag_window might not be set yet. In this case, we might finalize
the object before effective_drag_window is set, leading to a NULL pointer
when accessing window->display in hide_tile_preview().
To avoid that crash, add a check whether the window is set already. If no
window is set, we can just skip hiding the preview anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2858>
This fixes an issue when GLFW tries to change the display resolution
while fullscreen where the application window size doesn't get updated
according to the emulated resolution.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2725>
Streams are generally recoverable by the client and errors may happen
e.g. on negotiation failures. Right now we close the stream and
corresponding session, which is neither necessary nor expected by
clients.
Just disable the stream instead and let clients handle things as they
seem fit. This allows clients to e.g. try several Gstreamer pipelines
with limited caps on a single stream.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2850>
Doing it in dispose means the backend is actively tearing down itself,
meaning various components might or might not be there, depending on how
the tearing down is implemented. Make things a bit more robust by doing
any work that might rely on the backend being there before shutdown is
done in response to the 'prepare-shutdown' signal being emitted by the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2853>
Reading upon the history of this code branch (commits 6891ce95dc
and 7a4c808e43 are most relevant), it seems this code is meant to
synchronize Mutter focus state taking the Xserver state as true.
That is, if Mutter tried to change the focus but something truncated
that action, Mutter focus will be changed to be in sync with the
Xserver again.
This sounds backwards in a Wayland session. Mutter focus should be
the canonical source, and not second-guessed from the current Xserver
focus window. These race conditions might still apply between X11
clients, so make these paths only apply in that case.
An example of this breaking can be reproduced with a Spotify and
Firefox window, moving the focus from the first to the second by
going to the GNOME Shell overview in between, and clicking the
Firefox window from there. The Firefox window will be raised, but
refuse to take focus.
It's unclear what made this an issue recently, perhaps commit
0e6395d932 since the now possibly ignored XI_FocusIn/Out events
affect this accounting of the Xserver focused window. Anyhow it
sounds better to ignore these paths for Wayland/native altogether.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2841>
The intention when the offset request was added to protocol was
that the attach request in a new enough protocol version should
require dx/dy to be zero, but ignore them otherwise.
The current code checks for 0, but then overwrites the existing
dx/dy with it, which renders an earlier wl_surface_offset() call
ineffective.
Fixes: #2622
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2843>
This protocol is intended to let special clients create transient-for
relationships between X11 and Wayland windows. The client that needs
this is xdg-desktop-portal-gnome, which will create e.g. file chooser
Wayland dialogs that should be mapped on top of X11 windows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
When modal dialogs are attached, and we set the parent/transient-for
after setting the modal type, the attachedness isn't updated. This is
(apparently) not the case for X11 windows, as they go through a
unmanage/manage dance avoiding the issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The script is a list of newline separated command lines that are sent to
the client one by one as if one would have used e.g.
meta_test_client_do().
It doesn't have error handling as it's expected to be used from tests,
and handling errors in tests that never expects to handle errors is
cumbersome.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
The service channel D-Bus interface aims to be a "back door" for
services that needs special casing in Mutter, e.g. have custom private
protocols only meant to be used by that particular service.
There are currently no special casing implemented; only the basic
service channel infrastructure is added. There is a single method on the
interface, that is meant to eventually be used by
xdg-desktop-portal-gnome to open a Wayland connection with a private
protocol needed for the portal backend's rather special window
management needs.
The service channel Wayland client works by allowing one instance of
each "type", where each time needs to be defined to work in parallel. If
a new service client connects, the old one will be disconnected.
MetaWaylandClient's are used to manage the service clients, and are
assigned the service client type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
One can add a wl_global filter to a wl_display instance, which can be
used to decide what clients should see what globals. This has so far
been used to limit a Xwayland specific protocol extension to only
Xwayland. In order to expand the logic about what globals are filtered
to what clients, introduce a filter manager and port the Xwayland
specific protocol filter to this new manager.
Tests are added, using a new dummy protocol, to ensure that filtering is
working as expected.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
It only tests indirect clients, i.e. not the subprocess part, so far,
but tests explicitly terminating by destroying the MetaWaylandClient
object, as well as the client self terminating and the signal being
emitted.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
This API creates a "client" then later sets up a wl_client and returns a
file descriptor some Wayland client can connect to. It's meant to be
used as a method other than WAYLAND_SOCKET and process launching, e.g.
passing a file descriptor via a D-Bus API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
There will be two kind of client instances, lets move fields that are
only relevant to the current way of operation in an anonymous struct to
keep things a bit separate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2810>
On X11, the stage itself is backed by an XWindow, and moving the
input focus elsewhere will bypass any Clutter-level grabs.
This effectively allows newly opened windows to steal the focus
from gnome-shell itself, which is clearly undesirable. To prevent
that, only allow moving the X11 focus to a Window when no grab is
in place, just like commit 50e89e376 did for the stage focus.
But particularly the updating of x11_display->focus_xwindow is not
prevented. Since it's more consistent to the MetaDisplay/MetaX11Display
dual focus tracking and across Wayland/X11 backends, ensure the X11
input focus is actually set on the last focus Window after the
grabs are gone and windows became interactable again.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
This patch unfortunately results in situations where it is intended
that the focus change happens while a grab is present (e.g. Alt+tab
popup), resulting in confused focus state.
This commit is reverted in order to try a similar approach at a
different level.
This reverts commit 7531669b4f.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2832>
We used it to retrieve a Display, and convert between Atoms and
strings. We can just use the MetaX11Display's Display (It's the
same than GDK's anyways) and use XInternAtom/XGetAtomName for
these conversions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2836>
We didn't always set an implementation, when the foreign toplevel wasn't
found, and when the importer tried to set the parent-child relationship,
the implementation was missing and we'd crash in wl_closure_invoke() in
libwayland-server.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2834>
Windows that are decorated may get configure requests before
the frames client created a corresponding frame window and Mutter
reparented the window.
Since the configure request results in the buffer size being
used to update the window size and the window does not have a
buffer yet, these requests could mistakenly result in the client
window being given a minimal size.
In these situations, do not use the buffer size but the given
size. The window still has to undergo frame creation and
reparenting before being shown for the first time.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2588
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2605
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2808>
This used to be implicitly done by popups using a META_GRAB_OP_WAYLAND_POPUP
MetaDisplay grab. Since commit a8cd488c6f Wayland popups no longer do that,
so the keyboard focus was simply unset if a popup was destroyed while having
the keyboard focus.
Trigger a full input focus sync, so the correct MetaWaylandKeyboard focus
surface is looked up from the focused MetaWindow.
Fixes: a8cd488c6f - wayland: Drop redundant MetaDisplay grab op
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2833>
On one hand, this used to be handled generically in all the paths that
changed the MetaWaylandPointer focus surface, induced by user interaction
or not.
On the other hand, just listening for crossing events is not sufficient
since those also do happen programmatically. We must only listen to
crossing events that have a physical source device, meaning this was
created through user interaction.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/888
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
On Wayland sessions, this handling is unnecessary and even prone
to confusion (e.g. crossing serials are only ignored in X11-exclusive
paths, so this handling competes directly with that in MetaWaylandPointer).
Avoid it entirely there, so MetaWaylandPointer can figure out
sloppy/mouse mode focus for all Wayland/Xwayland surfaces.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
In GTK this is only used for GTK clipboard/DnD selections, and
finding out whether there is a compositing manager in charge.
In Mutter, we manage our own clipboard/DnD selections, and don't
perform any rendering through GTK in the Mutter process.
So there's no special reason to let these events go through GTK,
and (related to xwayland-on-demand?) there may be race conditions
in the handling of the second feature.
There's a chance this race condition may be in Mutter, but it
does not sound worth to chase this race condition when we can
let GTK ignore these events. And it does not make sense to "fix"
gtk3 for this Mutter-only condition, when we intend to eventually
avoid it.
So, take the easy path and ignore these events.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2617
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2831>
The first monitor in stacking tests is the primary monitor but that
doesn't have to stay this way forever. Instead of special casing the
name "primary" to refer to whatever monitor happens to be the primary
monitor, we add an `assert_primary_monitor` command to verify that the
monitor that should be the primary monitor actually is.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
New add_monitor command for adding secondary monitors. Support setting
the workspaces-only-on-primary preference.
The stacking test tests the focus and stacking for multiple monitors
with workspaces-only-on-primary=true. The default_focus changes
previously broke this.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2748>
bind_output() creates output interface resource, but does not
set implementation for it when wayland_output->monitor is NULL.
However, when the wayland library is running wl_closure_invoke(),
it expects the implementation to be non-NULL, and if not, it just
segfaults mutter by NULL pointer dereference.
This commit tries to address this issue by setting an implementation
when wayland_output->monitor is NULL. This could help prevent crash
when resuming from suspend or hotplugging displays.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2570
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2827>
The order of dependencies influences the order of -L arguments to gcc/ld,
we should put our private library first, so that introspection prefers
looking up libraries in private paths than public ones.
This could bring problems in API updates of the libmutter-test library,
since introspection would still prefer the old installed one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2826>
ClutterActions now no longer receive their events via
clutter_actor_event(), instead they get special treatment by the stage
now. Make the MetaGestureTracker work with this and stop emitting events
directly to Clutter via clutter_actor_event(), but instead let them get
through to Clutter (but still not to Wayland).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
The previous logic tried to keep the position of the top left corner of
the window relative to the top left corner of the monitor. This allowed
the window to move out of the target monitor. This change keeps the
proportions of the distance between the window and the monitor borders
instead if possible. Otherwise it keeps the relative position of the
center of the window clamped to [0,1] to make sure the window lands on
the right output.
This also slightly changes what monitor is considered to be on: the
monitor which contains the center of the window and, if the center is on
no monitor, the monitor wich overlaps the most with the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2591>
This partly reverts f9857cb8 but leaves an exception for cursor
surfaces in place, as some apps/toolkits will likely not get updated
anytime soon to ensure cursor themes comply with the Wayland spec.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2815>
So we can remove the additional `next_fb` and `current_fb` pointers from
`MetaOnscreenNativeSecondaryGpuState`.
Some non-scanout buffers also need to be held in the case of GL blitting
which completes in the background. Those are referenced from the scanout
buffers themselves to ensure the source buffers live just as long.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2087>
As with GAMMA_LUT, track whether privacy screen state has been pushed to
KMS in the onscreen. This leaves MetaOutput and MetaCrtc to be about
configuration, and not application.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
As with CRTC GAMMA_LUT, we're moving towards making the entity managing
KMS updates aware if there are any changes to be made, and whether KMS
updates are actually needed or not, and for privacy screen changes, this
means we need to communicate whether the privacy screen state is valid
or not. This allows the caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We're moving towards making the entity managing KMS updates aware if
there are any changes to be made, and whether KMS updates are actually
needed or not, and for GAMMA_LUT changes, this means we need to
communicate whether the GAMMA_LUT state is valid or not. This allows the
caller to create any needed MetaKmsUpdate.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2814>
We may fall through these paths on --nested too, resulting in us poking the
wrong internals from the wrong MetaRenderer subclass. Fixes launching of
clients using wl_drm in --nested.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2818>
Running each stacking test as a separate installed-test is analogous to
what was done for build-time tests in c6d1cf4a (!442) and should make it
easier to track regressions, by being able to see whether a regression
is specific to one .metatest script or applies to more than one.
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2773>
While completely untested, at least this makes it work "in theory"
again. Before it'd listen to signals on the stage, but have an incorrect
type signature to handle the test paint procedures, meaning it'd
probably crash or cause memory corruptions.
What was needed was a signal which in the callback the test could call
some cogl functions to paint on the framebuffer. While there is no such
signal on the stage, and the ClutterActor::paint signal (which they
probably used in the past) is long gone, lets add a "test actor" that is
just a wrapper that adds that paint signal with a paint context.
The tests that need it are changed to add this actor to the stage, and
to listen to the paint signal on the actor instead of incorrectly
listening on stage signals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2807>
At least indirectly, this is set as object qdata while the
window drag is ongoing, and reset/reconstructed if needed.
Consequently, this edge data does not need to be stored in
the MetaDisplay struct anymore.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Even though the data is still stored in the display, add a "high
level" meta_window_drag_update_edges() call, so that the cached
edges may be updated while a window drag operation is ongoing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is a public API change. Add device/sequence parameters to this
operation, so that window dragging and resizing can stick to one
set of pointing events of them all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since MetaWindowDrag took a lot of this code to handle window drags
internally with less interactions with the rest of the stack, this
code in display/window/keybindings is unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Flip the switch in using MetaWindowDrag, leaving display grab
ops and a bunch other code unused. Some places checked the grab op
and/or window in complex ways, others just checked for grab existence
and should now look for clutter ones, and others already were already
doing this in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This helper object (and the whole window drag operation) will be
requested to the compositor instead of created directly, and only
one of those can exist at a time, so the compositor will also
safeguard that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Since SSD X11 windows require synchronization between frame and client
windows on resizes, updates do not always happen immediately but in
control of external factors (i.e. when both windows become to have
a coherent size).
This method will be used to update the window position between
resize/sync operations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This compositor-side object will single-handedly drive a window
drag operation. Currently, this largely copies meta_display_begin_grab_op
and meta_display_end_grab_op, except grabbing is done through a
ClutterGrab instead of direct meta_backend_grab_device() calls. This
also means that the switch from passive to active keyboard grabs is
handled differently.
Currently, this object is dormant. It requires moving more code from
other places to become a fully functional replacement.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
We only allow partial grabs in the case of a keyboard-type MetaGrabOp
happening while the pointer cannot be grabbed. In that case, it's not
a big stretch to unconditionally ungrab the pointer device at the time
of undoing the grab, as it will be always ineffective (not even implicit
grabs on frame windows can happen now, inside Mutter).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary, since the SSD frames are no longer
part of Mutter process, so it is not the MetaX11Display connection
which holds the implicit grab when a mouse button is pressed over
a window frame (say, to start a drag).
As the SSD frames client communicates the same way than CSD windows
for window operations, it is also expected to undo its implicit
grab before requesting a window move/resize operation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The final effect of this boolean can now be expressed through the
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag to MetaGrabOp. Use that
in the relevant places, and drop the argument.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Now that it is called from a single place, there's a few arguments
that are unnecessary:
- button and modifiers are unused
- already_grabbed was originally added to handle grab transitions between
window menus (GtkMenus, back in the day) with display grabs. It's no
longer necessary now
- frame_action can be passed through the META_GRAB_OP_WINDOW_FLAG UNCONSTRAINED
flag
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Leave meta_window_begin_grab_op() as the only public API to initiate
a display grab. There's no longer grab operations that don't attain
windows, and ending these grabs usually happen through user interaction
when the right circumstances happen.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
There is no longer reason to call meta_display_begin_grab_op() except
for window grab operations, and meta_window_begin_grab_op() is a
perfectly fine entry point for all window grab operations.
Move away from meta_display_begin_grab_op().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Currently, it is thought out to be called with META_GRAB_OP_KEYBOARD*
grab op parameters. Make it more generic so it can also be called for
pointer operations (avoiding pointer warping in that situation).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Unlike the comment suggests, this piece of event handling manages
the ungrabbing of a window on button press in the following 2
conditions:
- If a keyboard grab operation was triggered, the window does
additionally follow the pointer, and first button press ends
the grab.
- If a button-press grab is ongoing on the window, but more buttons
are pressed.
We can simplify this to just happen every time a button press event
is received while a window grab op is ongoing. The only case where
this might diverge a bit is same button presses from different
pointer devices, and it's not a big stretch to also undo the grab
in that situation.
This also happens to make the "button" argument in
meta_display_begin_grab_op() completely unused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The frame_action boolean is only used by constraints.c code, in order to
determine whether a moving window should be able to move past the top
bar or not.
We can avoid the special casing by passing this information as a
META_GRAB_OP_WINDOW_FLAG_UNCONSTRAINED flag passed with the grab op.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This is no longer necessary to prevent the bits we wanted to be
prevented by the presence of this grab. We can drop this, and
let it work through the MetaWaylandPointerGrab interface.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
The whole reason for META_GRAB_OP_WAYLAND_POPUP to exist is to
avoid windows from being activatable/movable/resizable when a
grabbing xdg_popup is active.
Use the meta_display_is_grabbed() method which can tell this
from existing MetaWaylandCompositor grabs, so that this remains
true after dropping META_GRAB_OP_WAYLAND_POPUP.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Make this public API check just return a boolean about whether
there is an existing grab, instead of exposing MetaGrabOp.
It is desirable to avoid exposing details like
META_GRAB_OP_WAYLAND_POPUP, so that MetaDisplay and wayland
grabs can port to ClutterGrab at their own pace, but also
this further information is unused.
This is likely to be temporary API anyways, after both
MetaDisplay and wayland grabs port to Clutter, it will be
possible to check the ClutterStage for all of them.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
Rewrite this codepath so it handles the grab ops that it cares
about, and ignores the rest. This way the code works despite
possible future modifications to MetaGrabOp (e.g.
META_GRAB_OP_WAYLAND_POPUP removal).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
This piece of event handling only applies on windows receiving events while
the display is ungrabbed (i.e. for raising it, or beginning a move/resize
operation).
Move the checks on the current grab operation outside of window.c and into
events.c, so all checks about the current grab operation move closer to the
main event handler.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2683>
When sysprof-4 and libsysprof-capture-4 are installed into different
prefixes, such as with Nix package manager, the D-Bus interfaces
are likely not discoverable from the latter package.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2572>
The GQueue node for transactions are inlined in the transaction struct,
meaning we should never let the GQueue API free the node itself, as that
actuall frees the transaction itself.
We did this during tear down if there were left-over transactions,
meaning we ended up with use-after-free issues after having popped
transactions from the queue.
Fix this by just popping the link itself, which won't attempt to free
it. It is effectively freed when freeing the transaction itself so we
won't leak any memory.
Fixes: 56260e3e07
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2805>
During grabs, it is expected that the X11 focus does not correspond
to the display's focus window, as focus should be on the stage's
XWindow instead.
This still messes up the keyboard focus even after we stopped moving
the X11 focus, because we end up with a presumed X11 focus window
of None, and as a result the stage is considered unfocused.
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5932
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2776>
When the pointer crosses monitors, we account for a single motion event
resulting in the pointer moving across more than 2 monitors, in order
to correctly account each monitor scale and the distance traversed
across each monitor in the resulting relative motion vector.
However, memory on the direction is kept short, each iteration to
find the target view just remembers the direction it came from. This
brings a pathological case with 4 monitors with the same resolution
in a 2x2 grid, and a motion vector that crosses monitors at the
intersection of all 4 in a perfect diagonal. (Say, monitors are
all 1920x1080 and pointer moves from 1920,1080 to 1919,1079).
In that case, the intersection point at the crossing between 4
monitors (say, 1920,1080) will be considered to intersect with 2
edges of each view. Since there is always at least 2 directions to
try, the loop will always find the direction other than the one
it came from, and as a result endlessly jump across all 4 possible
choices.
In order to fix this, consider only the global v/h directions,
we already know if the pointer moves left/right or up/down, so
only consider those directions to jump across monitors.
For the case at hand, this will result in three monitors visited,
(either bottomright/bottomleft/topleft, or bottomright/topright/topleft)
with a total distance of 0,0 in the middle one, effectively
resulting in a correct diagonal motion.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2598
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Refactor code so that variables don't depend the on motion line
content, but the other way around. This makes it clearer what each
vector means.
This has no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Some tests expect warnings to be logged, and handle that using
g_test_expect_message(). However, if debug topics are enabled, this
causes g_logv() to expect expected messages to also contain entries with
the debug level 'message' or higher to be listed in the expected message
list. Since meta_topic() always logged using g_message(), enabling debug
topics caused any test that used g_test_expect_message() and had debug
logging somewhere along the code path to fail.
Fix this by changing the log level of meta_topic() to 'debug' if we're
in a test. This doesn't mean they won't be visible, they still will
since debug log entries are printed by default during testing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2800>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
It was missing a cairo_region_t. This also needs adapting the test case,
since prior to this, we didn't actually bump the paint counter when
painting.
When a scanout test isn't waiting to go from compositing to scanout, but
from scanout to compositing, we should not early out when we actually
composited, since that's what we're expecting to see.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
We might end up with a NULL opaque_region here in some circumstances
(client deleted _NET_WM_OPAQUE_REGION, or passed invalid data or a
region with 0 rectangles), account for that when freeing the variable.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
These frames client will use a visual with alpha information, and
report the opaque frame shapes through the _NET_WM_OPAQUE_REGION
window property. We can use this information in the Mutter side
for accurate opaque shapes, despite X11 windows with frames now
being seen as possibly transparent.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
Since the windows created by the frames client will have a RGBA visual, we
no longer can perform simple tests about whether the window is opaque. For
that, we will need to additionally know whether the client-side window has
a visual with an alpha channel.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2758>
This does nothing wrt making race conditions shorter in the
X11 window manager switch case, but is a nice to have in order
to ensure an orderly shutdown of X11 stuff.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2796>
Restarting a X11 window manager is a busy process, trying to leniently
quit the main loop may result in old and new instances each having a
frames client up and running, and the window handover to be less clean
than it should due to the frames client that is about to exit still
being able to react to the batch of events resulting from the window
manager switch that is already undergoing.
In order to avoid extending this transition period any long, make
the frames client exit() the process immediately when SIGTERM is
gotten from the parent process.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2796>
Writing to fields (in this case the MetaColorDevice::pending_state) in
response to an asynchronous operation that was cancelled means we'll
write to an arbitrary memory location, potentially causing segmentation
faults or memory corruption.
Avoid these segfaults or memory corruption by only updating state if we
weren't cancelled. Also avoid trying to dereference the device pointer
if we're cancelled.
The memory corruption due to this has been causing test flakyness in the
monitor unit tests due, which should now hopefully be fixed.
Fixes: 19837796fe
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2794>
I hit this rare error running the "x11" test from the suite locally:
(mutter:194027): Gdk-ERROR **: 18:21:52.525: The program 'mutter' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 663 error_code 9 request_code 143 (DAMAGE) minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
The only call from the Damage extension in use by Mutter that could
return BadDrawable is XDamageCreate(), and it's likely to be this
call. Wrap this X11 in an error trap, in order to catch possible
failures.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2793>
Flushing the input thread might implicitly iterate the mainloop, and thus
update the stage while still inside the clutter_test_flush_input() call.
This means the stage update has already happened when we call
wait_stage_updated(), and that's why we call clutter_stage_schedule_update()
there currently.
This clutter_stage_schedule_update() call is not necessary though, instead
we can flush the input thread from inside wait_stage_updated() after
setting was_updated to FALSE.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2792>
If the window is unmapped or otherwise unmanaged while still existing,
we would fail to let the frames client follow up in destroying the
frame for the window.
Delete the _MUTTER_NEEDS_FRAME property, so that the frames client
can react to meta_window_destroy_frame(), this avoids stale invisible
frame windows for clients that simply unmap windows to reuse them
later.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2791>
Recent versions of Xwayland can allow or disallow X11 clients from
different endianess to connect.
Add a setting to configure this feature from mutter, who spawns
Xwayland.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785>
This define was dropped by commit 0e8aaebc00 (xwayland: Make
XSetIOErrorExitHandler() mandatory), but some #ifdef checks were
brought back by commit 36f30341ac (wayland: Add a prepare-shutdown
signal).
Since there's no define anymore in config.h, these pieces of code
were unintentionally disabled, and a meta_get_display() call be
also left over. Remove the ifdefs and update the code to build
again.
Fixes: 36f30341ac - wayland: Add a prepare-shutdown signal
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2786>
This XChangeWindowAttributes call was never surrounded by an error trap
and was not really expected to fail with BadWindow since the frame window
would be owned by Mutter itself.
This however is no longer true, and we might be getting a BadWindow from
the frame window given the right timing.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2745>
Commit 4e0ffba5c attempted to fix initialization of keyboard a11y,
but mousekeys do attempt to create a virtual input device at a
time that it is too early to try to create one.
Defer this operation until keyboard devices are added, so that
we are ensured to already have the seat input thread set up.
Fixes: 4e0ffba5c - backends/native: Initialize keyboard a11y on startup
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2778>
Quoting Carlos:
The META_PRIORITY_EVENTS ± 1 happening below are in order to set these idles
and timeouts in a priority that is relative to the literal GDK event priority,
making those diverge is a likely way to sneakily break things.
But that's unlikely to happen, and decoupling mutter from GTK further
should make it moot, so perhaps it's alright after all.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
Clutter has an API to get the text direction but used to depend
on gtk3's translation domain. In order to avoid broken i18n
in case gtk3 is not installed, move the transtalable string to
clutter itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2407>
There are two tests; one checks that clearing with a color that cannot
be represented using 8 bits per channel doesn't loose precision when
painted, then read back using glReadPixels(). Would the texture backing
store have 8 bits per channel instead of 10, we'd get a different value
back.
The other test checks that painting from one fbo to another also doesn't
loose that precision.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2461>
Commit bf84b24 created meta-enums.h but it's pretty empty so far, the
vast majority of enum definitions is still in common.h.
Move the Meta enum definitions to meta-enums.h as one would expect them
to be found.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2467>
This replaces the v1 implementation, which is now renamed to
legacy-xdg-foreign. Both implementations use the same data structures
internally, so that protocol version mismatches between
the importer client and exporter client don't fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2770>
Things like meta_compositor_destroy() and meta_compositor_add_window()
isn't intended to be used externally, and if they was, things would
probably fall apart rather quickly.
MetaCompositor also isn't introspected, meaning things that technically
belong to the compositing parts isn't easily available via some object,
but much take detours via other objects like MetaDisplay.
So move the API intended for internal usage to compositor-private.h, and
leave API that is meant to be expose in the public compositor.h.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The "later" API is used to queue actions in relation to compositing,
thus is owned by the MetaCompositor instance. Make users of this
functionality get MetaLaters instance from the compositor, and stop
using the global meta_later() API.
display: Use non-singleton MetaLater API
tests: Use non-singleton MetaLater API
meta/common: Make docs refer to context aware MetaLater API
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means we can eliminate the use of scattered singletons that isn't
added by the tests or the test framework itself.
tests: Don't get backend from old singleton getter
Either use the ownership chain, or the explicit test context instance
pointer.
tests/wayland: Pass context to test client constructor
So that we can get the Wayland compositor directly from the context.
tests: Don't get display from singleton
tests/client: Make test client carry a context pointer
tests/runner: Have test cases carry a context pointer
tests/wayland/test-driver: Get backend from context
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Instead of passing around state using GINT_TO_POINTER() pass around a
state struct that also carries a pointer to the context. This allows
avoiding using old singletons for getting a window list.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
On the path towards clear ownership chains and always using them to find
other components, do the same for X11 client support paths too.
x11-display: Don't get backend from signleton
x11/selection: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
The API has no concept of user data, and requires the user to some how
get an instance without context, i.e. via static globals. Limit this to
the file where this is needed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with the backend commit, this means all objects can reach the
MetaContext by walking up the chain, thus can e.g. get the backend from
the context, instead of the global singleton.
This also is a squashed commit containing:
compositor: Get backend via the context
The MetaCompositor instance is owned by MetaDisplay, which is owned by
MetaContext. Get the backend via that chain of ownership.
dnd: Don't get backend from singleton
window-actor: Don't get backend from singleton
dnd: Don't get Wayland compositor via singleton
background: Don't get the monitor manager from the singleton
plugins: Don't get backend from singleton
This applies to MetaPlugin, it's manager class, and the default plugin.
feedback-actor: Pass a compositor pointer when constructing
This allows getting to the display.
later: Keep a pointer to the manager object
This allows using the non-singleton API in idle callbacks.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As elsewhere, make sure objects that need to have a ownership up to the
context, and use this ownership chain to find relevant components, such
as the backend or the Wayland compositor object instance.
wayland/data-device: Hook up data devices to seats
They are tied to a seat - make that connection in struct fields too, so
that related objects can get to the context via it.
wayland: Don't get Wayland compositor via singleton getter
This means via the ownership chain or equivalent.
xwayland: Hook up manager to Wayland compositor
Same applies to the drag-n-drop struct.
xwayland: Make X11 event handling compositor instance aware
This avoids finding it via singletons in the callee.
xwayland: Don't get Wayland compositor from singleton
xwayland: Pass manager when handling dnd event
window/xwayland: Don't get Wayland compositor from singleton
xwayland/grab-keyboard: Don't get backend from singleton
xwayland: Don't get backend from singleton
wayland: Always get the backend from the context
This means traveling up the ownership chain or equivalent when
necessary.
wayland: Hook up data devices, offers and sources to the compositor
This allows tying them to a context without going through any
singletons.
wayland: Don't get display from singleton
xwayland: Don't get display from singleton
tablet: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
As with other parts, make objects have the ability to walk up the
ownership chain to the context, to get things like the Wayland
compositor or backend instances.
Contains these squashed commits:
display: Don't get backend from singleton
window: Don't get backend from singleton
keybindings: Don't get backend from singleton
workspace: Don't get backend from singleton
display: Don't get Wayland compositor from singleton
selection: Add display getter
context/main: Get backend directly from the context
clipboard-manager: Don't get display from singleton
stack-tracker: Don't use singleton MetaLater API
startup-notification: Hook up sequences and activations to display
This allows using context aware API directly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
This means objects have an owner, where the chain eventually always
leads to a MetaContext. This also means that all objects can find their
way to other object instances via the chain, instead of scattered global
singletons.
This is a squashed commit originally containing the following:
cursor-tracker: Don't get backend from singleton
idle-manager: Don't get backend from singleton
input-device: Pass pointer to backend during construction
The backend is needed during construction to get the wacom database.
input-mapper: Pass backend when constructing
monitor: Don't get backend from singleton
monitor-manager: Get backend directly from monitor manager
remote: Get backend from manager class
For the remote desktop and screen cast implementations, replace getting
the backend from singletons with getting it via the manager classes.
launcher: Pass backend during construction
device-pool: Pass backend during construction
Instead of passing the (maybe null) launcher, pass the backend, and get
the launcher from there. That way we always have a way to some known
context from the device pool.
drm-buffer/gbm: Get backend via device pool
cursor-renderer: Get backend directly from renderer
input-device: Get backend getter
input-settings: Add backend construct property and getter
input-settings/x11: Don't get backend from singleton
renderer: Get backend from renderer itself
seat-impl: Add backend getter
seat/native: Get backend from instance struct
stage-impl: Get backend from stage impl itself
x11/xkb-a11y: Don't get backend from singleton
backend/x11/nested: Don't get Wayland compositor from singleton
crtc: Add backend property
Adding a link to the GPU isn't enough; the virtual CRTCs of virtual
monitors doesn't have one.
cursor-tracker: Don't get display from singleton
remote: Don't get display from singleton
seat: Don't get display from singleton
backend/x11: Don't get display from singleton
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
While already cleaning up API, if this should ever be more non-static
than a constant, it's better if its a function on the monitor manager
instance than something static.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2718>
Since the Wacom panel rewrite, the "output" setting is handled as
a kind of tri-state for display-integrated tablets:
- If the setting is unset, the device is automatically mapped
to an output
- If the setting is set and not empty, the device is mapped to
the output defined by the EDID data
- If the setting is ['', '', ''], the device is mapped to the
span of all displays, like opaque tablets do.
This distinction for the unset setting fell through the cracks,
so both "Automatic" and "All displays" options were handled as
the former.
Add this distinction, so that display-integrated tablets can
be used like opaque tablets of sorts with no limitations.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2767>
These are the ones attached to a display, thus they are the ones that may need
help from this heuristic. Non-integrated tablets (e.g. Intuos) will default to
the span of all monitors.
Fixes mapping of opaque tablets if a display-integrated tablet of the same
brand is also plugged in.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2767>
This might happen when the workspace is not switched and
focus_default_window is called or when 'workspace on primary display
only' is enabled, a secondary display exists and the workspace is
switched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2747>
There's 2 users of this, meta_display_sync_wayland_input_focus() which
does already perform these checks on its own, and MetaCursorTracker's
update_displayed_cursor() to determine whether it should go with the
Wayland client's cursor.
This second check should also consider the existing ClutterGrabs, so
make meta_display_windows_are_interactable() handle them for both
callers.
Fixes the cursor shown over windows while e.g. there are menus opened.
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/2553
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2754>
This code path is important for "empty" commits to ensure we schedule
frame callbacks even if previous commits didn't cause stage redraws.
There is, however, no reason to schedule updates on all stage views
instead of only those the actor is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
Avoid some allocations, save some CPU cycles and make the code easier
to read.
Behaviourwise the only expected change is that now, if there are mapped
clones, we unconditionally choose the view with the highest refresh
rate the actor (or one of its clones) is on and don't check the
obscurred region any more.
Thus in some cases a client may receive a higher rate of frame callbacks
when obscured on a faster view while a clone is present on a slower
one. The assumption is that cases like this are relatively rare and
that the reduction of code complexity, the reduction of allocations in
`meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is
not fully obscured and has clones on other views, as well as generally
fewer lookups and less code in most common cases, compensate for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
We only support feedback-actors, such as DnD-icons, in the compositing
path at the moment.
The approach is similar to how we handle certain shell elements.
Implementations need to ensure no references to the object keep
around longer that necessary.
Arguably this should be replaced by a more robust and implicit actor
hierachy detection in the direct scanout code at some point.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2470
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2677>
The fields of 'priv->video_format.max_framerate' are all of type
uint32_t. Multiplying by G_USEC_PER_SEC can overflow, and equally,
dividing a large numerical type by uint32_t can err too.
Since the variable holding the result is int64_t, cast all uint32_t
fields to int64_t before doing any maths on it.
Spotted while trying to investigating an issue with framerates on
HDMI screencasts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2762>
Add a helper function that ensures any queued virtual input events have
been flushed from the input thread. This works by posting a task to the
input thread, which will itself queue another callback back to the main
thread. Once the main thread callback is invoked, the flush call is
unblocked and the function returns. Upon this, any previously emitted
virtual input event should have already passed through the input thread
back into the main thread, however not necessarily fully processed.
For making sure it has been processed, one also have to make sure the
stage has been updated, e.g. via `meta_wait_for_paint()`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2727>
After the commit "wayland/subsurface: Implement
meta_wayland_surface_get_window()" subsurfaces are supported. Adjust
some comments and fix a warning that could occur when closing a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The intention here was to check if the subsurface belongs to a window.
Thus it didn't behave as expected for subsurfaces belonging to non-toplevel
windows.
After the previous commit we can use `get_window()` to check for what we
actually want here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
Subsurfaces are special regarding windows as they don't have a window,
but usually have an ancestor which does. All current users of
`get_window()` are either used for known surface roles, such as xdg-*
ones, or, as is the case for pointer constrains, would actually want to
get the ancestors window.
Thus implement `get_window()` to allow pointer constrains to work.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2223
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The meta_prop_get_motif_hints() function was only used in the
old MetaUI frames code. The remaining code in mutter accesses
directly the MetaPropValue when loading properties for a window,
and does not use this API call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
Since we use XCB in the Mutter side, but Xlib in the frames client,
we cannot share the same struct definition since both libraries
will expect different type lengths (respectively, 32-bit ints vs.
longs).
Revert the changes that made both executables share the same
struct, since not both of them can get it right (and retrieve
correctly the struct with the contained flags) in reading the
Motif WM hints.
This reverts commit 2fb3c5a4f5.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
Adding the 'default-decoration' CSS class to MetaFrameHeader after
it is set as the headerbar makes it not account for the minimum size
correctly sometimes. This is a bit racy though - if the window opens
very quickly, it works as expected.
Adding the CSS class before the widget is used guarantees it'll
always report the correct size though, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2753>
Add this CSS class both to the header bar itself, since it is what
actually contains the window controls, and to MetaFrameHeader too,
since it's what's directly attached to the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
Previous commit added support for setting the GTK4 theme setting
according to the color scheme setting. That's cool. What it didn't
add, though, was initializing the GTK4 theme setting to the proper
value. That means if the desktop starts at dark style, you'd still
get a light titlebar.
Fix that by updating the GTK4 theme setting on init as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
These are now referenced on the frames client side (in order to
track deletable state from the client window) and the mutter side
(pretty much everything else, like figuring out if a window wants
WM decorations).
It makes sense to make this a separate header, so that we don't
need to doubly define these flags/structs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
We use this for tracking the deletable state of the client window,
but forgot to check that the MWM_HINT_FUNCTIONS hint is set in
hints.flags before checking hints.functions.
This resulted in windows that do not specify this flag (and thus
should go with the defaults) in being mistakenly removed the close
button, as the functions flags would be typically 0 in that case.
Fixes issues with Chromium and Electron applications missing the
close button, since Chromium does this on X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
Recalculating window features is a busy thing on the Mutter side, the
different properties being (re)set will overwrite the current state
and cause some side work. Between that is the rewriting of the
_MUTTER_NEEDS_FRAME property on the window being recalculated, which
throws the frames client off, by thinking the window does actually
require a new frame.
It is not sufficient to trust that PropertyNewValue means the property
or the value are new, also double check that the window did not have
in fact a frame, and avoid the busy work if it did.
Besides the busywork that can be easily avoided, this also fixes the
window close button state being stuck if the window changed its
deletable state, since the frame being respawn managed to miss the
property change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
meta_screen_cast_window_stream_src_set_cursor_metadata() relies
entirely on meta_screen_cast_window_transform_cursor_position()
to return the correct relative cursor position.
However, this function actually does not return the expected
values, since it does not apply the resource scale to the
transformed position.
Actually apply the cursor scale when calculating the cursor
position.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2737>
meta_screen_cast_stream_src_set_cursor_sprite_metadata() receives
the cursor sprite, position, and scale, and with that it downloads
the cursor sprite by drawing it into a separate framebuffer, then
calls cogl_framebuffer_read_pixels() in it - this is the offscren
path that is very common when using screen capturing applications
such as OBS Studio.
There's a sneaky issue in this code path though: the 'scale' value
is a float. The cursor size is then determined by multiplying the
sprite width and height - two integer variables - by scale, and
this relies on standard float-to-int conversions. This is problematic
as sometimes the rounded values disagree with what is expected by
cogl_framebuffer_read_pixels(). If the packing of either the cursor
width or height is off by one, glReadPixels() will try to write into
off bounds, which crashes.
This can be reproduced by enabling fractional scaling, setting a 150%
zoom level, on a 4K screen, and opening any commit with an image diff
in gitlab.gnome.org, all while screencasting. When hovering the new
image, the cursor sprite will be such that it triggers this code path,
and reproduces this issue.
Fix this by always ceiling the cursor sprite sizes.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2542
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2736>
The uninitialized fields in this event causes use of uninitialised
data as seen in valgrind:
==71864== Syscall param writev(vector[0]) points to uninitialised byte(s)
==71864== at 0x5026EBD: __writev (writev.c:26)
==71864== by 0x5026EBD: writev (writev.c:24)
==71864== by 0x6482A3B: UnknownInlinedFun (xcb_conn.c:296)
==71864== by 0x6482A3B: _xcb_conn_wait.part.0 (xcb_conn.c:551)
==71864== by 0x6482BAF: UnknownInlinedFun (xcb_out.c:469)
==71864== by 0x6482BAF: _xcb_out_send (xcb_out.c:470)
==71864== by 0x6483DD7: UnknownInlinedFun (xcb_out.c:416)
==71864== by 0x6483DD7: xcb_writev (xcb_out.c:409)
==71864== by 0x53B79B4: _XSend (xcb_io.c:587)
==71864== by 0x53BBF38: _XReply (xcb_io.c:679)
==71864== by 0x53AFFC9: XQueryTree (QuTree.c:47)
==71864== by 0x4982A5F: query_xserver_stack (stack-tracker.c:508)
==71864== by 0x4EA1F5F: g_closure_invoke (gclosure.c:832)
==71864== by 0x4ECFD45: signal_emit_unlocked_R.isra.0 (gsignal.c:3796)
==71864== by 0x4EC0129: g_signal_emit_valist (gsignal.c:3549)
==71864== by 0x4EC03B2: g_signal_emit (gsignal.c:3606)
==71864== Address 0x287d5900 is 32 bytes inside a block of size 16,384 alloc'd
==71864== at 0x4849444: calloc (vg_replace_malloc.c:1340)
==71864== by 0x53A5FE8: XOpenDisplay (OpenDis.c:240)
==71864== by 0x6100E3C: _gdk_x11_display_open (gdkdisplay-x11.c:1565)
==71864== by 0x60CF675: gdk_display_manager_open_display (gdkdisplaymanager.c:462)
==71864== by 0x49D59F1: open_gdk_display (meta-x11-display.c:1041)
==71864== by 0x49D5D64: meta_x11_display_new (meta-x11-display.c:1156)
==71864== by 0x49564AD: meta_display_init_x11_finish (display.c:743)
==71864== by 0x495679D: on_x11_initialized (display.c:818)
==71864== by 0x4D67558: g_task_return_now (gtask.c:1232)
==71864== by 0x4D67782: UnknownInlinedFun (gtask.c:1301)
==71864== by 0x4D67782: g_task_return (gtask.c:1258)
==71864== by 0x495663C: on_xserver_started (display.c:788)
==71864== by 0x4D67558: g_task_return_now (gtask.c:1232)
==71864== Uninitialised value was created by a stack allocation
==71864== at 0x49D4A59: take_manager_selection (meta-x11-display.c:640)
==71864==
To fix this, fully initialize the event struct before sending it.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2535
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2724>
Since the frames are now rendered by a separate process, we no longer
can guarantee at this point that all updates were handled. Engaging
in a new synchronous resize operation will again freeze the actor,
so sometimes we are left with a not-quite-current buffer for the
frame+window surface.
In order to ensure that the right changes made it onscreen, delay
this next synchronous resize step until the moment the surface was
repainted. This avoids those glitches, while still ensuing the
resize operation ends up in sync with the pointer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Let the frames client render its own shadow. In order to do that,
avoid double painting a shadow on the compositor side, and extend
the mask area of the frame, so it does unveil the (so far)
hidden frames-client-side shadows.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
There's two meanings of "frame" there! Since SSD frames are now
rendered by an external client, and there are no actual mechanism
that ensures the frame did already get painted when the client did
respond to its NET_WM_FRAME_SYNC_REQUEST request, there may be
artifacts when resizing windows.
In order to get always the best visual result, we should actually
synchronize rendering with both the client window and the window
frame window.
This commit adds these mechanisms, so a sync alarm update is
expected on both windows until further resizes are allowed, this
ensures window and frame stay in sync, even after moving rendering
elsewhere.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
It will become necessary to track properties and changes from frame windows,
and it will be more convenient to have this managed by the common property
tracking mechanisms.
Add this source_xwindow parameter so property handler functions can check
whether the property belonged to the client Window or the frame Window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Store the alarms in a different hashtable, and look up the MetaSyncCounter
right away. It so far avoids the MetaWindow middle man, but will also be
simpler when each window can possibly have more than one active alarms.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Replace the in-process implementation of frames with the external
frames client.
When a client window is created and managed by Mutter, Mutter will
determine whether it is a window that requires decorations and
hint the creation of a frame for it by setting the _MUTTER_NEEDS_FRAME
property on the client window.
After the frames client created a window that has the _MUTTER_FRAME_FOR
property, Mutter will proceed to reparent the client window on the
frame window, and show them as a single unit.
Rendering and event handling on the frame window will be performed by
the external client, Mutter is still responsible for everything else,
namely resizing client and frame window in synchronization, and
managing updates on the MetaWindowActor.
In order to let the frame be managed by the external client, Mutter
needs to change the way some properties are forwarded to the client
and/or frame windows. Some properties are necessary to keep propagating
to the client window only, some others need to happen on the frame
window now, and some others needs to be propagated on both so they
are synchronized about the behavior.
Also, some events that were previously totally unexpected in frame
windows are now susceptible to happen, so must be allowed now.
MetaFrame in src/core/frame.c now acts as the wrapper of foreign
windows created by the frames client, from the Mutter side. Location,
size, and lifetime are still largely in control of Mutter, some
details like visible/invisible borders are obtained from the client
instead (through the _MUTTER_FRAME_EXTENTS and _GTK_FRAME_EXTENTS
properties, respectively).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This small X11 client takes care of creating frames for client
windows, Mutter will use this client to delegate window frame
rendering and event handling.
The MetaWindowTracker object will keep track of windows created
from other clients, and will await for _MUTTER_NEEDS_FRAME property
updates on those (coming from Mutter), indicating the need for a
frame window.
This process is resilient to restarts of the frames client, existing
windows will be queried during start, and the existence of relevant
properties checked. Mutter will be able to just hide/show
SSD-decorated windows while the frames client restarts.
The frames are created through GTK4 widgets, the MetaWindowContent
widget acts as a replacement prop for the actual client window,
and the MetaFrameHeader wraps GtkHeaderBar so that windows can be
overshrunk, but otherwise a MetaFrame is a 100% true GTK4 GtkWindow.
After a frame window is created for a client window, the
_MUTTER_FRAME_FOR property will be set on the frame window,
indicating to mutter the correspondence between both Windows.
Additionally, the pixel sizes of the visible left/right/top/bottom
borders of the frame will be set through the _MUTTER_FRAME_EXTENTS
property, set on the frame window.
In order to make the frame window behave as the frame for the
client window, a number of properties will be tracked from the
client window to update the relevant frame behavior (window title,
resizability, availability of actions...), and also some forwarding
of events happening in the frame will be forwarded to the client
window (mainly, WM_DELETE_WINDOW when the close button is clicked).
Other than that, the frames are pretty much CSD GTK4 windows, so
window drags and resizes, and window context menus are forwarded for
the WM to handle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This check dates all the way back to commit ac2aa5337d. At the time, the
window switcher was an actual X window, that could generate crossing events
if popped up under the pointer. Checking for this kind of crossing events
made sense back at the time in order not to break focus-follows-mouse as
it's been behaving for long.
But now, this UI is all Clutter widgetry, which in the worst case (X11
sessions, of course) it will update the stage window shape to make these
parts clickable. This happens in other places of code that do already
check for ignoring crossing events.
Underneath, this looked up for a Mutter-local GdkWindow of type
GDK_WINDOW_TEMP, only the main MetaFrames window matches those characteristics
nowadays, notably no window switcher popups. Since the remaining window is
never unmapped (until perhaps shutdown), the paths were functionally dead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
If the window is not managed, it's weird that it asks for _NET_FRAME_EXTENTS,
it's even weirder that mutter replies with a frame border that would only
apply if the window were managed. Stop doing the latter, and drop the
MetaUI call that calculates borders from the theme settings.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Put the helper to use, in order to lift MetaWindow itself from this
accounting. As a bonus, the data itself now moved to the MetaWindowX11
private struct, since this may only happen with X11 windows (or its
Xwayland subclass).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This helper struct takes care of the handling of requests and alarms
in order to satisfy NET_WM_SYNC_REQUEST. It will be necessary to
decouple rendering of windows and frames in future commits, so each
window may need its own synchronization and accounting.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
This may result in a view of the stack in MetaStackManager that does not correspond
to reality, since the window is already being unmanaged, there is no point either in
notifying the stack manager about it.
This slight divergence with reality in the MetaStackManager may produce a non-accurate
view if querying its state has to go through the predicted branches. Later synchronization
with the X11 stack may even this out, but the result really depends on when it is asked.
Fixes some intermittent failures in the stacking/closed-transient-only-take-focus-parents
unit test.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
The meta_window_show() method internally relies on window->mapped being
up-to-date, or attempting to focus it may fail since the window is not
mapped yet, resulting on the window being mapped, but not focused as
it would be expected.
This is moot so far, since windows with frames are created sort-of
synchronously and showing them will result in the focus attempt happening
when the window is already mapped, but things will break when this
becomes an asynchronous step.
Ensure to synchronize client state before showing, so any attempts to
focus the window are able to succeed despite the initial state when
calling meta_window_update_visibility().
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
The test does simply "wait" which apparently is not enough to ensure the
client window did resize to the expected dimensions. Use "wait_reconfigure"
and assert that the size after resize is the expected, before going further
at testing its behavior after maximize/unmaximize; it might end up with the
unexpected size after the whole operation.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2175>
Move the use count from a separate MetaWaylandBufferRef struct to the
MetaWaylandBuffer class, and remove the former.
The buffer use count is now incremented already in
meta_wayland_surface_commit, since the Wayland protocol defines the
buffer to be in use by the compositor at that point. If the buffer
attachment ends up being dropped again before it is applied to the
surface state (e.g. because another buffer is committed to a
synchronized sub-surface before the parent surface is committed),
the use count is now decremented, and a buffer release event is sent if
the use count drops to 0.
Buffer release events were previously incorrectly not sent under these
circumstances. Test case: Run the weston-subsurfaces demo with the -r1
and/or -t1 command line parameter. Resize the window. Before this
change, weston-subsurfaces would freeze or abort after a few resize
operations, because mutter failed to send release events and the
client ran out of usable buffers.
v2:
* Handle NULL priv->buffer_ref in
meta_wayland_cursor_surface_apply_state.
v3:
* Remove MetaWaylandBufferRef altogether, move the use count tracking
to MetaWaylandBuffer itself. Much simpler, and doesn't run into
lifetime issues when mutter shuts down.
v4:
* Warn if use count isn't 0 in meta_wayland_buffer_finalize.
* Keep pending_buffer_resource_destroyed for attached but not yet
committed buffers. If the client attaches a buffer and then destroys
it before commit, we ignore the buffer attachement, same as before
this MR.
v5:
* Rebase on top of new commit which splits up surface->texture.
* MetaWaylandSurfaceState::buffer can only be non-NULL if
::newly_attached is TRUE, simplify accordingly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Until all dma-buf file descriptors for all buffers in the transaction
are readable, which corresponds to when the client drawing to the
buffers has finished.
This fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1162 if the
GPU & drivers support high priority contexts which can preempt lower
priority contexts.
v2:
* Also remove dma-buf fds from transaction and try applying it from
pending_buffer_resource_destroyed. Avoids freeze due to leaving a
GSource based on a closed fd attached if a client destroys a wl_buffer
which is part of a transaction which was committed but not applied
yet. (Robert Mader)
* Tweak transaction cleanup logic in wl_surface_destructor.
v3:
* Adapt to meta_wayland_dma_buf_get_source.
v4:
* Adapt to new commits using transactions for (sub-)surface destruction,
drop code to remove destroyed surfaces from pending transactions.
v5:
* Use g_clear_pointer in meta_wayland_transaction_destroy.
(Georges Basile Stavracas Neto)
* Add spaces between type casts and values. (Carlos Garnacho)
* Use (gpointer *) instead of (void**). (Carlos Garnacho)
* Use gpointer instead of void * in
meta_wayland_transaction_dma_buf_dispatch.
v6:
* Use g_hash_table_remove in meta_wayland_transaction_dma_buf_dispatch.
(Carlos Garnacho)
v7: (Jonas Ådahl)
* Move include of glib-unix.h below that of meta-wayland-transaction.h.
* Split up g_hash_table_iter_next call to multiple lines in
meta_wayland_transaction_commit.
* Call g_source_destroy as well as g_source_unref when freeing a
committed but not yet applied transaction (during mutter shutdown).
v8:
* Drop dma_buf_source_destroy, can use g_source_destroy directly.
(Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
From xdg_surface_constructor_get_popup / xdg_popup_reposition (called
during Wayland protocol processing) to finish_popup_setup /
meta_wayland_xdg_popup_apply_state (called when the popup state is
applied).
This makes sure that the parent window frame rectangle is up to date in
meta_wayland_xdg_positioner_to_placement.
v2:
* Use meta_wayland_surface_state_new () in
meta_wayland_transaction_add_xdg_popup_reposition.
v3:
* Move xdg_popup_repositioned handling to
meta_wayland_xdg_popup_apply_state.
v4:
* Do not steal pending->xdg_positioner in
meta_wayland_xdg_popup_apply_state, fixes leaking the corresponding
memory.
* Drop MetaWaylandSurfaceState::xdg_popup_repositioned, just use
::xdg_positioner.
v5:
* Reformat meta_wayland_xdg_positioner_to_placement calls to stay within
80 columns. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
This makes sure that finish_popup_setup is called after any previous
transactions for the parent surface have been applied, so the parent
window geometry is up to date.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Preparation for potentially calling meta_wayland_transaction_apply some
time after surface commit, in which case doing it in the former would be
too late: The client may legally destroy the attached wl_buffer
immediately after commit, in which case meta_wayland_buffer_attach would
spuriously fail and disconnect the client (or possibly even crash mutter
due to NULL error).
Requires splitting up the surface texture between protocol and output
state, and propagating from the former to the latter via
MetaWaylandSurfaceState.
v2: (Jonas Ådahl)
* Move meta_wayland_surface_get_texture call to separate line.
* Use g_autoptr for GError.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And keep track of the hierarchy separately for the Wayland protocol and
for output. Protocol state is updated immediately as protocol requests
are processed, output state only when the corresponding transaction is
applied (which may be deferred until the next commit of the parent
surface).
v2:
* Directly add placement ops to a transaction, instead of going via
pending_state.
* Use transaction entry for the sub-surface instead of that for its
parent surface.
v3:
* Use transaction entry for the parent surface again, to ensure proper
ordering of placement ops, and call
meta_wayland_surface_notify_subsurface_state_changed only once per
parent surface.
* Drop all use of wl_resource_add_destroy_listener, transactions are
keeping surfaces alive as long as needed.
v4:
* Rebase on https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2501
* Drop ClutterActor code from meta_wayland_surface_apply_placement_ops.
(Robert Mader)
v5:
* Rename MetaWaylandSubSurfaceState to MetaWaylandSurfaceSubState, since
the next commit adds not sub-surface specific state to it.
v6:
* Move include of meta-wayland-subsurface.h from
meta-wayland-transaction.c to .h, since the latter references
MetaWaylandSubsurfacePlacementOp.
v7:
* Drop superfluous !entry check from meta_wayland_transaction_apply.
v8:
* Rename output/protocol fields to output/protocol_state. (Jonas Ådahl)
v9:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_add_placement_op.
v10:
* Fix a few style issues per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Destroy Wayland protocol related state immediately when the Wayland
resource is destroyed, but keep the rest alive by any transaction which
references the surface.
This makes it easier and cleaner to deal with a surface getting
destroyed while it's still referenced by transactions.
v2:
* No more need to keep references for surfaces in the entries hash
table.
v3:
* Do not use surface->sub.transaction in wl_surface_destructor, just
destroy it.
v4:
* No need for wl_surface_destructor to use its own transaction.
v5:
* Use g_steal_pointer & (more) g_clear_pointer in wl_surface_destructor.
v6:
* Leave SURFACE_DESTROY signal emission in wl_surface_destructor.
v7:
* Use finalize instead of dispose callback.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
This keeps all surfaces referenced by a transaction alive until the
transaction is destroyed, and makes sure transactions are applied in
the same order as they were committed with respect to all surfaces
they reference.
v2:
* Guard against NULL entry in meta_wayland_transaction_apply.
v3:
* Keep single entries hash table.
v4:
* Unref the surface in the meta_wayland_transaction_merge_into while
loop only if the "to" transaction didn't already have an entry for it,
to prevent premature finalization of the surface (likely followed by a
crash).
v5:
* Unref the surface (implicitly via g_hash_table_iter_remove) in the
meta_wayland_transaction_merge_into while loop even if the "to"
transaction already had an entry for it, or we leak a reference.
* Use g_clear_object & g_steal_pointer to not leave behind a dangling
from->state pointer in meta_wayland_transaction_entry_merge_into.
v6:
* Add curly braces around
meta_wayland_transaction_add_placement_surfaces calls. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Instead of cached_state.
surface_commit for a synchronized sub-surface either commits the
transaction or merges it into the parent surface's transaction (if
the parent is a synchronized sub-surface itself).
This should fix or at least improve the behaviour of nested synchronized
sub-surfaces.
Also change wl_subsurface_set_desync:
* Commit sub-surface transactions separately. This may allow some of
them to be applied earlier in some cases.
* Commit transaction only for descendant sub-surfaces which become
newly de-synchronized themselves.
v2:
* Drop unused function prototypes
v3:
* Use g_clear_pointer for surface->sub.transaction.
v4:
* Use g_steal_pointer instead of g_clear_pointer. (Sebastian Wick, Jonas
Ådahl)
v5: (Carlos Garnacho)
* Add spaces between type casts and values.
* Use (gpointer *) instead of (void**).
v6: (Jonas Ådahl)
* Use g_clear_object in meta_wayland_transaction_entry_merge_into.
* Use meta_wayland_transaction_entry_free in
meta_wayland_transaction_merge_into.
* Fix alignment of meta_wayland_transaction_merge_pending_state
parameters.
* Remove unused meta_wayland_transaction_add_state declaration.
v7:
* Use meta_wayland_surface_state_new in
meta_wayland_transaction_merge_pending_state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
A transaction contains the committed state for a surface, plus any
cached state for synchronized subsurfaces.
v2:
* Handle sub-surface positions separately from surface states.
v3:
* Sync child states only for surfaces with state in the transaction.
v4: (Jonas Ådahl)
* Drop unnecessary g_object_new call from wl_subsurface_set_desync. (me)
* Fix indentation & formatting in meta_wayland_surface_commit.
* Add meta_wayland_surface_state_new helper function.
* Fix alignment of meta_wayland_transaction_apply_subsurface_position
parameters.
* Add curly braces around meta_wayland_transaction_sync_child_states
call in meta_wayland_transaction_apply.
v5:
* Make meta_wayland_surface_state_new an inline function.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
If multiple transactions have entries for the same surface, they are
applied in the same order as they were committed. Otherwise, they can
be applied in any order.
This is preparation for following changes, transactions are still
applied as soon as they're committed.
v2:
* Move GQueue for transactions to MetaWaylandCompositor (Jonas Ådahl)
v3
* Say "entry for" instead of "state for", since there can be transaction
entries with no state (for surfaces which are getting destroyed).
v4:
* Use a hash table to keep track of all candidate transactions which
might be newly ready to be applied.
* Use clearer function / variable names.
v5:
* Use custom single-linked list instead of hash table for candidate
transactions, ordered by the transaction commit sequence number, so
that they're attempted to be applied in the same order as they were
committed.
* Rename transaction->queue to transaction->committed_queue, and
simplify its handling.
v6: (Carlos Garnacho)
* Add spaces between type casts and values.
* Use (gpointer *) instead of (void**).
v7: (Jonas Ådahl)
* Use G_MAXSIZE instead of ULONG_MAX.
* Fix indentation of meta_wayland_transaction_apply &
meta_wayland_transaction_maybe_apply_one parameters.
* Refactor find_next_transaction_for_surface & ensure_next_candidate
helper functions out of meta_wayland_transaction_apply.
* Refactor has_unapplied_dependencies helper function out of
meta_wayland_transaction_maybe_apply_one.
* Make while (TRUE) loop in meta_wayland_transaction_maybe_apply
consistent with general usage.
* Drop unused value local from meta_wayland_transaction_commit.
* Store pointer to compositor object in transactions, instead of
pointer to the queue of committed transactions.
* Drop tautological g_assert from meta_wayland_transaction_apply. (me)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
v2:
* Use single hash table with struct which will contain all kinds of
state handled by a transaction.
v3:
* Add meta_wayland_transaction_destroy.
v4 (Georges Basile Stavracas Neto)
* Fix struct _MetaWaylandTransaction(Entry) formatting.
* Explicitly test against NULL.
* Use gpointer insteadof void * for
meta_wayland_transaction_entry_destroy.
v5: (Robert Mader)
* Use for loop in is_ancestor.
* Include meta-wayland-transaction.h first in
meta-wayland-transaction.c.
v6:
* Use g_autofree & g_clear_object.
v7: (Jonas Ådahl)
* Rename meta_wayland_transaction_entry_destroy to
meta_wayland_transaction_entry_free.
* Drop g_autofree use from meta_wayland_transaction_entry_free again.
* Make meta_wayland_transaction_entry_free take a
MetaWaylandTransactionEntry pointer.
* Rename meta_wayland_transaction_destroy to
meta_wayland_transaction_free.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Need to deal with surface->resource == NULL and
surface->pending_state == NULL in some places.
v2:
* Avoid expanding conditions to multiple lines.
(Georges Basile Stavracas Neto)
v3:
* Use a single bailout condition in meta_wayland_client_owns_window as
well.
v4:
* Remove spare empty line in meta_wayland_surface_apply_state.
(Robert Mader)
* Add wl_resource_post_error calls in xdg-shell request handlers.
(Robert Mader)
* Drop checks in functions which can only be called if there's a valid
resource.
* Drop more checks which are unnecessary due to leaving the
SURFACE_DESTROY signal emission in wl_surface_destructor later.
v5:
* Move resource = surface->resource assignments to if (!resource) tests.
(Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Creates a GSource which will call the specified dispatch callback when
all dma-buf file descriptors for the buffer have become readable.
v2:
* Hold a reference to the buffer in the source, to prevent the buffer
from getting destroyed before the source.
v3:
* Do not use check callback, handle everything in dispatch callback.
(Dor Askayo)
v4: (Georges Basile Stavracas Neto)
* Define and use MetaWaylandDmaBufSource & MetaWaylandDmaBufSourceDispatch
types.
* Fix meta_wayland_dma_buf_source_dispatch &
meta_wayland_dma_buf_source_funcs formatting.
* Use gpointer instead of void*.
* Rename meta_wayland_dma_buf_get_source to
meta_wayland_dma_buf_create_source. (Carlos Garnacho)
v5:
* Explicitly handle NULL return value. (Jonas Ådahl)
v6:
* Fix style issue per check-style.py.
v7:
* Fix code style harder. (Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
And call it from meta_wayland_buffer_realize. This makes dma-buf fds
available for EGL image type buffers as well.
v2:
* Move buffer->dma_buf.dma_buf assignment value to next line.
(Jonas Ådahl)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880>
Add internal state (starting, running, stopping), and use this instead
of MetaDisplay struct fields to determine whether to start animations.
This fixes issues when we try to animate things when shutting down.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716>
On hotplug, the events we receive from the kernel are async, and
connectors in the kernel come and go as they please. In practice, this
means that calling drmModeGetConnector() twice more or less directly
after each other, there is no guarantee that the latter call will return
anything if the former did.
When updating the connector in response to hotplugs, we'd first update
the list of existing connectors, and following that, query each and
every one again for their current state, to update our internal
representation; only the former handled drmModeGetConnector() returning
NULL, meaning if unlucky, we'd end up doing a null pointer dereference
when trying to update the state.
Handle this by querying the kernel for the current connector state only
once per connector, updating the list of connectors and their
corresponding state at the same time.
Fixes the following crash:
#0 meta_kms_connector_read_state at ../src/backends/native/meta-kms-connector.c:684
#1 meta_kms_connector_update_state at ../src/backends/native/meta-kms-connector.c:767
#2 meta_kms_impl_device_update_states at ../src/backends/native/meta-kms-impl-device.c:916
#3 meta_kms_device_update_states_in_impl at ../src/backends/native/meta-kms-device.c:267
#4 meta_kms_update_states_in_impl at ../src/backends/native/meta-kms.c:604
#5 update_states_in_impl at ../src/backends/native/meta-kms.c:620
#6 meta_kms_run_impl_task_sync at ../src/backends/native/meta-kms.c:435
#7 meta_kms_update_states_sync at ../src/backends/native/meta-kms.c:641
#8 handle_hotplug_event at ../src/backends/native/meta-kms.c:651
#9 on_udev_hotplug at ../src/backends/native/meta-kms.c:668
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2131269
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2709>
There is no need to use the 'bypass-*' method of event processing in the
changed function since in all cases the 'bypass-*' variable was set, any
following event processing functions would ignore the event anyway.
Simplify things a bit by just returning TRUE if the event is consumed.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2714>
We can land inside meta_window_focus() in the middle of changing the
window workspace, because some signal handler of MetaWorkspace's
"window-removed" signal triggers a focus. This can cause a crash in
`g_assert (link)` when updating the MRU list because we still think
we're on the old workspace when actually we are already removed from
this workspaces MRU list.
To avoid crashes like this, bail out of meta_window_focus() when we're
in the middle of a workspace change.
Fixes https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5368
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691>
It's a bad idea to have data like this in the middle of a struct, as it
will easily cause everything behind it to be badly aligned and thus
increase memory access times.
So move all those bitfield booleans to the end of the struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2691>
It is generally assumed here and there that the pointer at all point in
time is within some logical monitor, if there is any logical monitor to
be within.
With the input thread, this was for a short amount of time not reliable,
resulting in crashes in combination with hotplugging or suspend/resume,
where monitors come and go quickly.
What happens is that the pointer at first is within a logical monitor,
but when that logical monitor is removed, while the new monitor
viewports are handed to the input thread, the constraining happens
asynchronously, meaning there is a time between between the new
viewports are sent, and before clutter_seat_query_state() starts
reporting the constrained position.
If a new client mapped a maximized window during this short time frame,
we'd crash with
#0 meta_window_place at ../src/core/place.c:883
#1 place_window_if_needed at ../src/core/constraints.c:562
#2 meta_window_constrain at ../src/core/constraints.c:310
#3 meta_window_move_resize_internal at ../src/core/window.c:3869
#4 meta_window_force_placement at ../src/core/window.c:2120
#5 xdg_toplevel_set_maximized at ../src/wayland/meta-wayland-xdg-shell.c:429
#6 ffi_call_unix64 at ../src/x86/unix64.S:105
#7 ffi_call_int at ../src/x86/ffi64.c:672
#8 wl_closure_invoke at ../src/connection.c:1025
#9 wl_client_connection_data at ../src/wayland-server.c:437
The fix for this is to make sure that the viewports are updated and
pointers constrained synchronously, i.e. the main thread will wait until
after the input thread is done constraining before continuing.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2147502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2711>
We 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>
More or less copied from gnome-settings-daemon. The look up tables are
either calculated based on the VCGT (Video Card Gamma Table) and the
blackbody color for a given temperature, or the blackbody color for a
given temperature alone, if no VCGT is available.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
This means that e.g. custom profiles or calibrated profiles will be
added and registered with colord. This does not use CdIccStore for two
reasons: don't want to generate duplicate entries for auto-generated
EDID or EFI profiles, and we want to store profiles as MetaColorProfile.
It also happens to be the case that CdIcc does synchronous I/O, which
should be avoided everywhere except on startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
It will be used to generate gamma look up tables depending on
temperature.
The temperature comes from org.gnome.SettingsDaemon.Color and
depends on the current night light state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
It uses the org.gnome.SettingsDaemon.Power.Screen D-Bus API. Currently
brightness set if the proxy is not ready are ignored; whether the
brightness value should be cached and set once it appears or whether
color profiles should be reapplied is yet to be decided.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
Instead of passing 4 arguments (red, green and blue arrays as well as a
size), always pass them together in a new struct MetaGammaLut. Makes
things slightly less tedious.
The KMS layer still has its own variant, but lets leave it as that for
now, to keep the KMS layer "below" the cross backend CRTC layer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
In practice, for KMS backend CRTC's, we cache the gamma in the monitor
manager instance, so that anyone asking gets the pending or up to date
value, instead of the potentially not up to date value if one queries
after gamma was scheduled to be updated, and before it was actually
updated.
While this is true, lets still move the API to the MetaCrtc type; the
backend specific implementation can still look up cached values from the
MetaMonitorManager, but for users, it becomes less cumbersome to not
have to go via the monitor manager.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2165>
We created device profiles, that we manage the lifetime of in colord,
but color devices can be assigned profiles other than the ones it was
created for. For example, this can include the standard sRGB profile
provided by colord.
To achieve this, keep track of the default profile of the CdDevice as
the "assigned" color profile of the device. Given this profile
(CdProfile), construct a MetaColorProfile that can then be interacted
with as if it was generated by ourself.
The assigned profile (default profile in colord terms) does nothing
special so far, but will later be used to determine how to apply CRTC
gamma ramps etc.
The sRGB.icc file used in the tests was copied from colord. It was
stated in the repository that it has no known copyright restrictions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
This works similiarly to how MetaColorDevice works, by creating them
asynchronously then signalling the 'ready' signal when done. Also
similarly to MetaColorDevice, the on-demand sync cleanup on finalize is
added, to avoid race conditions when hotplugs happens very rapidly,
e.g. in tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Just as gsd-color does, generate color profiles. This can either be done
from EFI, if available and the color device is associated with a built
in panel, or from the EDID. If no source for a profile is found, none is
created.
The ICC profiles are also stored on disk so that they can be read by
e.g. colord. The on disk stored profiles will only be used for storing,
not reading the profiles, as the autogenerated ones will no matter what
always be loaded to verify the on disk profiles are up to date. If a on
disk profile is not, it will be replaced. This is so that fixes or
improvements to the profile generation will be made available despite
having run an older version earlier.
After generating, add some metadata about the generated file itself
needed by colord, i.e. file MD5 checksum and the file path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Tests that test case EDID is setup correctly, and that color devices for
monitors are created.
tests/color: Add hotplugging tests
Checks that changing the number of connected monitors reflects the
number of current color devices, and that we end up with the correct end
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Ready means it has established the connection to colord and can operate.
Will be used by tests to make sure tests don't fail due to race
conditions when connecting to colord.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
gsd-color provides this API, which exposes details about the night light
state. Currently, gsd-color also turns this state into CRTC gamma
changes, but this will eventually change, and this is a preparation for
this.
The proxy isn't yet used for anything.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2164>
Previously, gsd-color handled adding color devices. It got information
about those via the GnomeRR API, which is part of libgnome-desktop.
libgnome-desktop itself got this information from the
org.gnome.Mutter.DisplayConfig.GetResources() D-Bus method, implemented
by mutter.
Now, mutter itself will add all the monitor color devices itself,
without having to go via gsd-color.
We sometimes need to delete colord devices synchronously, in certain
race conditions when we add and remove devices very quickly (e.g. in
tests). However, we cannot use libcolord's 'sync' API variants, as it
has a nested takes-all main loop as a way to invoke the sync call. This
effectively means we end up sometimes not return from this function in a
timely manner, causing wierd issues.
Instead, create our own sync helper, that uses a separate context that
we temporarly push as the thread-default one.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
This will be needed for adding colord integration without breaking
testing.
The test context is altered to make sure any left over color devices are
cleaned up before starting. This means it becomes possible to run a test
case multiple times without having to restart meta-dbus-runner.py.
Note: Don't use os.getlogin() to get the current username; as that
requires a controlling terminal.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
It's not really about monitors, even though it is used for monitors.
Lets shrink MetaMonitorManager a bit moving it to the backend.
While at it, stop leaking it too.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
What determines whether one MetaMonitor is the same as the other should
be whether the actual monitor is the same. The way to check this is
comparing the EDID vendor/product/serial fields. Whene these are
incomplete, fall back on the 'winsys ID'.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Same applies to MetaOutput. The reason for this is to make it possible
to more reliably know when there was EDID telling us about these
details. This will be used for colord integration.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
We fairly consistently had multiple monitors with the whole
vendor,product,serial tuple identical. If we start relying on making
monitors a bit more unique, e.g. for colord integration, we need to make
two monitors connected distinguishable in order for tests to properly
reflect reality and excercise the correct colord integration paths.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
As for the types of monitor, X11 and KMS are currently assumed to always be
physical, while the virtual ones are assumed to be virtual. In theory
X11 ones could be virtual, but lets not bother. KMS ones can be virtual
in the case of virtual KMS, but we typically use that for testing as if
it was physical, so lets leave it as such.
Will later be used to feed correct information to colord.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Create a color manager type that eventually will be the high level
manager of color related behavior, such as ICC profiles and
color "temperature" a.k.a. night light.
For now, it's only an empty shell. It's also constructed by the actual
backend, as at a later point, the X11 and native color management
implementations will differ.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2141>
Client connections may linger after the test driver is teared down;
handle this gracefully by unsetting the user data on the wl_resource,
and make the resource destructor a no-op, instead of where it would
otherwise remove itself from the resource list. This fixes this crash
seen in CI:
Received signal 11 (SIGSEGV)
#0 g_list_remove() at ../glib/glist.c:596
#1 test_driver_destructor() at ../src/tests/meta-wayland-test-driver.c:219
#2 destroy_resource() at ../src/wayland-server.c:730
#3 for_each_helper() at ../src/wayland-util.c:416
#4 wl_map_for_each() at ../src/wayland-util.c:430
#5 wl_client_destroy() at ../src/wayland-server.c:889
#6 wl_display_destroy_clients() at ../src/wayland-server.c:1482
#7 meta_wayland_compositor_prepare_shutdown() at ../src/wayland/meta-wayland.c:441
#8 meta_context_dispose() at ../src/core/meta-context.c:667
#9 g_object_unref() at ../gobject/gobject.c:3863
#9 g_object_unref() at ../gobject/gobject.c:3780
#10 glib_autoptr_clear_GObject() at /usr/include/glib-2.0/gobject/gobject-autocleanups.h:29
#10 glib_autoptr_clear_MetaContext() at ../src/meta/meta-context.h:32
#10 glib_autoptr_cleanup_MetaContext() at ../src/meta/meta-context.h:32
#10 main() at ../src/tests/wayland-unit-tests.c:707
#11 __libc_start_call_main() in /usr/lib64/libc.so.6
#12 __libc_start_main() in /usr/lib64/libc.so.6
#13 _start() in /builds/GNOME/mutter/build/src/tests/mutter-wayland-unit
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2601>
This reverts an attempt at saving texture memory that was introduced
recently in 16fa2100. It was misguided because the same texture may be
needed in the next frame if a window has multiple previews visible on
screen at once (gnome-shell's overview). Keeping the mipmaps around
seems to reduce the peak render times of the overview by roughly 5%-10%.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2598>
Although its atomic KMS support seems to work at first, mode sets to
anything other than the Xilinx preferred max resolution of 2048x1280
would result in a hang. The xlnx kernel driver is given:
`DRM_MODE_ATOMIC_ALLOW_MODESET | DRM_MODE_PAGE_FLIP_EVENT`
and it does complete the mode set without error, but page flip events
never arrive and so you're frozen on the first frame.
Revert to legacy KMS which has no such problem with non-default modes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2596>
The "activate" and "deactivate" signals on ClutterStage are used by
Cally to track the key-focus when the user is interacting with shell UI.
key-focus only gets tracked while the stage is activated.
Wayland has no concept of the stage receiving focus or not, so right now
the activation state is bound to whether there's a focus_window in
meta_display_sync_wayland_input_focus(). Since display->focus_window is
set pretty much all the time, this effectively binds activation state to
whether the stage holds a grab or not. This is almost good enough, but
it misses cases where key-focus is on the stage without a grab, for
example when keyboard-navigating the panel after using Ctrl+Alt+Tab.
It seems to make more sense to bind the activation state to whether
key-focus is set to an actor or to NULL, so let's do that instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2329>
In the timespan between an activation token being created and the
token being used by the activated application, the surface that started
the activation request may end up destroyed/disposed.
In that case, the token would be left with a stale surface pointer,
maybe causing crashes later on. Set up a destroy notification listener
so that we do know to unset the token surface if that situation arises,
this will result in Mutter not considering the token activatable, thus
maybe issuing the "Application needs attention" notification if the
activated surface did not immediately get focus. In any case this is
better than a compositor crash.
A typical situation where this may happen is "Open With..." dialogs,
since those don't live long after launching the application.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2390
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2592>
There is some surface tracking going on here, and all notify handlers
are possibly leaving the linked wl_listener behind. Ensure it is unlinked
in all destroy notification functions.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2588>
Since commit 1bf70334 "tests/runner: Make test runner use the headless
backend", tests are run with the native backend in headless mode, which
will attempt to open each GPU and show a warning (fatal during tests)
if it cannot.
However, in headless mode we might not be logged in on any seat (for
example we might be logged in via ssh instead), which means we might
legitimately not have permission to use any GPUs, even if they exist.
Downgrade the warning to a debug message in this case.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2381
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2584>
The catch option makes test run via 'catch'[1], which will log
backtraces whenever an abort or segmentation fault happens in any of the
subprocesses. The aim is to enable this when running in CI to help
debugging crashes that only tend to happen in CI.
While it's possible to wrap the whole meson command in 'catch', doing so
doesn't cover the KVM tests, so this option is added instead that covers
both cases.
[1] https://gitlab.gnome.org/jadahl/catch/
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2561>
Until recently, mutter-test-runner called into libraries that
indirectly depend on (mutter's fork of) Clutter, but did not actually
call into Clutter itself. Commit 1bf70334 "tests/runner: Make test
runner use the headless backend" gave it a direct call into Clutter,
which means the runtime linker will fail unless the executable's
RUNPATH is sufficient to find Clutter.
For future-proofing, do the same for the other test executables.
Resolves: https://gitlab.gnome.org/GNOME/mutter/-/issues/2389
Signed-off-by: Simon McVittie <smcv@debian.org>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2581>
This adds the 4 new connector types that mutter didn't know about from
drm_mode.h in the kernel.
Noticed because mutter kept crashing when plugging in a USB-C adapter to
use an external monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2577>
When we e.g. generate switch configs (i.e. the ones from pressing the
Super+P or the switch-config key on laptops), try a bit harder to find a
"good" monitor scale.
With "good", it means pick a scale that was used in a previous
configuration. In practice, this means that if you for example have
configured your external monitor to use a specific scale, then pressed
e.g. "built in only", and then switched back to e.g. "external only" or
"linear", the generated configuration will use the scale that was
previously configured.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
If two modes are roughly the same, they should probably use the same UI
scaling factor. I.e. for the same monitor, if a 4K mode was configured to
have a certain scaling factor, and we generate a new configuration with
a similar sized 4K mode, we should re-use the scale previously
configured; however if we e.g. go from a 4K mode to a FHD mode, we
shouldn't.
This allows implementing better hueristics when using the switch-config
feature, where we'd be less likely to loose the for a certain monitor
mode combination previously configured scaling factor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This will eventually help with better hueristics for finding a good
scale. It currently doesn't change much, but the helper will later gain
more functionality that will also help when coming up with mirroring
configs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
The resulting logical monitor was eventually marked as primary anyway,
but without the config being marked as such, various primary properties
was not set e.g. the one on the MetaOutput. Also, tests would fail.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2479>
This condition is inverted of how it should be. Since pad focus relies
on grouped devices lookups (e.g. pads not grouped with a tablet do not
focus surfaces), this fixes issues in pad focus and event propagation to
wayland clients.
Fixes: fff3654941 - wayland: Check input device capabilities in tablet seats
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2573>
This checks that an unmapped but created Wayland window correctly handle
monitor changes. This is specifically added to test an edge case causing
a crash with the following backtrace:
```
...
4) 0x00007ffff78a2a6b in g_assertion_message_expr ()
5) 0x00007ffff7defd5b in meta_window_update_for_monitors_changed () at ../src/core/window.c:3745
6) 0x00007ffff7899758 in g_slist_foreach () at ../glib/gslist.c:885
7) 0x00007ffff7dbe562 in meta_display_foreach_window () at ../src/core/display.c:3185
8) 0x00007ffff7dbe5fd in on_monitors_changed_internal () at ../src/core/display.c:3210
9) 0x00007ffff796f4ff in g_closure_invoke () at ../gobject/gclosure.c:830
10) 0x00007ffff7981316 in signal_emit_unlocked_R () at ../gobject/gsignal.c:3740
11) 0x00007ffff7987699 in g_signal_emit_valist () at ../gobject/gsignal.c:3495
12) 0x00007ffff7987bc2 in g_signal_emit () at ../gobject/gsignal.c:3551
13) 0x00007ffff7d89915 in meta_monitor_manager_notify_monitors_changed () at ../src/backends/meta-monitor-manager.c:3517
...
```
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
If the window didn't have a size, it would still have a monitor, and
when we are asked to update, we must update, as the old monitor might
not be kept around, leaving us vulnerable to use after free.
Avoid not updating the monitor by using the stored IDs (preferred, or
previous) to find suitable logical monitors, with the primary monitor
being the last fallback unless we're completely headless.
This fixes the assert
!window->monitor ||
g_list_find (meta_monitor_manager_get_logical_monitors (monitor_manager),
window->monitor)
in meta_window_update_for_monitors_changed() being hit when a Wayland
window has been created, but not mapped, when a hotplug happens.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
The function finds a suitable logical monitor given the window
rectangle; this wasn't all that clear from the name
"calculate_main_logical_monitor".
This is in preparation for finding a new logical monitor using things
other than the geometry of the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This will allow tests to change monitor resolution. The first argument
is the monitor ID; there is always one monitor added by default, and it
has the id 0. It's currently not possible to add more monitors, so
passing '0' is the only valid way to resize monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
This hasn't worked for a while, since the test always runs the nested
backend, meaning it's a Wayland compositor. To unblock testing window
management in combination to monitor changes, lets remove the
unreachable X11 WM paths, so that we can start using virtual monitors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2554>
util-private.h includes glib-i18n-lib.h, which requires GETTEXT_PACKAGE
to be defined. The define comes from config.h,
but that cannot be included in headers, so we have to make sure
that any source file that pulls in util-private.h (or a header
that includes it) includes config.h first.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2566>
mutter needs GDK to use the x11 backend. It already calls
gdk_set_allowed_backends ("x11") for this purpose; however, if
GDK_BACKEND=wayland (or any other non-x11 backend possibly) happened to
be in the environment, GDK would fail to initialize at all. This would
result in mutter not registering as X11 window manager, and all X11
clients hanging.
Big thanks to Olivier Fourdan for figuring this out!
v2:
* Restore original value of GDK_BACKEND environment variable after
initializing GDK.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2022283
Bug: https://bugs.debian.org/1008992
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2496>
It consists of only a macro and build description logic.
Adds a macro for simpler tests that doesn't require a context; unit
tests requiring a context should use the same framework as conform
tests.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
All working tests have already migrated to the test suite using mutter;
move the old unported tests over too, and remove the conform test
framework, as it is no longer used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
This is in preparation of moving Cogl tests into src/tests, so they can
use the real backend, instead of the franken-backend it some how still
manages to use some how.
This makes them no longer installed. Most mutter tests are yet to be
installed, so leave that for later, since bigger changes are needed for
that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2555>
Now that we support Wayland buffer transforms in all cases, we can
properly report them to outputs.
Also make sure we resend the output geomerty on transform changes.
This partly reverts commit bda9c359
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
This allows the GL fallback path to correctly paint the cursor
if clients pre-rotated the buffer using
`wl_surface::set_buffer_transform`, visually matching the
hardware cursor path.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/344>
They can be quite heavy, as they load up one virtual machine each. If
your system is already busy, this can easily cause them to time out
instead of finish in time, as they all fight over the same limited
amount of CPU and I/O time.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2556>
Failing in `wait_for_effects_completed()` or `wait_for_view_verified()
indicates client- or compositor-bugs. As hitting those is quite likely
during test development, print error messages to simplify debugging.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
The "single pixel buffer" Wayland protocol extension provides a way for
clients to create 1x1 buffers with a single color, specified by
providing the color channels (red, green and blue) as well as the
alpha channel as a 32 bit unsigned integer.
For now, this is turned into a 1x1 texture. Future potential
improvements is to hook things up to the scanout candidate logic and
turn it into a scanout capable DMA buffer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2246>
When taking the scanout path we still want to clear the
redraw-clip from the stage-view in order to ensure we skip
frames in `handle_frame_clock_frame()` if no new redraw-clip
was recorded.
This was not done previously as the accumulated redraw-clip was
needed for the next repaint, likely under the assumption that
scheduling a scanout repeatedly would be computationally cost-free.
This assumption does not hold in a VRR world.
In order to archive both, an accumulated redraw-clip for the next
paint and frame-skipping during scanout, introduce new API to defer
and accumulate redraw-clips until the next repaint.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2480>
To Wayland clients, it doesn't matter how we configure our onscreen
buffers, since they don't necessarily have the same bandwidth issues
related to mode setting, whichis the primary reason why we disable
modifiers using the udev rule, so simply check whether importing with
modifiers will work at all and advertise modifiers if so is the case.
This might help avoid issues using legacy non-modifiers path in drivers.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
We disable modifiers for two reasons: an udev rule saying so, or the
lack of a working drmModeAddFB2(). However, to the users, this is not
granular enough. While the current user, whether to enable modifiers in
MetaRendererNative, doesn't need more granularity, we want to send
modifiers to Wayland clients even if the onscreen framebuffers should
still be allocated without modifiers.
Prepare for differentiating between how Wayland DMA buffers work and how
onscreen buffer allocation work by separating the relevant device flags.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2546>
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>
