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>
What the keymap eventually is after, are things handled by the actual
backend (MetaBackendX11), so let it keep a pointer to that. This
eliminates some usages of globals.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2014>
XIQueryPointer allocates the button state mask that we were leaking in
some places. We need to manually free this, because there is no XI
function that would do this for us.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1728>
This commit adds the events created in the function
`meta_seat_x11_notify_devices` to the clutter events queue, which
are currently only added to the stage queue making the events not
being picked up by the `clutter_seat_handle_event_post` function.
This results in devices not getting added to the device-list of
`MetaInputSettings`.
Fixes the bug in which mouse and touchpad settings are not working in
the settings app during x11 session.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1767>
Given X11 nature, the pointer "leaves" the stage anytime it wanders into
a client window, or any other areas that are not deemed part of the
stage input region.
Yet we want to stay correct in those situations, e.g. have the clutter
side reasonably in sync, picking and highlighting to work properly, etc.
In order to achieve that, emulate motion events on XI_RawMotion. These
are as much throttled as our pointer tracking for a11y, in order to avoid
too many XIQueryPointer sync calls. This emulation only kicks in anytime
that X11 notifies us that we are not "on" the stage.
This replaces some sync_pointer() calls in GNOME Shell code that are
there just to compensate for this trait of X11, e.g. in the message tray
code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1659>
We had code in both backends that sort of independently associated
sequences to slots. Make both transform slots to sequences the same
way, so they may share the implementation convert those back to slots.
This helper now lives in Clutter API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
All that is left in the "public" struct is all state that ClutterStage
delegates on ClutterInputDevice. That should move somewhere else, but
not here, not now.
All private fields belong to construct-only properties, with only getter
API, and idempotent vmethods (except keyboard a11y, atm). This should
be enough to make ClutterInputDevice obviously thread safe, outside the
backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Depending on the backend, we want to integrate this object at different
levels. It will sit close to the MetaBackendX11/MetaSeatX11 in X11, but
it will be put deep down with MetaSeatImpl in the native backend, in a
separate thread.
Since we can't depend on a single object type, nor are able to track
ClutterSeat signals neatly, make this API something to be called
explicitly by backends.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Like it's done for the pointer in other places. Without a stage assigned,
some bits (like IM handling) may end up with events ignored, and misbehave.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1413
Just because X11/XI uses a particular terminology doesn't mean we
have to use the same terms in our own API. The replacement terms
are in line with gtk@1c856a208, which seems a better precedent
for consistency.
Follow-up to commit 17417a82a5.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1425
When a device is removed from the seat the events that this device may have
emitted just before being removed might still be in the stage events queue,
this may lead a to a crash because:
Once the device is removed, we dispose it and the staling event is
kept in queue and sent for processing at next loop.
During event processing we ask the backend to update the last device
with the disposed device
The device is disposed once the events referencing it, are free'd
The actual last device emission happens in an idle, but at this point
the device may have been free'd, and in any case will be still disposed
and so not providing useful informations.
To avoid this, once a device has been added/removed from the seat, we queue
ClutterDeviceEvent events to inform the stack that the device state has
changed, preserving the order with the other actual generated device events.
In this way it can't happen that we emit another event before that the
device has been added or after that it has been removed.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1345
Add a method to ClutterSeat that allows peeking the list of input
devices and allow looping through devices a bit faster. The API left is
private so we can make use of peeking the GList internally, but don't
have to expose any details to the outside, which means we'd have to
eventually stick with a GList forever to avoid breaking API.
Since we now have the peek_devices() API internally, we can implement
ClutterSeats public list_devices() API using g_list_copy() on the list
returned by peek_devices().
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
