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>
These use now more of a "pull" model, where they receive update
notifications and the relevant input position is queried, instead
of the coordinates being passed along.
This allows to treat cursor renderers all the same independently
of the device they track. This notifying of position changes should
ideally be more backend-y than core-y, a better location will be
figured out in future commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Without doing this, we'd use the same sprite that was last set by
mutter, most likely a leftptr cursor, and fail to update when e.g.
moving the pointer above a text entry and the displayed cursor updated
to a cursor position marker.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
On X11 we won't always receive cursor positions, as some other client
might have grabbed the pointer (e.g. for implementing a popup menu). To
make screen casting show a somewhat correct cursor position, we need to
actively poll the X server about the current cursor position.
We only really want to do this when screen casting or taking a
screenshot, so add an API that forces the cursor tracker to track the
cursor position.
On the native backend this is a no-op as we by default always track the
cursor position anyway.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1391
