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>
No effect since we don't care about the mouse itself. But when running
on kernels without uinput's UI_GET_SYSNAME this can cause misdetection of
the uinput device and test case failures. Simply picking a differently named
device avoids that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch started hovering in the main area, the button state would start
with AREA and never move to the real button state, despite the finger
triggering the pressure thresholds correctly in one of the areas.
This could even happen across touch sequences if a touch went below pressure
in the software button area, it changed to hovering and the button state
changed to NONE. On the next event, the touch is still hovering and the
current position of the touch is taken for the button state machine.
https://bugs.freedesktop.org/show_bug.cgi?id=99976
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Introduced in commit 8e7f99c27a we only allowed horizontal edge scrolling
on devices larger than 50mm to leave enough reactive space on the touchpad.
Looking at a ruler, a 50mm high touchpad is still large enough to leave the
bottom 7mm as an horizontal edge scroll area. Reduce the minimum size to 40mm
instead, that's closer to where it starts to get a bit iffy.
https://bugzilla.redhat.com/show_bug.cgi?id=1422221
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This may be a feature for the future but for now be honest and don't claim
that button-based scrolling is available, it's not hooked up in the absolute
code path.
https://bugs.freedesktop.org/show_bug.cgi?id=99865
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Before, our states were idle, button down and scrolling. This adds a state
where the button is down and the timeout has expired (i.e. we're ready to send
scroll events) but we haven't actually sent any events anymore.
If the button is released in this state, we generate a normal click event.
https://bugs.freedesktop.org/show_bug.cgi?id=99666
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Device needs BTN_MIDDLE disabled, this way middle button emulation is present
by default.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The button-scroll by default behavior is only true on devices with a middle
button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
And disable middle button emulation for this test, it would mess with the test
results.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This failed on devices without a middle button, we just didn't have a test
device to trigger this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We don't have the same libevdev context that libinput has so if libinput
disables/enables event codes we don't see that and may get unexpected
behavior in the test.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Specify the layout of the combo so we know when to initialize palm detection.
This allows us to drop palm detection on external touchpads otherwise,
replacing the wacom-specific check with something more generic..
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Simplest implementation for what we need right now, it turns off an event on
the evdev device and turns it back on again. This allows us to change bits in
the 'normal' event stream, such as changing the tool type without triggering
proximity events for the BTN_TOOL_PEN that all test devices send by default.
This won't work for absolute devices because we need to re-enable with a
struct input_absinfo. But we don't need that ability for now anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We don't initialize click methods on devices with physical buttons. This model
is a special case, it's not a clickpad but it only has one button (because one
button is all you ever need and whatnot).
https://bugs.freedesktop.org/show_bug.cgi?id=99283
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Usually we reply INVALID before we reply UNSUPPORTED but that's only for those
values where the value is a programming error. But in this case it's a bit
more complicated. INVALID is only for the cases where the button doesn't exist
on the device, if we don't have button scrolling at all then we have
UNSUPPORTED for all.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not much we can do here, our virtual devices don't have the sysfs files
required, so they have 0 modes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These tablets only ever give us a close event, the open event is broken. So
when we detect keyboard events, fix the kernel device's state by writing the
event to the fd.
We still sync the lid state manually, in case this fails and we don't get the
SW_LID through the normal event sequence. If it works fine, the real open
event will just be ignored.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't rely on BTN_TOUCH for "finger down", the value for that is hardcoded in
the kernel and not always suitable. Some devices need a different value to
avoid reacting to accidental touches or hovering fingers.
Implement a basic Schmitt trigger, same as we have in the synaptics driver. We
also take the default values from there but these will likely see some
updates.
A special case is when we have more fingers down than slots. Since we can't
detect the pressure on fake fingers (we only get a bit for 'is down') we
assume that *all* fingers are down with sufficient pressure. It's too much of
a niche case to have this work any other way.
This patch drops the handling of ABS_DISTANCE because it's simply not needed
anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
No functional changes, just enables us to use 'continue' instead of piling up
negated conditions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Right now, we fail if we call litest_push_event_frame() when already inside a
frame. For the semi-mt handling we need to do exactly that though, so turn it
into a counting semaphore instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
