We have 2 sources (this one in MetaSeatNative, and the one in
MetaBackend) dispatching ClutterEvents to the stage. Make the
MetaSeatNative one exclusively about dispatching the libinput
queue, and leave ClutterEvents to the other.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
This will resort to SW rendering if this cursor renderer does not
own the MetaKmsCursorRenderer, so it's pretty much equivalent thus
far, except we may now implement logic to flip the kms cursor renderer
around.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
We actually have a set_send_events() vfunc that can enable or disable
devices at the libinput and X11 input driver level, so use that. A
positive side effect is that those layers will leave the device at
a consistent idle state (as opposed to going mute maybe amid user
input).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Move the KMS updating pieces to a distinct MetaKmsCursorRenderer whose
cursor sprite will get updated from the driving MetaCursorRenderer.
Since there could be multiple MetaCursorRenderers, also add the
necessary pieces to move the KMS cursor renderer between renderers.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
We are aiming for a split of HW and SW cursor rendering management.
Given the HW plane is a limited resource and the amount of cursor
renderers may be >1 (due to tablets, even though we currently use an
always-software cursor renderer there), it would ideally be able to
switch between renderers.
Being MetaCursorRenderer not really a singleton, having cursor
inhibitor accounting here doesn't pan out. Make it MetaBackend API
so all cursor renderers get the same picture.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
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.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Instead of letting the wayland bits maintain an always-software
cursor renderer, let the cursor renderer be managed by the backend,
and only hook to it (as we do for pointer cursor) in the wayland
bits.
ATM, make the cursor renderer still always-software, although
ideally we should allow moving the HW cursor management between
renderers.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Different devices may get standalone cursor renderers, add this API
to adapt slowly to this. The meta_backend_get_cursor_renderer() call
still exists, but shortcuts to the mouse pointer's renderer (as it
actually did before).
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
This is already taken care of in meta_backend_monitors_changed(), called
from the same code paths that emit ::monitors-changed-internal. It is
better to leave this up to backend internals.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Rely on the seat stage, or other ways to fetch it. Also rely that
there is actually a single stage, so that we assign the right stage
to all events going out of the seat, in a single place.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
This is a bit scattered around, with the setter/getter in Clutter, and
it only being only directly honored in Wayland (it goes straight through
device properties in X11).
Make this private native API, and out of public ClutterInputDevice API.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
Make the upper part agnostic about the device being relative in order
to avoid applying keep-aspect. The X11 bits already are, so make it
sure it's also the case for the native backend.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403
