Exposed via new configuration option this enables 3 and 4 finger
dragging on touchpads. When enabled a 3/4 finger swipe
gesture is actually a button down + motion + button up sequence.
If tapping is disabled the drag starts immediately, if tapping is
enabled the drag starts after the tap timeout/motion so we can distinguish
between a tap and a drag.
When fingers are released:
- if two fingers remain -> keep dragging
- if one finger remains -> release drag, switch to pointer motion
When 3/4 fingers are set down immediately after releasing all fingers
the drag continues, similar to the tap drag lock feature. This drag lock
is not currently configurable.
This matches the macos behavior for the same feature.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
Slightly less efficient but easier to read and it's not possible to
accidentally provide the wrong length. Plus it handles null pointers
correctly so get to skip the checks (which weren't needed for strneq()
either, but still).
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1121>
This makes it easier to quickly gather how far a touch has moved since
it started, compared to the initial starting position. This again makes
it easier to determine if a threshold required for e.g. scrolling has
been met.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1101>
If libinput replay is currently replaying events, stop that sequence and
go back to the start if the user presses Ctrl+C. Only on the second
Ctrl+C do we fully exit.
This helps debugging long recordings where we don't want to keep
producing events after some initial event sequence.
Closes#1064
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1102>
This adds the configuration option to define a rectangle that serves as
an input area on external tablets such as an Intuos.
The intention behind this is to make this input area behave as if it was
the only physical input area on this tablet with libinput emulating
proximity events as required for where the tools moves in and out
of this area.
This could also be achieved with the existing calibration setting but
area configuration is not calibration and we don't want to expose other
side-effects of the matrix (e.g. scaling and rotation) for these
devices.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1013>
If --compress-motion-events is given (and stdout is a tty) reduce
the output printed to one line per repeated motion/axis/scroll sequence
(with a count). Example output:
event6 POINTER_MOTION 108 +1.912s 1.00/ -1.00 ( +1.00/ -1.00))
event6 POINTER_BUTTON +2.008s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_BUTTON +2.074s BTN_LEFT (272) released, seat count: 0
event6 POINTER_MOTION 39 +5.249s 0.00/ 0.99 ( +0.00/ +1.00)
event6 POINTER_BUTTON +5.385s BTN_LEFT (272) pressed, seat count: 1
event6 POINTER_MOTION 66 +6.031s -1.00/ 0.00 ( -1.00/ +0.00)
event6 POINTER_BUTTON +6.401s BTN_LEFT (272) released, seat count: 0
The event count (108, 39 and 66) is only printed for more than one event
in sequence so the output is otherwise identical (but 4 spaces wider
now)
If stdout is not a tty the event count is printed but no compression
happens since we rely on a ansi escape sequence for that. Could be fixed
by changing the current print statements to print a \n before the
current event instead of at the end of the current line.
This makes debugging events easier as button events and similar are no
longer obscured by pages of motion events in between.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1041>
We were drawing an arc but apparently in white which made it a tad hard
to see on a white background. Draw this with the same color as the
touchpoints so we can debug single-touch and tablet devices too.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1011>
So we know which kernel driver is handling the device. Quite useful,
sometimes, without having to ask for extra logs.
This of course requires that we ignore said property in libinput replay
since no uinput device will have that driver property set.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1007>
Some tablets such as those in the XP-PEN PRO series use "dials" which
are actually scrollwheels and emit EV_REL events. These should not be
emulated as rings (which are absolute) so we must expose them as a new
tablet event.
Adds LIBINPUT_EVENT_TABLET_PAD_DIAL that work largely identical as our
high-resolution wheel events (i.e. the values are in multiples or
fractions of of 120). Currently supports two dials.
This is a lot of copy/paste from the ring axes because the interface is
virtually identical. The main difference is that dials give us a v120
value in the same manner as our scroll axes.
Notes:
- REL_DIAL is mutually exclusive with REL_WHEEL, we assume the kernel
doesn't (at this point) give us devices with both. If this changes for
devices with three dials (wheel + hwheel + dial) we need to add code
for that.
- REL_DIAL does not have a high-resolution axis and we assume that any
device with REL_WHEEL_HI_RES will also have REL_HWHEEL_HI_RES (if the
second wheel exists).
- With dials being REL_DIAL or REL_WHEEL there is no possibility of
detecting a finger release (the kernel does not route EV_RELs with a
value of zero). Unless this is implemented via a side-channel - and it
doesn't look like any hardware that supports dials does that - we
cannot forward any information here. So unlike absolute rings we
cannot provide a source information here.
Closes#600
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
A follow up on commit 65eaabf91f ("tools/record: print the vid/pid
with proper 4 hex digits").
Print the bus name in addition to the bus ID. Only the busses available
in quirks are printed.
Example:
$ sudo libinput record
[...]
# ID: bus 0x0003 (usb) vendor 0x046d product 0x406d version 0x0111
[...]
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
The range is (max - min + 1) because the kernel range is inclusive min
and max. Let's fix that once and for all with a helper function.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The field with includes the 0x if printing with "0x04d". And because
that format prints zero as just 0000, let's move the 0x prefix out and
let printf only handle the actual number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
