- Apr 14, 2021
-
-
Peter Hutterer authored
Fixes #599 Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 13, 2021
-
-
Move the code in used to detect motion based gestures (scroll, swipe and pinch) to tp_gesture_detect_motion_gestures. Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
Move tp_gesture_same_directions, tp_gesture_mm_moved and tp_gesture_init_pinch to be able to use them in future commits. Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
Use a bool instead of an int and also rename the variable to avoid ambiguity with tp_filter_motion(). Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
Change the "cancel" parameter in the existing notify methods (swipe, pinch and gesture_notify) from int to bool. It is used as boolean, the fact that it's an int is just a historical quirkyness. Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
- Apr 09, 2021
-
-
Chris Dickson authored
Signed-off-by:
Chris Dickson <hobochili@pm.me>
-
Peter Hutterer authored
This causes a bunch of "your system is too slow" messages in e.g. the various gesture tests. Fixes 95a72990 Fixes #601 Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 07, 2021
-
-
Peter Hutterer authored
The dispatch time is taken during libinput_dispatch(), i.e. at the beginning of an event sequence. We always read all events off the device, so where events come in while we're inside the main dispatch loop, our event time may be later than the saved dispatch_time. This causes an uint underflow and our tdelta > 10 will be true for that case. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Apr 06, 2021
-
-
Jonas Ådahl authored
We don't want the file to be left open after any fork/exec, and we don't want the read to be blocking; so open it as such. Signed-off-by:
Jonas Ådahl <jadahl@gmail.com>
-
Don't middle click on clickpads with click method clickfinger when more than 3 fingers are used. Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
- Apr 03, 2021
-
-
Ben authored
Signed-off-by:
Ben Weston <b.weston60@gmail.com>
-
- Mar 29, 2021
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
For historical (but not very good) reasons, libinput record printed events from the first device to the output file (or stdout) and buffered everything else. On ctrl+c, the other devices' descriptions and the buffered events were appended to the output file. This makes the printing code rather complex. Simplify it by giving each device a separate FILE* - the first device points to the real output file, the others to a tempfile. On Ctrl+C we just append those tempfiles to the real output file one-by-one and done. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Less confusing than having output_file, out_file, and outfile. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
No functional changes since we can get this easily from the list itself, but in the future the first device will be used more extensively. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Using list_insert() here means the last device specified on the commandline is the one that ends up in the file first - not very obvious... Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Our file format is static enough that we don't need to use push/pop, we know exactly which line is going where. So let's replace it with a static indent instead. 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 is prep work to be more consistent with the use of tempfile later for individual devices. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
With a new helper function strv_from_argv we can re-use the device opening loop for all the use-cases we have. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Mar 26, 2021
-
-
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
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Mar 19, 2021
-
-
José Expósito authored
EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs: https://editorconfig.org/ Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
- Mar 17, 2021
-
-
Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
The current fallback_dispatch wheel struct, a device_coords, doesn't allow to save extra information. The new anonymous struct will allow to add a is_inhibited field to disable mouse scroll while the middle button is pressed and, potentially, any required extra state in the future. Signed-off-by:
José Expósito <jose.exposito89@gmail.com>
-
The FreeBSD HID stack adds the device type to the evdev name, so we get e.g. "ACPI0C50:00 18D1:5028 TouchPad". (Maybe this shouldn't be matched by name at all though...) Signed-off-by:
Greg V <greg@unrelenting.technology>
-
FreeBSD does not use Linux modaliases, so we have to generate these strings. Unfortunately for us, the data in kenv has the chassis type pre-parsed into a nice string, so we have to match these strings back into numbers. Only relevant types are included to avoid bloating the code. Signed-off-by:
Greg V <greg@unrelenting.technology>
-
The Linux applespi driver currently uses the Synaptics vendor ID on the trackpad for some reason (even though, at least from bcm5974 we only know that Broadcom is involved..) but my upcoming FreeBSD driver uses the Apple vendor ID everywhere, so add two quirks. Signed-off-by:
Greg V <greg@unrelenting.technology>
-
Apple MacBooks (Broadwell/Skylake/Kaby Lake and Apple Silicon) use SPI to communicate with the keyboard and trackpad. Signed-off-by:
Greg V <greg@unrelenting.technology>
-
- Mar 16, 2021
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Make sure the unaccelerated deltas are comparable to scroll deltas. edit by whot: The original intention of the unaccelerated motion data here was to provide both accelerated and unaccelerated motion for gestures so it was possible to have 1:1 mapping from gesture motion to screen activity. Normalizing to 1000dpi this way would've worked for mice but touchpad acceleration also includes the TP_MAGIC_SLOWDOWN (amongst other tricks) which slows down motion to around 27% *before* applying the acceleration function. On a 1000dpi touchpad (~40 units/mm) simply normalizing touchpad motion to 1000dpi results in pointer motion that is way too fast, it's lacking that slowdown to 27% of original speed. This results in the accelerated and unaccelerated gesture data being in effectively two different coordinate systems with the caller having no ability to relate the two. Switching to the special constant acceleration applies that slowdown and matches the data to the part of the acceleration curve where no (additional) acceleration is applied. It makes the gesture unaccelerated data comparable to the accelerated data and to scroll data which uses the same process. Fixes #582 Signed-off-by:
Alexander Mikhaylenko <alexm@gnome.org> Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
Without this, each finger movement happens in a different evdev event frame. Since we average deltas for gestures, this messes with the expected data. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
There's no test case where we need to do something immediately after the last event so we might as well do everything in the same loop. This also fixes a bug where the first movement would usually get swallowed. Test cases in general put the finger down at x/y, then move them to some other position. We'd expect the first event in a loop to happen at x+n/y+n, not at x/y again. 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
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
Peter Hutterer authored
See d6e53134 for confirmation that the threshold is intended to be in mm/s, the comment here is simply a leftover from earlier times when the acceleration method was using device-units only. Fixes #585 Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-
- Mar 15, 2021
-
-
Peter Hutterer authored
Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net>
-