Symmetrical to litest_create_context(), this allows us to store special data
in that context that we have access to during the tests.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This somewhat duplicates the existing test
huion_static_btn_tool_pen_disable_quirk_on_prox_out
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the previous patches a tablet would ignore a valid proximity out sequence
where it happends after a forced prox-out. Fix this by checking the state when
we're in forced proximity out - if we have a zero tool state but a tool
updated then we did get a proximity out.
And fix the existing test to check for that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This quirk was introduced for #248 was caused by buggy input-wacom drivers,
not by actual firmware, see
https://gitlab.freedesktop.org/libinput/libinput/issues/381#note_279371
This appears to be the only tablet where this fix was needed, but we've been
playing whack-a-mole ever since to work around the various other tablets that
break with this behavior in place.
So let's revert that fix and hope there aren't any other tablets out there
(and if they are, we can probably quirk those). The revert makes the ISDV4 pen
quirk obsolete (see 9cb089f2b6), so this was
folded into this commit.
This reverts commit 4f63345b60.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some of these may have a non-libwacom solution but let's be honest, you
shouldn't be skipping libwacom if you rely on tablets to be precise.
Fixes#436
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While buttons are down, don't let a forced proximity out happen. If the tablet
goes out of proximity normally that's fine but we don't force a proximity out.
Remains to be seen if this causes stuck buttons now on devices that rely on
the forced proximity out...
Fixes#403
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We know we should have an event here, so we might as well process it
immediately to speed the error case up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where a pen was forced out of proximity and an eraser came into proximity
without axis updates on the prox-in, subsequent axis updates would trigger the
pen back into proximity. This resulted in two tools in proximity at once
though the new pen never went out of proximity
This would trigger crashes in various compositors/applications, see
https://github.com/xournalpp/xournalpp/issues/1141#issuecomment-578362497
The cause was a wrong condition introduced in ffd8c71e4e. We only need to
force the pen bit on if the current tool state is currently zero and no tool
update was sent with the axis event. In our case, the tool state is nonzero
already (eraser) and we can skip this bit.
Fixes#418
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
As of d20bbfa5cb we handle the direct tool switch correctly so there's
no more warning. Which means testing for the warning is pointless.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
x/y assigned but never used. Dropping those few lines gets rid of the warning
and checks the coordinates correctly now too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some graphics tablets (most or all Wacom, for example) do not emit
proximity out events when the tablet pen goes out of range. To
compensate for this, libinput synthesizes proximity out events when no
events are received for a certain period of time. Unfortunately, on some
tablets, this is fairly failure prone when moving the pen slowly. As a
workaround, this patch causes libinput to avoid synthesizing proximity
out events when the pen is still in contact with the tablet pad, as
defined by the TABLET_TOOL_IN_CONTACT status.
Pens that don't have a pressure offset (caused by a worn-out tip) still have
basic pressure thresholds to avoid tip events when we're still a bit away from
the tablet or barely touching it. That range is currently 5% of the pressure
for tip down, 1% for tip up.
This leaves us with 95% of the range and that needs to be scaled correctly,
otherwise the bottom 5% happen before a tip event and are inaccessible where
applications don't look at pressure before tip down.
Fixes#332
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Theoretically this shouldn't matter, but testing at the far end of the range
is bound to trigger some little issues eventually that should be triggered
explicitly, not by accident.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Previously, the pressure range was calculated from the axis total range. A
device with a pressure offset making the bottom 10% inaccessible would lose
10% of that range as non-accessible. Due to the implementation, this affected
the upper range of the device, so the top N percent became unaccessible. Which
may be why no-one's noticed this yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unsuprisingly, a normalized [0,1] value will always be between 0 and 1, so
bhis gave us a false positive. Check for the real values instead.
Those values aren't 100% correct because of a bug in the offset handling which
will be fixed in a follow-up commit. The difference is near enough that it
doesn't matter here anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We keep running into the proximity timeout for these tests, especially under
valgrind. To avoid this, manually intersperse the touch events with tablet
events.
Note that this manual loop would just work even without tablet events
because we no longer have a 10ms delay between touch events as enforced by
litest_touch_move_to. But let's do the right thing anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Alleged division by zero and use of an uninitialized variable. Both cannot
happen the way we call the tests, so let's just abort to make coverity happy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This pen has random timeouts, often when a button is pressed. This causes a
forced proximity out (and the button release) and makes the whole device a
tad unusable.
Nothing we can detect by heuristics since it looks like other devices that
don't send proximity out events. And the timeout can be quite high, the
recording in #304 has over 800ms for one sequence.
Fixes#304
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Where the proximity out event is delayed by the kernel, libinput would cause
an extra proxmity in-out after the forced proximity out event.
Event sequence is basically (k: kernel, l: libinput)
k: tablet axis events
l: tablet axis events
k: nothing for $proximity timer milliseconds
l: tablet proximity out
k: proximity out event
l: proximity in event
l: proximity out event
Fixes#306
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This device looks similar to a MT device on the kernel side, but it's not a
MT device and it's not quite a tablet either. It uses slots to track up to 4
totems off the same device and the only hint that it's not a MT device is that
it sends ABS_MT_TOOL_TYPE / MT_TOOL_DIAL.
udev thinks it's a touchscreen and a tablet but we currently init those
devices as touchscreen (because all wacom tablet touch devices are udev
tablets+tochscreens). So we need a quirk to hook onto this device.
And we use a completely separate dispatch implementation, because adding the
behavior to the tablet interface requires so many exceptions that it's easier
to just add a separate dispatch interface.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was a copy-paste error in the form of
while(event) {
...}
} while(event);
Found by coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There are tablets out there that *sometimes* send the right event sequence,
but are generally broken. So let's not disable that quirk even if we do get a
right sequence.
Affected devices: Lenovo Flex 5
Fixes#248Fixes#290
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unlike virtually everything else, the tablet tool was processed at the time
the event was read rather than when the subsequent EV_SYN came in. This causes
difficulties with tablets that send the wrong BTN_TOOL_PEN events.
Moving the tool change processing to tablet_flush() makes the injection of the
BTN_TOOL_PEN event a lot easier, simply flipping the matching bit does the
job. It also makes it easier to ignore duplicate tool updates like we've seen
in #259.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A few leaks in the test code were found when running linput-test-suite
with the -fsanitize=address option enabled. Clean up these leaks so that
we can more clearly see real issues.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure we check the expected sequence more stringent and change the x/y
coordinates on prox in so the kernel doesn't filter them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
With the previous code we'd set both tools simultaneously which isn't allowed.
It only worked because the second tool set was the one we cared about.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't require a quirk update, just enable this by default for all tablets. If
we get a proximity out event at the right time, the quirk is disabled for that
tablet for the rest of its lifetime. And it's virtually impossible to have a
false positive here anyway - you cannot hold the pen still enough to not
trigger events for 50ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We expect the kernel to transition properly for us, e.g. BTN_TOOL_PEN goes to
0, BTN_TOOL_ERASER goes to 1. Two cases have surfaced recently where this
doesn't happen and debugging this takes time - so let's warn about it to make
it obvious.
Example 1: https://github.com/linuxwacom/libwacom/issues/70
Example 2: https://gitlab.freedesktop.org/libinput/libinput/issues/259
This is just a warning, nothing more. We should just handle that case
accordingly but that requires more effort.
Fixes#260
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
