These numbers just happened to add up correctly for the motion history to
produce a zero delta for a diagonal movement. Fix it by adding extra events to
flush out any motion history leftovers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This test had a loop around the proximity events, so in theory we could've
sent two proximity-in events and still get a positive test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When the touch arbitration is reset to ARBITRATION_NOT_ACTIVE, the proximity
timer is set for 90ms to avoid erroneous touches (see 2a378beab for the
reason).
If the device is removed within those 90ms, the timer is never cancelled,
leading to an assert on cleanup.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the tilt angle on tip down is not 0 set the touch arbitration to a
rectangle around the assumed position of the hand. This assumed position is
right of the tip for a rightwards tilt and left of the tip for a leftwards
tilt (i.e. left-handed mode). The rectangle is 200x200mm with a 20x50mm
NW of the tip or NE for left-handed. In other words, if the period below is
the tip, the rectangle looks like this:
+-----------+ +-----------+
| . | <- for rightwards tilt | . |
| | | |
| | | |
| | for leftwards tilt -> | |
+-----------+ +-----------+
Touches within that rectangle are canceled, new touches are ignored. As the
tip moves around the rectangle is updated but touches are only cancelled on
the original tip down. While the tip is down, new touches are ignored in the
exclusion area but pre-existing touches are not cancelled.
This is currently only implemented in the fallback interface, i.e. it will
only work for Cintiqs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When a hand is resting on a pen+touch device, lifting the hand may remove the
stylus from proximity before the hand leaves the surface. If the kernel
performs touch arbitration, this triggers a touch down on proximity out,
followed by a touch up immediately after when the hand stops touching.
This can cause ghost touch events. Prevent this by using a timer-based
arbitration toggle.
Same as 2a378beab0 but for the fallback
interface.
Signed-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>
Because we're doing axis smoothing, we may get a nonzero delta between events
even when the real axis hasn't updated. Make sure the bit is set in this case.
One part of #128
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This forces events for every ~10ms now. If we want a slower movement, we need
more steps - just like a real touchpad does it.
Cocinelle spatch files were variants of:
@@
expression A, B, C, D, E, F, G, H, I, J, K;
@@
- litest_touch_move_two_touches(A, B, C, D, E, F, G, H, I)
+ litest_touch_move_two_touches(A, B, C, D, E, F, G, H)
The only test that needed a real fix was touchpad_no_palm_detect_2fg_scroll,
it used 12ms before, now it's using 10ms so on the bcm5974 touchpad the second
finger was a speed-thumb. Increasing the events and thus slowing down the
pointer means it's a normal finger and the test succeeds again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once we start working with real event frames (i.e. intervals after SYN_REPORT)
we'll always trigger the proximity timeout here. Avoid this by sending one
event with all buttons.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the same blurb everywhere, changing from the old style MIT to the Expat
license we're using everywhere else.
Similar to bc9f16b40e
Signed-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=104985
Signed-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=104940
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>
Some pens keep sending small amounts of pressure even when the tip is up. This
isn't always a sign of the pens worn out, it also happens on the new Pro Pen
3D models.
The X driver uses a default threshould of ~1.3% to paper over this, let's do
the same with a 1% threshold. This threshold only applies to pens that don't
already have a pressure offset anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=103086
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And instead disable it when we do get a proximity out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Some devices like the UC Logic WP5540U has BTN_STYLUS but not BTN_TOOL_PEN.
While a kernel bug, let's just handle these correctly anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=102570
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yay-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Could be fixed in the kernel, but these tablets are effectively abandoned and
fixing them is a one-by-one issue. Let's put the infrastructure in place to
have this fixed once for this type of device and move on.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Yay-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Uninitialized variables, potential NULL dereferences, dead assignments and an
unused return value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
test-tablet.c: In function ‘proximity_in_out’:
test-tablet.c:797:20: warning: increment of a boolean expression [-Wbool-operation]
have_tool_update++;
And tighten the test so we fail for multiple prox in events
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Taking the tablet events as-is produces the occasional wobble in what should
be a straight line. Bug 99961 has a jpg attachment to illustrate that.
Emulate the wacom driver behavior and average x/y across the last 4 values to
smoothen out these dents.
https://bugs.freedesktop.org/show_bug.cgi?id=99961
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
Nothing actually called that function, sprinkle a few calls into existing
tests to make sure it actually works.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These conditions were never triggered by our test suite, so let's tighten up
the tests to match what we expect.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
gcov analysis showed that none of the actual testing conditions were hit, so
the test succeeded despite not actually testing anything. Which is good,
because testing for tilt normalization isn't correct anyway, tilt is in
physical degrees,
Drop the test and replace it with a test for pressure normalization instead.
We already have a similar one to check for [0, 1] range, this new one
explicitly tests for the extents.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
They weren't originally prefixed but the various tests were, but now that we
only have one test runner binary anyway, the prefix helps sorting the files
easily within e.g. gcov results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
