Age | Commit message (Collapse) | Author | Files | Lines |
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
During the work with meson I realised auto-detection is not a good solution.
Our dependencies should be well-defined for what is considered 'normal' and
explicitly defined for any deviation from that normal build.
The normal build includes docs, tools, tests, etc. because we expect
developers to find errors in any of those. A distribution build may exclude
some of these bits, but it should be explicitly specified by the distribution
rather than having our build system guess what's not needed.
This patch drops any auto-detection of features and replaces it with a hard
yes/no.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100527
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Introduced in 230af3f9fcf
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Not required because it sets the resolution in the kernel, but we have a
generic "Apple touchpads" rule with a different size. Even though libinput
won't use this property, let's override the generic one with the right
dimensions.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
As of systemd commit f013e99e160f385a0c02793c612ef4c8a8ffc4d7, ID_BUS is now
set for all bluetooth devices, not just those with subsystem bluetooth. This
affects the Apple Magic Mouse and sets the systemd hwdb's MOUSE_DPI value.
That value is different to the test results we currently have, causing some
tests to fail because different deltas are generated (e.g.
pointer_scroll_button).
Our udev rules are prefixed 99 and thus apply after the various system rules.
So we can't easily set ID_BUS in our rule because it'll apply after
70-mouse.rules checks for the bustype. So we'd have to detect systemd version
or so, but the easy way is to simply force MOUSE_DPI to the empty value. For
our test cases it doesn't matter if the DPI is set correctly anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Assigned click counts to other, unrelated devices
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Makes visual identification easier
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If a single log message is composed of multiple calls (as are all from
evdev_log_*), don't prefix multiple times.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
See the getopt_long example, makes the code more obvious
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>
|
|
We don't have frame events for tablets so we must take care to send the
axis change notifications only once and leave the others as-is. Most of the
axes are absolute so it doesn't really matter, but we need to reset the delta
to make sure clients don't receive the same delta twice.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
The tablet axis struct has a delta field that's only useful for the events,
not for our internal axis handling. Make sure we never set it to anything
nonzero.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
Handle the delta in the end once we've updated the device state for all axes.
This requires us to use the device history rather than the current state
delta, and it also requires us to update both x and y whenever an axis change
comes in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
This is a bit hard to follow:
- tilt is handled first and if either tilt axis is set we fetch *both* tilt axes
into tablet->axes.tilt
- rotation is handled second but it only triggers if either tilt axis is
flagged. as we now guarantee to have both axes in tablet->axes.tilt, we
can continue with the rotation conversion without needing some other state
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
This is prep work for axis smoothing. Modify the various helper functions to
just update the state in the tablet and then grab the state later for better
grouping.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
No functional changes, part of the grouping of tablet axis manipulation vs.
processing of that manipulated state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
No functional changes, this is just to group the calls that modify tablet axis
state together and move the bits that rely on this state (but don't modify it)
to the bottom.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
Stores the processed axes values in a history 4 events deep. Currently unused
but will be used to smoothen out axis values to avoid transducer-caused axis
wobbles.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
The current code modifies a bit of state inside the proximity_tip_down
function which makes for confusing reading. Clean this up by having a bunch of
helper functions for the various events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
This cannot trigger because we'd never get here if out-of-proximity is set,
tablet_flush() will return early.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
The only code path that leads here would see the changed_axes array zeroed out
in tablet_send_axis_proximity_tip_down_events(), zeroing again is unlikely to
make it more zero.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Ping Cheng <pingc@wacom.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
And fix up the one buggy call we had
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=100122
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Print the axis values on proximity out because it a) ensures we have the right
values and b) makes the output better aligned with the proximity in, so it's
easier to spot in a log file. But don't print the tool capabilities because
they're unrelated to the prox out anyway and again it makes the output easier
to spot.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If not set, libtool will search directories up to ../.. for an install-sh and
then dump the aux files there. This caused a couple of problems with the xorg
release.sh script that now uses worktrees but is generally bad behaviour
because we can't guarantee that we're not inside some other repository.
Set AC_CONFIG_AUX_DIR to avoid this behavior.
See https://lists.freedesktop.org/archives/xorg-devel/2017-March/053006.html
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This device only sends ABS_PRESSURE
https://bugs.freedesktop.org/show_bug.cgi?id=100106
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
https://bugs.freedesktop.org/show_bug.cgi?id=99975
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Introduced in commit 8e7f99c27ab39 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>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
|
|
We don't cater for the special case of groups having a different number of
modes, there is no hardware right now that does that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|