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>
