Data in
https://gitlab.freedesktop.org/libinput/libinput/-/issues/225#note_379034
suggests that AES devices have lower noise than the older EMR
devices, so let's try disabling it for those devices.
We can't directly get the AES devices in libinput unless we want to add a
whole bunch of quirks for the various vid/pid combinations. But we can get
that info from libwacom, primarily because we know that libwacom will list all
known AES pens for any device. So we can check for one that we know of (0x11)
and if it's in the list, the tablet is an AES tablet.
Setting the history size to 1 means we never do any actual smoothing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is merely the simple support that we use in the fallback backend as
well. It doesn't interact with touch arbitration directly but it'll be
good enough for the default use-case.
Fixes#476
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>
The Aiptek 8000U has a pressure offset above our default (%5) but no
meaningful way of detecting that. It doesn't provide distance or BTN_TOOL_PEN
either, so our heuristics can't hook onto anything. BTN_TOUCH is set by this
tablet but not at consistent pressure thresholds.
Work around this by shipping a quirk that ups it to 70. Aiptek
re-uses USB IDs because of course they do, so this applies to more than one
device. Let's see what breaks.
Fixes#462
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>
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>
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>
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>
The offset handling was inconsistent, stored as relative to the axis minimum
but used as absolute in some places. Fix this by always using the absolute
value including the minimum (i.e. no pressure offset means offset == minimum).
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>
__builtin_popcount might not be available and in this case, a bitwise-and
can accomplish the same task.
Signed-off-by: Michael Forney <mforney@mforney.org>
No real changes for the non-tablet code, but for tablets we now keep the
libwacom datbase around. The primary motivating factor here is response time
during tests - initializing the database under valgrind took longer than the
proximity timeouts and caused random test case failures when a proximity out
was triggered before we even got to process the first event.
This is unfortunately a burden on the runtime now since we keep libwacom
around whenever a tablet is connected. Not much of an impact though, I
suspect, chances are you're running a web browser and everything pales against
that anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Follow-up to 6229df184e
We must not rely on the caller to toggle the left-handed bits correctly since
they may not know which devices belong together (despite device groups). Let's
do the right thing here, if the touchpad is set to left-handed, rotate the
tablet accordingly.
Note that the left-handed setting of the touchpad is left as-is
(right-handed). Until we have notifications about configuration changes, this
is the best we can do.
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>
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>
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>
This enables us to specify the location that needs to be arbitrated, rather
than just disabling the whole device altogether. This patch just adds the
hooks, no implementation.
This is internal API only, one backend can specify an area in mm which gets
converted to device coordinates in the target device and arbitrated there.
Right now, everything simply passes NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This enables us to change the types of touch arbitration, with the focus on
allowing location-based touch arbitration as well as the more generic "disable
everything".
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#146
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>
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>
On some ELAN tablets we get a coordinate jump in the same frame that we put
the tip down. The existing axis smoothing causes that jump to be somewhere in
the middle between the previous and the next coordinates, causing a small
stroke from the smoothed position to the next. Prevent this by resetting the
history on tip down/up so we always take that coordinate.
Fixes#94
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The struct input_event is not y2038 safe.
Update the struct according to the kernel patch:
https://lkml.org/lkml/2018/1/6/324
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-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=104911
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
