- May 29, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
Accidentally updated the wrong picture. This reverts part of commit d6e53134. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Part of d6e53134 but I updated the wrong svg in that commit. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
This is causing too many false positives and they're not easy to filter out. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
https://bugs.freedesktop.org/show_bug.cgi?id=106323 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>
-
- May 25, 2018
-
-
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>
-
Signed-off-by: Martin Wilck <mwilck@suse.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Clearly a copy/paste error. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- May 24, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- May 22, 2018
-
-
Peter Hutterer authored
-
- May 21, 2018
-
-
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>
-
Peter Hutterer authored
-
Peter Hutterer authored
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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 d8bd6505. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
This reverts commit f6d61dc3.
-
- May 18, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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.
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
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>
-
- May 17, 2018
-
-
Peter Hutterer authored
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>
-
- May 16, 2018
-
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
If we need more than 1000 pairs, we have a problem... Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
We need to free 'pairs' here, do so by jumping to the error label. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Fixes the dead code issue introduced in 822c97a1, print_accel was always true so the rest of the code never got triggered. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
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>
-
Peter Hutterer authored
Same as the code itself does. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- May 15, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Well, I say "measure" but really at this point it just reads the properties/axes and then does it's best to auto-generate a hwdb entry that matches the user's hardware and sets a fuzz value on the device. Ideally this reduces the number of hand-holding required in bugzillas. There are plenty of things that can go wrong, so our fallback is still to throw up our hands and point to the documentation. https://bugs.freedesktop.org/show_bug.cgi?id=98839 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- May 14, 2018
-
-
Peter Hutterer authored
ALPS SS5 devices have a range above 100. https://bugs.freedesktop.org/show_bug.cgi?id=106323 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
- May 13, 2018
-
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-