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>
