summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* evdev: if a device's rotation is around 180 degrees, flip the wheelPeter Hutterer2023-04-271-0/+19
| | | | | | | | | | | For a device used upside-down, make sure the wheels correspond to the new physical directions. There's a grace range of 20 degrees either way since that seems like it makes sense. For 90 degree rotation (or 270 degree) the wheel is left as-is, the heuristics to guess what angle we want in this case is not clear enough. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* fallback: remove write-only rotation.is_enabled variablePeter Hutterer2023-04-272-2/+0
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Disregard touchless clicks on flaky devicesRobert Glossop2023-04-113-0/+14
| | | | | | | | Some touchpads, notably those on the Dell XPS 15 9500, are prone to registering touchpad clicks when the case is sufficiently flexed. Ignore these by disregarding any clicks that are registered without touchpad touch. Signed-off-by: Rob Glossop <robgssp@gmail.com>
* touchpad: Disable edge palm detection Apple touchpadsHector Martin2023-04-061-0/+4
| | | | | | | | | | | This hurts more than it helps, and users complain of dead trackpad edges. Apple touchpads have fairly sophisticated internal palm rejection algorithms going back many years, so let's just disable this one on everything Apple. Related to: #433 (need to figure out what other hardware may need this) Signed-off-by: Hector Martin <marcan@marcan.st>
* evdev: Enable natural scrolling by default on AppleHector Martin2023-04-062-2/+13
| | | | | | As suggested by the comment itself. I think most users expect this. Signed-off-by: Hector Martin <marcan@marcan.st>
* tablet: always enable touch arbitration with touchscreens/ext. touchpadsPeter Hutterer2023-03-301-14/+38
| | | | | | | | | | | | | | | Right now for touch arbitration to work, we require the device group to be the same (i.e. they're hanging off the same physical bus). That's not always the case and statistically we have a lot more devices that have a built-in tablet + touchscreen than we have Intuos-like external tablets. So let's default to the more common case - enabling arbitration with the first touchscreen/external touchpad we find. If a subsequent device is "better", swap it out. Right now, the only heuristic we have here is the device group check but in the future we could get more precise. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* tablet: split out arbitration/rotation handling assignmentPeter Hutterer2023-03-301-22/+36
| | | | | | No functional changes Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* fallback: don't double-map if any left-handed buttons are downPeter Hutterer2023-03-291-1/+6
| | | | | | | | | | | | | The key_count array for buttons records the logical button sent to the client - for left-handed configurations that means a BTN_LEFT is recorded as BTN_RIGHT. When the device is suspended and we are releasing all keys we must thus release the button code as-is without trying to map it again. Fixes #881 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* doc: document libinput_device_tablet_pad_get_* error caseJosé Expósito2023-03-251-3/+3
| | | | | | | | | Like in libinput_device_switch_has_switch()'s documentation, document the error case in libinput_device_tablet_pad_get_num_buttons(), libinput_device_tablet_pad_get_num_rings() and libinput_device_tablet_pad_get_num_strips(). Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* touchpad: rm dead tp_palm_tap_is_palmTobias Bengfort2023-03-233-33/+0
| | | | | | | | | | | | | | | This was added in 39f11253471500cd380c8977b8cbe0683abe6b1d (https://bugs.freedesktop.org/show_bug.cgi?id=89625) Later, a more sophisticated palm detection was implemented in 46eab97538af18381243f5337bf3d29e4b21098f (https://bugs.freedesktop.org/show_bug.cgi?id=103210) The only place where `tp_palm_tap_is_palm()` is called is if the more sophisticated palm detection has already decided that this is not a palm, so it should never return true. Signed-off-by: Tobias Bengfort <tobias.bengfort@posteo.de>
* filter: add scroll movement type to the custom acceleration profileYinon Burgansky2023-02-2421-11/+134
| | | | | | | | Adds a dedicated scroll movement type to the custom acceleration profile. Supported by physical mouse and touchpad. Other profiles remain the same by using the same unaccelerated filter for the scroll filter. Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
* filter: simplify speed_factor()Tobias Bengfort2023-02-081-12/+2
| | | | | | The `speed_factor()` formula is unnecessarily complex, The behavior that is described in the comment can be achieved with a simple power function. And adjust the comment to explicitly state that 0.05 is the minimum.
* evdev: apply calibration for touch arbitrationhrdl2023-02-081-3/+10
| | | | | | | Rectangle-based touch arbitration should respect calibration. This fixes #853. Signed-off-by: hrdl <git@hrdl.eu>
* evdev-tablet: clip touch arbitration rectanglehrdl2023-02-071-3/+3
| | | | | | | Previously the arbitration rectangle would be moved to lie completely in the first quadrant of the coordinate system. Signed-off-by: hrdl <51402-hrdl@users.noreply.gitlab.freedesktop.org>
* filter: validate custom acceleration function's points sizeYinon Burgansky2023-02-023-0/+22
| | | | | | | Adds min and max size limit for custom acceleration function's points. Adds tests to make sure validation works properly. Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
* Introduce custom acceleration profileYinon Burgansky2023-01-1712-10/+839
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The custom acceleration profile allow the user to define custom acceleration functions for each movement type per device, giving full control over accelerations behavior at different speeds. This commit introduces 2 movement types which corresponds to the 2 profiles currently in use by libinput. regular filter is Motion type. constant filter is Fallback type. This allows possible expansion of new movement types for the different devices. The custom pointer acceleration profile gives the user full control over the acceleration behavior at different speeds. The user needs to provide a custom acceleration function f(x) where the x-axis is the device speed and the y-axis is the pointer speed. The user should take into account the native device dpi and screen dpi in order to achieve the desired behavior/feel of the acceleration. The custom acceleration function is defined using n points which are spaced uniformly along the x-axis, starting from 0 and continuing in constant steps. There by the points defining the custom function are: (0 * step, f[0]), (1 * step, f[1]), ..., ((n-1) * step, f[n-1]) where f is a list of n unitless values defining the acceleration factor for each velocity. When a velocity value does not lie exactly on those points, a linear interpolation of the two closest points will be calculated. When a velocity value is greater than the max point defined, a linear extrapolation of the two biggest points will be calculated. Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: add helper functions to create/destroy a delta smoothenerPeter Hutterer2023-01-174-13/+19
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* quirks: touchpad: add ModelPressurePadJosé Expósito2023-01-163-1/+4
| | | | | | | | | | | | | Unlike in traditional touchpads, whose pressure value equals contact size, on pressure pads pressure is a real physical axis. We don't take advantage of the pressure information reported by pressure pads yet, so we disable it to avoid errors. Add a new model quirk for pressure pads instead of disabling ABS_MT_PRESSURE and ABS_PRESSURE. Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* Allow rotation on all mice and for any angleLucas Zampieri2022-12-054-18/+20
| | | | | | | | | | | | Previously we restricted rotation to trackballs only and to multiples of 90 degrees. Update rotation allow angles other than multiples of 90. Also enable rotation on all mice. The only devices without rotation are now pointing sticks. Fixes #827 Signed-off-by: Lucas Zampieri <lzampier@redhat.com>
* evdev: only read the trackpoint multiplier on trackpointsPeter Hutterer2022-12-051-2/+4
| | | | | | | | Check the tag before we read any multiplier quirks. And don't bother reading the DPI for trackpoints either because it doesn't make sense for those devices. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* quirks: allow overriding of AttrEventCode and AttrInputPropPeter Hutterer2022-11-285-93/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This switches the quirk from AttrEventCodeEnable/Disable to just AttrEventCode with a +/- prefix for each entry. This switches the quirk from AttrInputPropEnable/Disable to just AttrInputProp with a +/- prefix for each entry. Previously, both event codes and input props would only apply the last-matching section entry for a device. Furthermore, an earlier Disable entry would take precedence over a later Enable entry. For example, a set of sections with these lines *should* enable left, right and middle: [first] AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT;BTN_MIDDLE [second] AttrEventCodeDisable=BTN_RIGHT [third] AttrEventCodeEnable=BTN_LEFT;BTN_RIGHT; Alas: the first line was effectively ignored (quirks only returned the last-matching one, i.e. the one from "third"). And due to implementation details in evdev.c, the Disable attribute was processed after Enable, i.e. the device was enabled for left + right and then disabled for right. As a result, the device only had BTN_LEFT enabled. Fix this by changing the attribute to carry both enable/disable information and merging the commands together. Internally, all quirks matching a device are simply ref'd into an array in the struct quirks. The applied value is simply the last entry in the array corresponding to our quirk. For AttrEventCode and AttrInputProp instead do this: - switch them to a tuple with the code as first entry and a boolean enable/disable as second entry - if the struct quirk already has an entry for either, append the more recent one to the existing entry (instead of creating a new entry in the array). This way we have all entries that match and in-order of precedence - i.e. we can process them left-to-right to end up with the right state. Fixes: https://gitlab.freedesktop.org/libinput/libinput/-/issues/821 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Remove duplicate empty lines in our sourcePeter Hutterer2022-11-2518-25/+0
| | | | | | | We only touch src and tools, imported headers from include are not ours to change. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Remove a few empty lines with nothing but a lonely tabPeter Hutterer2022-11-253-4/+4
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* Remove trailing whitespaces in the treePeter Hutterer2022-11-251-1/+1
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* tablet: increase touch arbitration rectangle heightJosé Expósito2022-11-231-4/+4
| | | | | | | | | | | A user was experiencing issues with their hand being recognized as touch input above the stylus tip. Since touch above the stylus should be rare, increase the touch arbitration rectangle height by 50mm. Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/809 Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* tablet: fix compiler warning when -Dlibwacom=falseJosé Expósito2022-11-231-3/+3
| | | | | | | | | | | | | | | | Fix the warning generated: [82/243] Compiling C object libinput.so.10.13.0.p/src_evdev-tablet.c.o ../src/evdev-tablet.c:938:1: warning: unused function 'tool_set_bits_from_libwacom' [-Wunused-function] tool_set_bits_from_libwacom(const struct tablet_dispatch *tablet, ^ When building with Clang v15 and without libwacom: $ CC=clang CXX=clang++ meson builddir -Dlibwacom=false Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* tablet-pad-leds: fix compiler warning when -Dlibwacom=falseJosé Expósito2022-11-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Fix the warnings generated: ../src/evdev-tablet-pad-leds.c:54:1: warning: unused function 'pad_mode_toggle_button_new' [-Wunused-function] pad_mode_toggle_button_new(struct pad_dispatch *pad, ^ ../src/evdev-tablet-pad-leds.c:194:1: warning: unused function 'pad_group_new' [-Wunused-function] pad_group_new(struct pad_dispatch *pad, ^ ../src/evdev-tablet-pad-leds.c:238:1: warning: unused function 'pad_led_get_sysfs_base_path' [-Wunused-function] pad_led_get_sysfs_base_path(struct evdev_device *device, ^ When building with Clang v15 and without libwacom: $ CC=clang CXX=clang++ meson builddir -Dlibwacom=false Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* touchpad: add escape and asterisk to the DWT blacklistJosé Expósito2022-11-141-1/+7
| | | | | | | | | | | | | | | The escape key can be used to cancel a drag and drop action in some desktop environments. However, it triggers disable-while-typing, ending the drag and drop action rather than cancelling it. Add it to the tp_key_ignore_for_dwt() set to avoid it. Since I'm here, add the asterisk key as it is the only numpad key not ignored by tp_key_ignore_for_dwt(). Fix: https://gitlab.freedesktop.org/libinput/libinput/-/issues/820 # [1] Suggested-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org> Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* util: return the number of elements from strv_from_stringYinon Burgansky2022-11-074-79/+58
| | | | Signed-off-by: Yinon Burgansky <51504-Yinon@users.noreply.gitlab.freedesktop.org>
* tablet: avoid errors calling libevdev_get_abs_info()José Expósito2022-10-031-0/+16
| | | | | | | | | | | | Commit 806d4a1393db ("tablet: check libevdev_get_abs_info() return value") prevented a crash when tilt was deactivated by a quirk. For more information check [1]. Add similar checks before calling libevdev_get_abs_info() to avoid possible crashes. [1] https://gitlab.freedesktop.org/libinput/libinput/-/issues/805 Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* tablet: check libevdev_get_abs_info() return valueJosé Expósito2022-09-181-0/+4
| | | | | | | | | | | | | | | | Commit b5f0536a4f93 ("quirks: add a quirk for the Wacom 524c device") added the quirk "AttrEventCodeDisable=ABS_TILT_X;ABS_TILT_Y;" to the Wacom 524c. When using the pen in a display with tilt support, the tilt X/Y axes are set as changed. Using the pen again, but this time in the display without tilt support, will try to get the tilt information, crashing. Check the return value of libevdev_get_abs_info() to avoid this crash. Fix https://gitlab.freedesktop.org/libinput/libinput/-/issues/805 Fixes: b5f0536a4f93 ("quirks: add a quirk for the Wacom 524c device") Signed-off-by: José Expósito <jose.exposito89@gmail.com>
* filter: add a flat trackpoint accelPeter Hutterer2022-09-083-10/+167
| | | | | | | | | | | Previously, trackpoints got assigned the normal flat profile which does not accommodate for the trackpoint magic multiplier *and* had a config range that was too small if you take the multiplire indo account anyway. Fix this by adding a trackpoint-specific flat accel that has a wider configuration range and take sthe magic multiplier into account. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: apply the same factor for constant motion as for normal motionPeter Hutterer2022-09-082-14/+24
| | | | | | | | | | | | Users that want a flat pointer acceleration want the input speed to match 1:1 to the output speed, barring a fixed constant multiplier. This will apply to things like button scrolling as well, so let's map the constant accel function to the non-constant accel functions to the speed setting applies to every movement. This is applied to both the flat and the touchpad flat filter. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: don't normalize the speed again in the default mouse filterPeter Hutterer2022-09-081-4/+1
| | | | | | | | | | | The first thing this filter does is normalize the coordinates to 1000dpi, i.e. all other values are in normalized coordinates. By normalizing the speed again we get an invalid value, effectively stretching or compressing the acceleration curve. e.g. on a 5000dpi mouse the estimated speed was 1/5 of the real speed. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* evdev: use filter_dispatch_constant() for the lenovo trackpoint "wheel"Peter Hutterer2022-09-083-18/+10
| | | | | | | Rather than normalizing manually, leave this up to the pointer acceleration code. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* evdev: use filter_dispatch_constant() for button scrollingPeter Hutterer2022-09-081-7/+13
| | | | | | | | | | | | | Our pointer filter code has two functions - one for accelerated movement and one for "constant" movement (i.e. no accel factor provided but same conversions). Let's use that instead of a manual normalization. This fixes an issue with button scrolling on high-dpi mice in the flat pointer acceleration: normal pointer motion in the flat profile isn't normalized but the button scrolling was - resulting in e.g. 5 times slower motion for button scrolling on a 5000dpi mouse. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: don't normalize the const filter approachPeter Hutterer2022-09-082-8/+10
| | | | | | | | | | | | | | | The filter vs const filter is supposed to be for accelerated vs non-accelerated motion (e.g. pointer motion vs scrolling) - in both cases the returned value is supposed to be in the same coordinate system, just once with an extra accel factor applied. This was broken in the flat and low-dpi profiles: in both of those the accelerated filter does *not* normalize, it merely applies the fixed/adaptive factor. The constant filter normalized however. The result was that on e.g. a 5000dpi mouse the constant motion was 5 times slower than the accelerated motion, even with a factor of 1. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: constify the interfaces and make them staticPeter Hutterer2022-09-089-9/+9
| | | | | | No functional change Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* evdev: rename post_trackpoint_scroll to post_button_scrollPeter Hutterer2022-09-081-4/+4
| | | | | | This is no longer trackpoint-only, so let's rename this. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: localize a few variablesPeter Hutterer2022-09-081-10/+6
| | | | | | No functional changes Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: constify the tracker APIPeter Hutterer2022-09-081-5/+5
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: remove an unnecessary layer of indirectionPeter Hutterer2022-09-083-117/+39
| | | | | | | | | | | | | | This is a leftover from when some of the filter code was shared between pointer acceleration methods (pre v1.11 or so). Now these functions are duplicated across files, so both the names and what they do isn't necessarily reflective anymore. Let's drop one layer of indirection to make the code a bit easier to understand. No functional changes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: fix the mix of normalized vs device coordinatesPeter Hutterer2022-09-081-15/+15
| | | | | | | | | | | | No functional changes, this is just for improving readability and a leftover when some of these functions were used by multiple filters. This filter normalizes the data first, then applies the acceleration to the normalized values. So let's keep the data in normalized_coords structs and only drop to device_float_coords when we have to to use the tracker API. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* filter: a few whitespace fixes and extra commentsPeter Hutterer2022-09-083-10/+12
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* evdev: remove duplicate "device is a switch" messagePeter Hutterer2022-08-231-1/+0
| | | | | | We log this a few lines south of here. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* evdev: fix a tab vs space indentation issuePeter Hutterer2022-07-121-12/+12
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* wheel: fix Lenovo Scrollpoint quirkJosé Expósito2022-06-071-2/+7
| | | | | | | | | | | | | | | | | The IBM/Lenovo Scrollpoint mouse features a trackpoint-like stick that sends a great amount of scroll deltas. In order to handle the device, a quirk is in place to normalize the scroll events as they were relative motion. However, when high-resolution scroll was implemented, we started normalizing the hi-res events instead of the lo-res events by mistake. Fix the quirk by normalizing the right deltas. Fixes: 6bb02aaf307a ("High-resolution scroll wheel support") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Tested-by: Peter Ganzhorn <peter.ganzhorn@gmail.com>
* filter-touchpad: normalize for dpi on the touchpad-specific flat profilesatrmb2022-05-291-6/+7
| | | | | | | | | | | | | | | | | | | | On mice, switching the acceleration profile to flat disables dpi normalization, because high or even switchable dpi are generally major features of a high-end mouse, and switching to flat acceleration indicates that the user wants to reduce the effects of any cursor acceleration to a minimum. Therefore we skip normalization there and let the user take full advantage of their expensive hardware. On touchpads, particularly those built into a laptop, users have to deal with whatever hardware they have; touchpad dpi is an afterthought at best, or a disaster at worst. Switching to the flat profile is more likely to be about avoiding the non-linear acceleration curve of the adaptive profile. Hence the flat profile for touchpads shouldn't copy what the one for mice does, but rather use dpi normalization like the adaptive profile. This keeps flat acceleration on low-resolution touchpads from dropping to unusably slow speeds. Signed-off-by: satrmb <10471-satrmb@users.noreply.gitlab.freedesktop.org>
* tablet: require a minimum pressure before we process pressure eventsPeter Hutterer2022-05-232-31/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tools default to 1% lower threshold (tip up) and 5% upper threshold (tip down). But our distance vs pressure exclusion would reset the distance for *any* pressure value, regardless how low that value was and how high distance was in comparison. A very low pressure value of less than 1% would then result in a normalized pressure of 0, so we'd effectively just reset the distance to zero and do nothing with the pressure. This can cause distance jumps when the tool arbitrarily sends low pressure values while hovering as seen in https://github.com/libsdl-org/SDL/pull/5481#issuecomment-1118969064 Commit 61bdc05fb0f84303f97daaba6ae6b49c976dbfbf from Dec 2017 "tablet: set the tip-up pressure threshold to 1%" was presumably to address this but no longer (?) works. Fix this by addressing multiple issues at the same time: - anything under that 1% threshold is now considered as zero pressure and any distance value is kept as-is. Once pressure reaches 1%, distance is always zero. - axis normalization is now from 1% to 100% (previously: upper threshold to 100%). So a tip down event should always have ~4% pressure and we may get tablet motion events with nonzero pressure before the tip down event. From memory, this was always intended anyway since a tip event should require some significant pressure, maybe too high compared to e.g. pressure-sensitive painting - where a tablet has an offset, add the same 1%/5% thresholds, on top of that offset. And keep adjusting those thresholds as we change the offset. Assuming that the offset is the absolute minimum a worn-out pen can reach, this gives us the same behaviour as a new pen. The calculation here uses a simple approach so the actual range is slightly larger than 5% but it'll do. Previously, the lower threshold for an offset pen was the axis minimum but that can never be reached. So there was probably an undiscovered bug in there. And fix a bunch of comments that were either wrong, confusing or incomplete, e.g. the pressure thresholds were already in device coordinates. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* tablet: use a helper variable to make the code more readablePeter Hutterer2022-05-231-4/+5
| | | | Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
View Lorry Controller Status