For the coordinates of pointers or stylii, we translate the ones we store
using the viewport matrix already. For touch events otoh, we store coords
untranslated and translate them later only for event emission.
Let's be consistent here and store the coordinates of touch events
translated, just like we do for pointer events.
This fixes touch window dragging on rotated monitors. MetaWindowDrag calls
clutter_seat_query_state(), which uses those stored coordinates. So in case
of a touch sequence the coords returned by query_state() would be
untranslated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2859>
When the pointer crosses monitors, we account for a single motion event
resulting in the pointer moving across more than 2 monitors, in order
to correctly account each monitor scale and the distance traversed
across each monitor in the resulting relative motion vector.
However, memory on the direction is kept short, each iteration to
find the target view just remembers the direction it came from. This
brings a pathological case with 4 monitors with the same resolution
in a 2x2 grid, and a motion vector that crosses monitors at the
intersection of all 4 in a perfect diagonal. (Say, monitors are
all 1920x1080 and pointer moves from 1920,1080 to 1919,1079).
In that case, the intersection point at the crossing between 4
monitors (say, 1920,1080) will be considered to intersect with 2
edges of each view. Since there is always at least 2 directions to
try, the loop will always find the direction other than the one
it came from, and as a result endlessly jump across all 4 possible
choices.
In order to fix this, consider only the global v/h directions,
we already know if the pointer moves left/right or up/down, so
only consider those directions to jump across monitors.
For the case at hand, this will result in three monitors visited,
(either bottomright/bottomleft/topleft, or bottomright/topright/topleft)
with a total distance of 0,0 in the middle one, effectively
resulting in a correct diagonal motion.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2598
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
Refactor code so that variables don't depend the on motion line
content, but the other way around. This makes it clearer what each
vector means.
This has no functional changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2803>
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>
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>
It is generally assumed here and there that the pointer at all point in
time is within some logical monitor, if there is any logical monitor to
be within.
With the input thread, this was for a short amount of time not reliable,
resulting in crashes in combination with hotplugging or suspend/resume,
where monitors come and go quickly.
What happens is that the pointer at first is within a logical monitor,
but when that logical monitor is removed, while the new monitor
viewports are handed to the input thread, the constraining happens
asynchronously, meaning there is a time between between the new
viewports are sent, and before clutter_seat_query_state() starts
reporting the constrained position.
If a new client mapped a maximized window during this short time frame,
we'd crash with
#0 meta_window_place at ../src/core/place.c:883
#1 place_window_if_needed at ../src/core/constraints.c:562
#2 meta_window_constrain at ../src/core/constraints.c:310
#3 meta_window_move_resize_internal at ../src/core/window.c:3869
#4 meta_window_force_placement at ../src/core/window.c:2120
#5 xdg_toplevel_set_maximized at ../src/wayland/meta-wayland-xdg-shell.c:429
#6 ffi_call_unix64 at ../src/x86/unix64.S:105
#7 ffi_call_int at ../src/x86/ffi64.c:672
#8 wl_closure_invoke at ../src/connection.c:1025
#9 wl_client_connection_data at ../src/wayland-server.c:437
The fix for this is to make sure that the viewports are updated and
pointers constrained synchronously, i.e. the main thread will wait until
after the input thread is done constraining before continuing.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2147502
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2711>
Some mice send a value slightly lower than 120 for some detents. The
current approach waits until a value of 120 is reached before sending a
low-resolution scroll event.
For example, the MX Master 3 sends a value of 112 in some detents:
detent detent
| | |
^ ^ ^
112 REL_WHEEL 224
As illustrated, only one event was sent but two were expected. However,
sending the low-resolution scroll event in the middle plus the existing
heuristics to reset the accumulator solve this issue:
detent detent
| | |
^ ^ ^ ^
REL_WHEEL 112 REL_WHEEL 224
Send low-resolution scroll events in the middle of the detent to solve
this problem.
Fix https://gitlab.gnome.org/GNOME/mutter/-/issues/2469
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2668>
Change meta_seat_impl_notify_discrete_scroll_in_impl to receive 120
based values and report high-resolution scroll values as smooth scroll.
Notify discrete scroll only when the accumulated value reach 120.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
In order to get the delta X/Y value of the
LIBINPUT_EVENT_POINTER_SCROLL_FINGER
or LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS events the new function
libinput_event_pointer_get_scroll_value should be used instead of
libinput_event_pointer_get_axis_value.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
Ignore deprecated LIBINPUT_EVENT_POINTER_AXIS events and handle
LIBINPUT_EVENT_POINTER_SCROLL_WHEEL,
LIBINPUT_EVENT_POINTER_SCROLL_FINGER and
LIBINPUT_EVENT_POINTER_SCROLL_CONTINUOUS instead.
The scroll source is now encoded in the event type making
libinput_event_pointer_get_axis_source and translate_scroll_source
redundant.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1962>
We do not need to open code the ClutterInputDeviceType fetching from a
libinput_device, since we already created a native ClutterInputDevice that
has the right type.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2331>
This GSource is not being properly unref nor the variable holding it
cleared. This on one hand leaks the GSource memory, on the other hand
may trigger warnings in keyboard_repeat() as the source may be
(reentrantly) cleared, yet we don't exit early as
seat_impl->repeat_source is never NULL.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1839>
The input thread is in deep water doing the meta_is_*() check itself,
as that pokes the MetaMonitorManager managed by the main thread. Use
the getter from the MetaViewportInfo instead.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1793>
Add a flag to MetaSeatNative and MetaSeatImpl that tells it not to
attempt to create a libinput context. This is intended to be used when
mutter is to run headless, as in without any input devices other than
virtual ones.
Currently not hooked up.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1698>
With commit 7d7876880998fe7b414bb38f8094af9822020d1b we switched to
storing pointer coordinates in MetaInputDeviceNative instead of
ClutterInputDevice, and while we had set the coordinates of the
ClutterInputDevice in ClutterStage when queueing an event, we now set
the MetaInputDeviceNative coordinates in new_absolute_motion_event().
Here a small mistake snuck in: new_absolute_motion_event() only
translates the coordinates of the event, but we call
meta_input_device_native_set_coords() using the x and y variables
(which remain untranslated), so now the input device coordinates are no
longer translated.
Fix that by translating the coordinates of the x and y variables in case
we're we handling a tablet/stylus event instead of only translating the
event coordinates.
Fixes https://gitlab.gnome.org/GNOME/mutter/-/issues/1685
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1760>
This removes the responsibility of tracking these from the backend to
the base object. The backends are instead responsible for calling the
function to update the values.
For the native backend, it's important that this happens on the correct
thread, so each time either of these states may change, post a idle
callback on the main thread that sets the, at the time of queuing said
callback, up to date state. This means that things on the main thread
will always be able to get a "new enough but not too new" state when
listening on the 'notify::' signals and getting the property value
after.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1739>
Libinput will queue a few initial events when a seat is assigned to the
udev backend; a result of it probing udev adding detected devices. For
us to see these events, we need to dispatch libinput before going idle,
as nothing will show up on the libinput file descriptor until something
else (e.g. keyboard event or mouse movement) wakes us up.
Do this by adding a prepare() function to the libinput GSource, that
checks whether there are any events in the queue already, and return
TRUE if so is the case, causing us to dispatch before going fully idle.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1688>
When a remote desktop user emits a virtual smooth scrolling event, a
smooth scroll event, that is not emulated, is emitted and on occasion
a discrete scroll event, that is emulated, is emitted.
As base for the discrete scrolling event, the smooth scrolling steps
are accumulated.
When the accumulated smooth scrolling steps surpass the
DISCRETE_SCROLL_STEP, the discrete scrolling event is emitted.
Currently, mutter uses for DISCRETE_SCROLL_STEP the value 10, which is
a terrible value to work with, especially for high resolution mouse
wheels.
When a triple resolution mouse wheel is used, each scrolling step will
have the value 3 1/3.
Three of such events won't however surpass the DISCRETE_SCROLL_STEP.
To fix this situation, add DBL_EPSILON to the calculation step, when
checking for the discrete scroll event to ensure that 3 smooth scroll
events, with each having the value 3 1/3, emit a discrete scrolling
event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1727>
The original implementation of ::touch-mode tested for keyboard
presence to know whether the OSK and other touch-only features were
enabled.
However that didn't pan out, every webcam, card reader and kitchen
sink like to live a second life as EV_KEY devices. This made the
detection of actual external keyboards a much harder task than it
sounds, and was thus removed in commit f8e2234ce59fbb.
Try a different approach here, and test for pointer devices, it
doesn't matter if internal or external devices, the rationales:
- It is significantly easier to get this right, there's virtually
no devices with abs/rel axes that don't try to be a real input
device of some sorts.
- It's not as good as testing for keyboard presence, but it's the
next best thing. These usually come in pairs, except in weird
setups.
- It is better than not having anything for a number of situations:
- Non-convertible laptops with a touchscreen will get touch-mode
disabled due to touchpad presence (plus keyboard). There's
been complains about OSK triggering with those.
- Same for desktop machines with USB touchscreens, the mouse
(and presumably keyboard) attached would make touch-mode
get in the middle.
- Convertible laptops with a broken tablet-mode switch get a
chance to work on tablet modes that do disable input devices
(e.g. detachable keyboards, or via firmware)
- Kiosk machines, tablets, and other devices that have a
touchscreen but will not regularly have a mouse/keyboard
will get the touch-mode enabled.
All in all, this seems to cover more situations the way we expect it,
there's only one situation that the OSK would show where it might
not be desirable, and one that might not show when it better should:
- Tablets and kiosk machines that get one keyboard plugged, but not a
mouse, will still show the OSK, despite being able to type right
away.
- Convertible laptops with broken/unreliable tablet-mode switch (e.g.
ignored by the kernel) rely entirely on the device/firmware
characteristics to work. If after folding into tablet mode the
touchpad remains active, touch-mode will not turn on.
Fixing the tablet-mode switch on these devices should be preferred,
as that'll also make libinput magically disable the touchpad.
The latter can be worked around with the a11y toggle. The former is
merely inconvenient, and nothing prevents the user from plugging a mouse
in addition.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1710>
We can't post tasks to the input thread when cleaning up the
MetaSeatImpl, as that will make the GTask complain about adding
references to a to be purged object. Avoid this by adding an explicit
meta_seat_impl_destroy() function that handles the destruction of the
MetaSeatImpl properly.
This also does more of the cleanup in the input thread, as that is where
it was managed. Will likely not make a difference as before this
happened after tearing down the thread, but lets tear down things in the
thread they were managed for good measure.
This fixes the last log spew I see right now when terminating mutter.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1670>
We didn't tear down the libinput objects in the right thread when
exiting, but did so after the input thread exited.
We also tried to destroy the libinput devices after the libinput context
was destroyed, which isn't allowed.
Fix these two issues by tearing down the libinput objects in a input
thread task that when done exits the input thread. This effectively
"flushes" the input thread tasks while destroying the libinput objects
just before the thread exits.
While it might fine to tear down libinput objects in an arbitrary (main
in this case) thread while making sure nothing pokes at it in parallel
(e.g. the input thread is gone), libinput is by definition single
threaded, and could theoretically make assumptions about this, and we
shouldn't cause any possible surprises here, so make sure to destroy it
all in the right thread.
This fixes an abort() on exit caused by an assert about invalid object
destruction in libinput.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
The "seat" usually refers to the ClutterSeat (MetaSeatNative) object,
and "seat_impl" to the MetaSeatImpl object, but there were still a few
places where this wasn't adhered to so fix those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1663>
To clear a pointer constraint, the Wayland backend passes a NULL
constraint to the native input backend.
The new async API however tries to reference/un-reference the given
object to use it while running in a separate task, which leads to a
warning from GLib trying to g_object_ref()/g_object_unref() a non
GObject pointer.
To avoid that issue, simply set the data only if the given constraints
pointer is not NULL.
Suggested-by: Carlos Garnacho <carlosg@gnome.org>
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1587
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1652>
Currently, the MetaInputDeviceNative owns the libinput_device, with the
small catch that it is eventually finished in the main thread (as the
CLUTTER_DEVICE_REMOVED event keeps the last reference to it).
Make it sure that the libinput_device is destroyed in the input thread,
before giving away the last extra input device references.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1639>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
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>
Figuring out the MetaSeatImpl this much indirectly is fairly awkward when
the keymap is only updated from the MetaSeatImpl, pass instead the seat
impl's xkb_state, as we have it handy in all the places this is called.
This will not break on NULL seats during initialization, should the numlock
state be restored from previous sessions.
Fixes: https://gitlab.gnome.org/GNOME/mutter/-/issues/1556
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1612>
Make it impossible to add individual includes of input thread objects.
This must go through meta-input-thread.h now, which should be enough
to make anyone think it twice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
They're a dime a dozen. If it gets called exclusively from the
input thread, it got one. Hopefully these breadcrumbs will be
enough so people don't lose their way here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
This (now) doesn't change anything in regards to the API that the UI
thread should access from the MetaSeatImpl. The MetaInputDeviceNative,
MetaInputSettings and MetaKeymap objects are now considered owned by
the input thread, as well as all of libinput objects.
The MetaEventSource now dispatches events in a GMainContext that is
the thread default to this thread, and all UI-thread-accessible API
(seat and virtual input device API) will be handled in a serialized
manner by that same input thread.
The MetaSeatImpl itself is still considered to be owned by the caller
thread, and all the signals that this object emits will be emitted in
the GMainContext that is default at the time of calling
meta_seat_impl_new().
The MetaInputSettings configuration changes will likewise be handled
in the input thread, close to libinput devices.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
Instead of going through the event queue, stage handling code, and
back to the input device via a vmethod call, do this directly in the
MetaSeatImpl. This is not too different from X11, where everything
happens inside the backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1403>
