GitLab

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

If a touch ends and starts again in the same frame, our touch count gets out
of whack. This later triggers an assertion when the tap touch count mismatches
the real tap count.

E: 0.105005 0003 0039 -001      # EV_ABS / ABS_MT_TRACKING_ID   -1
E: 0.105005 0003 0035 8447      # EV_ABS / ABS_MT_POSITION_X    8447
E: 0.105005 0003 0036 4479      # EV_ABS / ABS_MT_POSITION_Y    4479
E: 0.105005 0001 014a 0000      # EV_KEY / BTN_TOUCH            0
E: 0.105005 0001 0145 0000      # EV_KEY / BTN_TOOL_FINGER      0
E: 0.105005 0003 0039 0074      # EV_ABS / ABS_MT_TRACKING_ID   74
E: 0.105005 0003 0035 8388      # EV_ABS / ABS_MT_POSITION_X    8388
E: 0.105005 0003 0036 4480      # EV_ABS / ABS_MT_POSITION_Y    4480
E: 0.105005 0001 014a 0001      # EV_KEY / BTN_TOUCH            1
E: 0.105005 0001 0145 0001      # EV_KEY / BTN_TOOL_FINGER      1
E: 0.105005 0003 0000 8388      # EV_ABS / ABS_X                8388
E: 0.105005 0003 0001 4480      # EV_ABS / ABS_Y                4480
E: 0.105005 0000 0000 0000      # ------------ SYN_REPORT (0) ---------- +19ms

This is a kernel bug but let's paper over here because otherwise we crash and
that's considered impolite.

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

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

Copy/paste error in the hwdb to quirks transition
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The special bezel buttons are associated to the keyboard and would
therefore mistakenly be deactivated as well. See #154.

If a 2fg scroll motion starts with both fingers in the bottom button area and
one finger moves into the main area before the other, we used to send motion
events for that finger. Once the second finger moved into the main area the
scroll was detected correctly but by then the cursor may have moved out of the
intended focus area.

We have two transitions where we may start sending motion events: when we move
out of the bottom area and when the finger moves by more than 5mm within the
button area. In both cases, check for any touches that are in the
bottom area and started at the 'same' time as our moving touch. Mark those as
'moved' to release them for gestures so we get the right finger count and
axis/gesture events instead of just motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

There's one state with a name longer than allocated but it's virtually never
triggered so let's just ignore the misalignment in that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The shape of the average hand implies that two fingers down within the lower
thumb area (the bottom few mm of the touchpad) cannot be thumbs without
significant contortion. So let's not mark them as thumb.

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

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

We rely on the udev keyboard builtin to set the fuzz but that builtin isn't
run during udevadm test. So running sudo udevadm test shows the LIBINPUT_FUZZ
properties the first time round (still set from boot), but not the second time.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

tp_detect_thumb_while_moving() assumes that of the 2 fingers down, at least
one must be in TOUCH_UPDATE, otherwise we wouldn't have a speed to analyze for
thumb.

If a touch starts in HOVERING and exceeds the speed limit, we were previously
increasing the 'exceeded count'. This later leads to an assert() in
tp_detect_thumb_while_moving() when the second finger comes down because
although we have multiple fingers, none of them are in TOUCH_UPDATE.

This only happens when fingers 2 and 3 come down in the same event frame,
because then we have nfingers_down at 2 (the hovering one doesn't count) but
we don't yet have a finger in TOUCH_UPDATE.

Fix this twofold, first by now calculating the speed on anything but
TOUCH_UPDATE. And second by force-resetting the speed count on
TOUCH_BEGIN/TOUCH_END so we definitely cover all the hover transitions.

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

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

When we disable the touch device, any existing touches should be cancelled,
not just released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Because that's how we use it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This is a 0-360 ranged value, so let's print it aligned.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

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

This touchpad stops sending pressure data after the first frame of the second
finger down. If the initial pressure is too light, the finger doesn't get
detected even when the pressure increases in the future.

This thing is from 2014, so let's just disable the pressure axes on it
and skip the pressure-based touch detection code. Let's hope that it doesn't
also have ghost touches on light interactions...

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

Pretends to have a middle button where there is none.

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

Reduces the places we need to update bits for new quirks.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Anything that merely requires a once-off check during initialization can just
use the quirks directly, no need to copy them over to the model flags.

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

Fix libinput_event_destroy call by passing the correct parameter (event) in the
example code.
Signed-off-by: Diego Rondini <diego.rondini@kynetics.com>

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

The hwdb match entry used to be this one:
 libinput:name:*Elan Touchpad*:dt:*
  LIBINPUT_ATTR_PRESSURE_RANGE=10:8
from commit 596777a3. It was intended to match
for devicetree only but the way the udev rules were composed, it ended up
matching on any system.

Restore that for all systems to have compatibility with 1.11. For this one,
let's also add the resolution hint and hope that that works too.

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

Copy/paste typos introduced in the hwdb to quirks transition

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

Was 0x800 in the hwdb, became 0x8000 in th quirks transition because of
inflation, but let's pretend the economy is back to normal and devalue our
currency. (aka: "it was a typo", whoops and whatnot)

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

If sizeof(long) == sizeof(int), this test won't pass so let's drop it
altogether.

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

The previous check only worked if sizeof(long) > sizeof(int). Rather than be
fancy about it, just cast to a signed long, check for negativity and continue
based on that.

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

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

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

This tool is now obsolete, we don't use that range anywhere.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

All we do now is to set the fuzz, so we only ever need to care about this when
a device has absolute axes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

This was removed accidentally as part of a9ef4ba1 and then completely dropped in
870ddce9 when the hwdb was deprecated completely. The model quirks call
is also the one that reads and sets the LIBINPUT_FUZZ property, effectively
making that code a noop.

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

We may get a pointer jump on tip down/up, see #128. For absolute coordinates
we reset the history to avoid smoothing across that jump but deltas still used
to be calculated based on the previous position to the current one. This
can result in a large jump on tip down.

Since the delta is supposed to be useful (and not physically accurate, see the
docs), let's force it to 0/0 on tip down/up to avoid that scenario.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>