Some tablets have a noticable pointer jump on tip down/up, causing unintended
lines during drawing. Likewise, a button event may have an axis update that we
currently ignore. libinput provides tablet axis events only if no other state
changes, the client must instead get the current axis data from the tip/button
event. So let's do this, process the event axis data during tip/button as
well.
A libinput recording to reproduce is the 'dots.yml' in
https://gitlab.freedesktop.org/libinput/libinput/issues/128Fixes#289
Sending button events to a ClutterVirtualInputDevice, the API expects
button codes to be of the internal clutter type. The evdev
implementation incorrectly assumed it was already prepared evdev event
codes, which was not the case. Fix the evdev implementation to translate
from the internal representation to evdev before passing it along to
ClutterSeatEvdev.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/190
The function is intentionally provided as macro to not require a
cast. Recently the macro was improved to check that the passed in
pointer matches the free function, so the cast to GDestroyNotify
is now even harmful.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/176
Treat the main seat as other seats, so we don't have to handle it differently
in specific places. This was already the case before when a real device
was plugged before the startup, but not applied when hotplugging a device.
When no input devices are available on startup the device manager might be fast
enough to be constructed so that no default stage is set yet, and thus when
main seat virtual devices are created they won't have a proper stage set.
If then we plug a real device, the events that an input manager could generate
won't be associated to any stage and thus won't be processed.
We need then ensure that when we update the stage for the device manager we
(un)associate it also to the main seat devices.
In devices such as ARM boards there could be no input devices connected on
startup, leading to a crash when we try to process artificial events that
could be queued (as gnome-shell does when syncing pointer).
Those events still should refer to a device and, in case we don't have one
provided by libinput we should still return the core devices defined in the
main seat.
Mark CAPS lock as a modifier (as it should) so that when using XKB
options to change the default behaviour of CAPS lock, the new assigned
key can by used as a sticky key as well.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/112
Input method can inject key events, which leads to multiple reported key
press/release events for a single user action.
Ignore those events as this confuses keyboard accessibility.
IF two touch devices have colliding touch point IDs they'd interfere on
the seat. To avoid this, always allocate a seat wide slot for each
device wide slot, but don't use device slots directly in the seat.
BTN_STYLUS3 is defined by the Linux 4.15 kernel and is sent when the
third button on a stylus is pressed. At the moment, only Wacom's "Pro
Pen 3D" has three stylus buttons. Pressing this button triggers a button
8 event to be sent under X11, so we use the same mapping here.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
Libinput shall report those as having slot=-1, which gets mistakenly
translated into the special "NULL" ClutterEventSequence. Making those
events get a non-NULL sequence will make single touch devices work.
https://bugzilla.gnome.org/show_bug.cgi?id=792005
We might receive touch events for unknown touch points, for example
when starting mutter while touching the screen (resulting in no
touch-down event ever being received). Avoid crashing when this happens
by just dropping these events on the floor.
https://bugzilla.gnome.org/show_bug.cgi?id=791371
On VT switch, the xkb state layout index is lost and reset to the first
group, so if the first layout is not the last one being used, the xkb
state used in both meta-wayland-keyboard.c and clutter/evdev will be
desynchronized with the keyboard source indicator in the gnome-shell UI.
Save the effective layout chosen along with the seat so it can be
restored when reclaiming devices.
Use the saved layout index from the clutter/evdev's seat to restore the
layout in meta-wayland-keyboard, so that switching VT doesn't reset the
layout and causes further discrepancies with the layout indicator in the
gnome-shell UI.
https://bugzilla.gnome.org/show_bug.cgi?id=791383
If CLUTTER_CURRENT_TIME is passed, let the backend find an appropriate
time stamp representing the current time in the clock that is used by
that backend.
https://bugzilla.gnome.org/show_bug.cgi?id=784199
Adds basic support for the "wheel" event from the Wayland tablet protocol.
Ideally we would accumulate the angle and report a wheel event with an
appropriate value for "clicks". We can get away with a much cruder method
for the time being, however, since no Wacom tablet puck actually provides
a smooth scrollwheel. Checking whether the angle in CLUTTER_INPUT_AXIS_WHEEL
exceeds a nominally-small threshold is sufficient to determine that the
wheel has advanced by at least one physical click.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
When != 0, this property will express the W:H ratio of the desired
output area (be it one monitor or the span of all monitors). At
the time of translating coordinates, coordinates will be skewed so
that the input area of the tablet is a rectangle of the given ratio.
Events happening in the input areas that fall outside the output
aspect ratio will be clamped to the nearest coordinate in the rect.
If the ratio is 0, the whole input area of the tablet will be used
and no coordinate skewing will happen.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
And transform absolute events using this matrix. This property is
akin to the "Coordinate Transformation Matrix" property in X11,
and will be used to map tablets/touchscreens to outputs, favoured
over the libinput matrix which is meant for calibration.
https://bugzilla.gnome.org/show_bug.cgi?id=774115
Clutter assumed seat0 which is most usually, but not always correct.
Add an evdev-backend specific function to allow passing the seat
that will be used for ClutterDeviceManager construction, which we
already obtain in MetaLauncher.
https://bugzilla.gnome.org/show_bug.cgi?id=778092
Since both the libinput event source and the key repeat timer have the
same priority, the order in which both handlers are called is
arbitrary if both sources are ready on the same poll return. This
means that sometimes we generate key repeats when there's already a
real key event queued on libinput that would cancel the repeat timer
if only it was processed before.
One solution would be lowering the repeat timer source priority a
notch lower than the libinput source but that would mean that a steady
stream of events from libinput (e.g. pointer device motion) would
prevent any key repeats to happen.
Instead, we can fix this problem by trying to dispatch libinput from
the key repeat timer and checking if the timer source has been
destroyed before generating more key repeats.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
Commit 9214d5029c630e6ed8fd9793f6bcb0a0ae451576 changed the notify*
API to use microseconds and we already have a microsecond time source
here so we can use the timestamp directly without losing resolution at
this layer.
https://bugzilla.gnome.org/show_bug.cgi?id=774989
Stylus configuration (stylus buttons, pressure) was handled
at the very high level, doing the button and pressure translations
right before sending these to wayland clients.
However, it makes more sense to store these settings into the
ClutterInputDeviceTool itself, and have clutter apply the config
at the lower level so 1) the settings actually apply desktop-wide,
not just in clients and 2) X11 and wayland may share similar
configuration paths. The settings are now just applied whenever
the tool enters proximity, in reaction to
ClutterDeviceManager::tool-changed.
This commit moves all handling of these two settings to
the clutter level, and removes the wayland-specific paths
https://bugzilla.gnome.org/show_bug.cgi?id=773779
We do so whenever a tool enters or leaves proximity. We now also
ensure that last_tool is NULL after it leaves proximity, although
the CLUTTER_PROXIMITY_OUT event itself should still contain tool
information.
https://bugzilla.gnome.org/show_bug.cgi?id=773779
