Our parser doesn't care about this, but let's stick to the proper format so
we can read those files with e.g. Python's ConfigParser
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Apple M2 (and presumably newer) laptops now embed the touchpad
controller into the main SoC, and use a new internal communications
protocol between it and the main CPU. This isn't really a "bus" like
SPI or I2C, so the downstream kernel driver currently uses the (not
well supported) HOST bus type. MatchBus can't match on that, so let's
just use a name match (plus the vendor ID, which is still valid and
the usual Apple one).
Signed-off-by: Hector Martin <marcan@marcan.st>
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>
The current defaults detect force presses as palm or thumb.
The values provided here work for a 99% accurate palm/thumb detection
and provide close zero false positives in my tests.
Signed-off-by: Davide Depau <davide@depau.eu>
The external Apple "Magic" trackpads, both the first and the second
generations, have pretty good built-in spurious touch filtering. For
these device models libinput's own filtering is not required. Using low
enough values such as 20:10 effectively disables libinput's filtering.
Signed-off-by: Yariv Barkan <oigevald+libinput@gmail.com>
Also, set a default AttrTouchSizeRange for Apple touchpads via Bluetooth
to match the one from the USB rule.
Signed-off-by: Sebastian Krzyszkowiak <dos@dosowisko.net>
The touchpad is 104mmx75mm, but an AttrPalmSizeThreshold of 800 is too
aggressive, and even relatively-small fingers and thumbs register as
palms sporadically, stopping the mouse until you lift your hand and try again.
1600 was chosen because it's the point at which my fingers and thumbs,
held at a very low angle, stop registering as palms, so it should
acommodate bigger fingers.
I don't know if the [Apple Touchpads USB] default of 800 needs to be
updated too, or if it's a quirk of this particular touchpad.
In testing on an Apple Magic Trackpad, thumb touches are reliably
detected by being quite large in the major dimension, but around
half the size in the minor dimension.
