A tablet with multiple mode toggle buttons had each mode toggle button
merely cycle to the next mode in the sequence, removing the whole point
of having multiple toggle buttons.
Fix this by defaulting each mode toggle button to "next". Once we
have initialized all buttons we can check if we have multiple buttons -
if so we number them sequentially so that the first button maps to mode
0, the second maps to mode 1, etc.
Closes#1082
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1132>
This was working on an assumption that there is only one ref of the
tablet tool and if we call unref it will be removed. This assumption is
not something we can guarantee in the public API so we shouldn't test
for it.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1161>
These have been behind #if 0 for ages but there are more to come, let's
make it possible to toggle those on/off with a meson option.
This is an option that must not be used in a release build, it will leak
key codes to the logs.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1156>
Two advantages here: fewer actual printf() calls making the output
slightly more coherent if there are other things writing to stdout but
also better re-usability since we can now move the print functions to
shared code.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1156>
This avoids inconsistencies between the LITEST_ enum value and the
shortname but also makes it easier to grep for any test cases that use
the same define. At the cost of the test names not looking very nice
anymore but oh well.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1157>
It's a bit annoying to only find those during a CI pipeline run, so
let's add a hook for it. Pre-commit doesn't seem to have something
useful for duplicate line detection so let's hack up a quick script
that can do this for us, together with the other whitespace checks in
the CI so we're consistent.
Excluded from the duplicate line checks are anything "Not C" and the
"include/" directory since we don't control those files.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1154>
As I tested my friend's ThinkPad A485, I found that the default multiplier
resulted in jumpy cursor and a slightly too quick acceleration curve. Upon
checking for Lenovo quirks, I found that since commits 383a60abea
("Better Thinkpad T480 trackpoint multiplier") and a1566e3492 ("quirks:
Thinkpad T470 trackpoint multiplier"), the TrackPoint multiplier for both
T470 and T480 (which shares the same keyboard FRUs with the A485) were set
to 0.4.
However, per my testing, by setting the multiplier to 0.4, the TrackPoint
speed became so painfully slow that it began to hurt my index finger...
I suspect the original commiters have set custom acceleration curves on
their own system, but I might be wrong.
Playing with the multiplier, I found 0.75 to be the most appropriate and,
interestingly, with anything >= 0.8, the TrackPoint began to become jumpy,
with the cursor appearing to have a very low poll rate on the screen (the
higher the multiplier, the worse it gets).
Since, as I mentioned above, the keyboard and TrackPoint parts are shared
between these three models, I'm assuming that this multiplier will work
well for them.
Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1149>
Tablets may have different ABS_PRESSURE ranges with the oldest tablets
having 1k pressure range, then 2k, and the newer ones 8k.
If the same tool is used across two tablets with different ABS_PRESSURE
ranges, the first tablet in proximity calculated the range on where to
normalize to. As a result the other tablet either couldn't reach the
full pressure (2k pressure first, then 8k) or the full pressure range
was reached at a fraction of the full range (8k pressure first, then
2k).
Fix this by moving the threshold handling into a separate struct and
hardcoding up to 4 of those per tool. That is 2 more than the more
complicated setups I've heard of (and this only applies to tracking the
same stylus across those tablets anyway).
This duplicates the pressure offset heuristics but that's easier than
figuring out how to handle heuristics across potentially two tablets.
The range configuration is left as-is on the assumption that this one is
per tool, not per tablet.
Closes#1089
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1143>
touchpad_move_after_touch contains support for up to 5 fingers but was only run
with 2..4 fingers.
touchpad_multitap and several others using the same parameter definition were
long ago tested with 3..7 taps. In 8f92b091 this was reduced to 3..4 for CI
performance, while the commit message indicates 3..5 were intended.
The common theme is that the upper bound of `struct range` is interpreted
as exclusive, while some uses assumed it would be inclusive.
There are relatively recent helper functions range_init_inclusive and
range_init_exclusive (since 817dc423) to avoid this trap. Use them on the
remaining two ranged tests.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
The two remaining ranged tests (abs_device_no_range, abs_mt_device_no_range)
are better served staying with ranges because parametrized tests need to
explicitly list all members of the range, which for these tests is not only
pretty big, but also contains abs axes reserved for future use. Those axes
have no names yet, making a future-proof conversion pretty much impossible.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1142>
Similar to the condition just north of here, if we have 3 fingers in a
roughly linear line and 3fg dragging is enabled, assume we're actually
trying to drag. This reduces the minimum movement otherwise required
to detect the type of gesture.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
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>
Where the tapping code calls into the timeout function make sure we have
a separate event for this. This way we know whether the current gesture
event is caused by the hold timeout or something else.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
This shouldn't have any effect in the current setup as there is
"coincidentally" no overlap between the two state machines so this is
effectively a noop.
Nonetheless, if we're about to send a tap button event we cannot be in
any other gesture than tapping so all swipe/pinch/holds need to be
cancelled.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1042>
The 5th finger was placed in the same position as the 4th finger which
doesn't have an effect in libinput but it looks wrong.
And the first finger was put down at 40/30 but then moved from 70/30 to
the new position, causing pointer jumps on some touchpads.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1145>
