GitLab

Prep work for the wobbling detection patch
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

division by 0 and an unused variable
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Similar in style to evemu-play but parses the YAML printed by
libinput-record. Note that this tool requires python-libevdev which is a new
package and may not be packaged by your distribution. Install with pip3 or
alternatively, just ignore libinput-replay, it's a developer tool only anyway.

User-visible differences to evemu-play:
* supports replaying multiple devices at the same time.
* no replaying on a specific device, we can add this if we ever need it
* --verbose prints the event to stdout as we are replaying them. This is
  particularly useful on long recordings - once the bug occurs we can ctrl+c
  and match up the last few lines with the recordings file. This allows us to
  e.g. drop the rest of the file.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This is a tool that does effectively the same job as evemu-record.
evemu has two disadvantages: its API is clunky and hard to extend even for
simple features. And it has a custom file format that requires special
processing but is difficult to extend and hard to write manually. e.g. the
bitmasks require keeping a line number state to know which bit an entry refers
to.

libinput-record records the same data but the output is YAML. That can be
processed easier and extended in the future without breaking the parsing. We
can (in the future) also interleave the evemu output with libinput's debug
output, thus having a single file where the events can be compared and
analysed without the need for replaying.  Likewise, we can easily annotate the
file with parsable bits of information without having to shove all that into a
comment (like version numbers of libinput, kernel, etc).

User-visible differences to evemu-record:
* the output file requires an explicit -o or --output-file argument
* no evemu-describe equivalent, if you just want the description simply cancel
  before any events are sent
* to see key codes, a --show-keycodes flag must be supplied, otherwise all
  'normal' keys end up as KEY_A. This protects against inadvertent information
  leakage
* supports a --multiple option to record multiple devices simultaneously. All
  recordings have the same time offset, it is thus possible to reproduce bugs
  that depend on the interaction of more than one device.

And to answer the question of: why a printf-approach to writing out yaml
instead of a library, it's simply that we want to be able to have real-time
output of the recording.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Because life is too short for this

https://bugs.freedesktop.org/show_bug.cgi?id=105265Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

https://bugs.freedesktop.org/show_bug.cgi?id=105264Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

It's pretty basic as compared to e.g. one of Mesa, but I don't see what
else could be needed, and if anything, it can be added later.
Signed-off-by: Konstantin Kharlamov <Hi-Angel@yandex.ru>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Missing '+' in the optstring caused it to evaluate all options. If any
argument was passed to a subcommand, libinput-measure would throw an error and
exit.

https://bugs.freedesktop.org/show_bug.cgi?id=105246Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Accidentally committed in 2a378beaSigned-off-by: Peter Hutterer <peter.hutterer@who-t.net>

When drawing on a tablet, the hand usually rests on the device, causing touch
events. The kernel arbitrates for us in most cases, so we get a touch up
and no events while the stylus is in proximity. When lifting the hand off in a
natural position, the hand still touches the device when the pen goes out of
proximity. This is 'immediately' followed by the hand lifting off the device.

When kernel pen/touch arbitration is active, the pen proximity out causes a
touch begin for the hand still on the pad. This is followed by a touch up when
the hand lifts which happens to look exactly like a tap-to-click.

Fix this by delaying the 'arbitration is now off' toggle, causing any touch
that starts immediately after proximity out to be detected as palm and
ignored for its lifetime.

https://bugs.freedesktop.org/show_bug.cgi?id=104985Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Currently unused, will be used in later patches
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Previously, on touch toggle (invoked by the tablet when a pen goes in
proximity) the touchpad cleared the state and ignored any events. Since we
ignore touches that we didn't see the touch begin for, this handled the cases
of a touch remaining after proximity out.

This code pre-dates palm detection, so let's take the bluetack off and instead
integrate it with proper palm detectino.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The sd-bus interface we're using wasn't public until 221.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

If a single-touch touchpad drops below the pressure threshold in the same
frame where a fake finger is added, we begin a fake touch here. The subsequent
loop ends this fake touch because real_fingers_down is 0.

This causes the tapping code to have a mismatch of how many fingers are down
because it never sees the touch begin event for that finger.

https://bugs.freedesktop.org/show_bug.cgi?id=105160

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Makes debugging a bit easier when you know *which* touch was marked as palm,
etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Having this initialized and then changed later is more confusing that having
the trinary here in one line

Tweak this python scripts to use '/usr/bin/env python3'
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Found by coverity
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

If libdir is an absolute path (which means it’s outside of prefix) we
would wrongly add the prefix to it in the install script. Just pass the
correct libdir from Meson directly thanks to join_paths() magic.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Since the install script cannot know the correct bindir, just pass it
from Meson directly.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This tablet advertises tilt but doesn't actually have it. Let's rule out tilt
for all aiptek devices until someone complains.

Recording from: https://bugzilla.redhat.com/show_bug.cgi?id=1535755
Related to: https://bugs.freedesktop.org/show_bug.cgi?id=104911Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Some (?) Aiptek tablets have BTN_TOOL_PEN but aren't inclined to actually send
this on proximity in. This means we don't have a tool assigned and ignore the
events.

This patch piggy-backs on the already-existing proximity-out quirks. On the
first EV_SYN and if the tool is still NONE (i.e. no BTN_TOOL_* was received), we
pretend that we've earlier forced a proximity-out event for this tablet. This
causes the proximity-out quirk code to emulate a proximity in and we're off.
Hooray.

https://bugs.freedesktop.org/show_bug.cgi?id=104911Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Mouse and lens cursor tools are rare and the rotation calculation is quirky to
say the least. I don't have access to a non-Wacom mouse tool, so
until this changes, just disable those tools and wait for someone to shout.

This is a much easier fix than trying to figure out the correct generic
rotation calculation that may not be correct anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

If a tablet never sends a BTN_TOOL_foo, we never update the tool and we remain
on the 'none' tool.

Somewhat related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1535755
https://bugs.freedesktop.org/show_bug.cgi?id=104911Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

When the device gets deleted in a non-neutral state, we need to release all
buttons, lift the tip up and send a proximity out event.

https://bugs.freedesktop.org/show_bug.cgi?id=104940Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Let's make sure all libevdev manipluations are done before we start
initializing anything based on the event codes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Aiptek tablets have the BTN_TOOL_MOUSE|LENS bits but don't actually have a
mouse, at least not in libinput (see future patches). Turns out we only have
one device that really has the tool anyway, so not running the tests for the
others seems sensible.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>