If we created it, remove it again. No change because we're not adding any of
the directories yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make the tempfile creation dependent on whether the required template is
present. Currently unused, this is just prep work for future patches.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The GitLab migrations means that bugs should now be reported there
rather than Bugzilla. Though the repository is still available via
anongit, cloning through GitLab allows use of HTTPS.
All freedesktop.org URLs are also preferentially served over HTTPS
rather than unsecured HTTP.
Signed-off-by: Daniel Stone <daniels@collabora.com>
The lenovo compact keyboard with trackpoint has a sensitivity of 5, which
causes the trackpoint range to be 0. This in turn causes inf/NaN during
pointer acceleration as we divide by 0 and makes the cursor go unpredictably
somewhere it probably shouldn't be.
This is part of a wider problem in that the current sensitivity handling
doesn't work well for values well below the default of 128. Any such values
are scaled up to multiples of pixels instead of just working as-is.
Reverting the automatic sensitivity parsing, any systemd udev property set to
change the sensitivity increases it, so we don't run into this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1583324
This reverts commit a4036a33ca.
On the off-chance that someone actually looks at this page, let's put the
comment most at risk by a TLDR attention span at the top.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was overengineered. The separation between the model quirks file and the
udev hwdb matches allowed for more complex firmware detection. Except we never
used it anywhere but on ALPS and there we can, thankfully, just get it from
the version number in the input_id field exposed in the modalias.
So let's drop this and use that match instead. We just need an extra udev rule
to match on ID_INPUT_POINTINGSTICKs so we can differ between ALPS touchpads
and ALPS trackpoints.
https://bugs.freedesktop.org/show_bug.cgi?id=106323
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
LIBINPUT_ATTR_THUMB_PRESSURE_THRESHOLD now determines whether we do thumb
pressure detection or not. Much better than having a hardcoded default that
may or may not be correct on any given device.
This patch is likely to break thumb detection on some touchpads, the only
property so far is to restore the default of 100 for all Lenovo Thinkpad
touchpads. More rules are needed, we'll just wait until someone shouts.
https://bugs.freedesktop.org/show_bug.cgi?id=106458
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the artificial 3 keyboard limit. If you have more internal
keyboards than that, something is wrong in your setup but that shouldn't stop
us from working. Or more specificially: this can happen easily when running
tests so let's not fail the test suite because we created a few hundred
keyboards.
We'll still throw out a log message though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes the artificial 3 keyboard limit. If you have more internal
keyboards than that, something is wrong in your setup but that shouldn't stop
us from working. Or more specificially: this can happen easily when running
tests so let's not fail the test suite because we created a few hundred
keyboards.
We'll still throw out a log message though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add support for firmware detection on pointing stick devices. This
is needed for ALPS only at this time.
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput-measure-trackpoint-range doesn't work well for ALPS
touchsticks that have minimum delta amplitude of ~8. Fix that
by analyzing min and max amplitude (radius) of the measured deltas,
and suggesting a high trackpoint range value if ALPS-typical behavior
is encountered. Also, suggest a different calibration procedure
to the user; rather then just calibrating quick movements, slow, gentle
movements should also be covered.
Signed-off-by: Martin Wilck <mwilck@suse.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This raises the trackpoint speed limit to something more conducive to
long-distance moves.
https://bugs.freedesktop.org/show_bug.cgi?id=106506
Signed-off-by: Chow Loong Jin <hyperair@debian.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This seems to give me roughly the same behaviour as macos does on the default
0 speed setting.
* Default speed is lower than before by around 30% [1]
* Acceleration kicks in much sooner (130mm/s vs 250mm/s before)
* Acceleration kicks in slower at lower speeds, so the change from 130mm/s to
150mm/s is less than that of 320mm/s to 350mm/s
* The effect of the speed setting is a wide-range constant (de|ac)celeration
[2], which means:
* The unaccelerated baseline up until the threshold now changes with the
speed setting
* The threshold is now the same for all speeds
* The range of the speed setting should now easily cover all desired device
speeds.
* Acceleration is steeper at higher speeds
* Deceleration was left as-is.
[1] This may or may not fix the jumping pointer issues caused by the previous
high defaults. When you have high default acceleration you move the finger
slower. This slow movement caused some touchpads (mostly seen on Lenovos) to
create pointer jumps. These weren't seen on synaptics previously because of a
combination of higher user finger speed (thus not triggering the bug) or just
not being as obvious (2px jump vs 10 px jump).
[2] The speed setting is actually a curve, the closer you get to 1.0 the more
difference you see between two different values. The curve's points are:
-1/0, 0/1, 1/5, so the resolution is closer for slow speeds. We still have
double resolution on the setting though so you'll find what you want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is supposed to come from systemd on a real setup, but for our test setup
we want to pass the test suite even when the system itself doesn't set it.
There are 4 possible cases why a touchpad suspends right now: lid switch,
tablet mode switch, sendevents disabled and sendevents disabled when an
external mouse is present.
But these reasons can stack up, e.g. a lid switch may happen while send events
is disabled, disabling one should not re-enable the touchpad. This patch adds
a bitmask to remember the reasons we're current suspended, resuming only
happens once all reasons are back to 0.
https://bugs.freedesktop.org/show_bug.cgi?id=106498
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Because we register the handler separately (once for lid, once for
tablet-mode) the handler is called twice for the same event. This causes a
double-suspend of the touchpad, though it doesn't seem to have any real
effect.
Split it up so that each handler function only does one thing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
And rename the model flag, no point in having separate flags here, we likely
have to add more devices over time.
https://bugs.freedesktop.org/show_bug.cgi?id=106534
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Found by scan-build, running ptraccel-debug --mode=sequence --nevents=5
would use garbage custom_deltas.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes the dead code issue introduced in
822c97a1c2, print_accel was always
true so the rest of the code never got triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Coverity screwed up something so we can't submit builds right now, the
compilation units all fail. math.h pulls in a _Float128 type that coverity
cannot handle. So as a workaround, add an option to the build to avoid this
and remove it when the next version of coverity hopefully fixes this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
