The Contour RollerMouse have a button for "double click" which emulates
a double click. The two clicks are so close together that with libinput
heuristics it looks like a worn-out button and triggers debouncing
functionality.
This commit adds support for the RollerMouse Free 2 and RollerMouse
Re:d.
Fixeslibinput/libinput#204
(cherry picked from commit fc029e3fb5)
As with some other convertible devices, the keyboard is disabled by the system when the device is in tablet mode.
The volume control keys on the side of the unit are not, but still appear from the keyboard to the system.
Don't disable the keyboard when in tablet mode.
Tested working.
(cherry picked from commit eb0b48151f)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/x86_64-linux-gnu/libinput/libinput-measure-fuzz", line 464, in <module>
main(sys.argv)
File "/usr/lib/x86_64-linux-gnu/libinput/libinput-measure-fuzz", line 458, in main
print('Error: {}'.format(e.message))
AttributeError: 'InvalidConfigurationError' object has no attribute 'message'
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>:
(cherry picked from commit a904738730)
It's missing INPUT_PROP_BUTTONPAD but working kernel drivers prove to be
elusive. Meanwhile, add a quirk here that force-enables this bit.
Fixes#177
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 0cd65cf336)
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.
(cherry picked from commit ad50a94789)
test/test-misc.c:1065:28: warning: Value stored to 't' during its
initialization is never read
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
alpine:latest which is now the default image doesn't docker installed by
default. apk add docker results in failures
Warning: failed to get default registry endpoint from daemon
last time all this worked was when we defaulted to the docker:stable image,
see https://gitlab.freedesktop.org/libinput/libinput/-/jobs/8316
Let's switch back to that and move on with our lives.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Executing the script as illustrated sends it to nowhere (localhost maybe?),
prepending docker:// makes it recognize the hostname correctly and actually
upload it to gitlab.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a more flexible approach than adding a model flag and the C code to
just call libevdev_disable_event_code(). There's a risk users will think this
is is a configuration API but there are some devices out there (e.g. the
Microsoft Sculpt mouse) that need a more generic solution.
Case in point: the Sculpt mouse insists on holding BTN_SIDE down at all times.
We cannot ship any quirks for that device because we only have the receiver's
generic VID/PID. So a local override is required, but we might as well make
that one generic enough to catch other devices too in the future.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Log if we use a non-default click angle setting, makes it easier to debug
this. The condition to add the log was a bit unwieldly to read, so this also
factors out the property names to temporary variables.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
At least on MacBooks, the host emulates two clicks 8ms apart in response to a
doubletap. Those clicks are filtered by our debouncing code.
Since these are emulated devices anyway and by definition cannot have a stuck
button, let's tag them so we don't enable the debouncing code. If the button
of the physical device is stuck, that's a problem that needs to be fixed in
the host system.
Fixes#158
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The POSIX version of basename modifies the string (and therefore crashes
on static strings), so use safe_strdup before calling it.
glibc provides a POSIX version when libgen.h is included.
FreeBSD 12 provides a POSIX version when nothing is included, which was
causing a segfault.
Using the POSIX version correctly is the right way to avoid any such issues.
If a 2fg scroll motion starts with both fingers in the bottom button area and
one finger moves into the main area before the other, we used to send motion
events for that finger. Once the second finger moved into the main area the
scroll was detected correctly but by then the cursor may have moved out of the
intended focus area.
We have two transitions where we may start sending motion events: when we move
out of the bottom area and when the finger moves by more than 5mm within the
button area. In both cases, check for any touches that are in the
bottom area and started at the 'same' time as our moving touch. Mark those as
'moved' to release them for gestures so we get the right finger count and
axis/gesture events instead of just motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's one state with a name longer than allocated but it's virtually never
triggered so let's just ignore the misalignment in that case.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The shape of the average hand implies that two fingers down within the lower
thumb area (the bottom few mm of the touchpad) cannot be thumbs without
significant contortion. So let's not mark them as thumb.
Fixes#126
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We rely on the udev keyboard builtin to set the fuzz but that builtin isn't
run during udevadm test. So running sudo udevadm test shows the LIBINPUT_FUZZ
properties the first time round (still set from boot), but not the second time.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
tp_detect_thumb_while_moving() assumes that of the 2 fingers down, at least
one must be in TOUCH_UPDATE, otherwise we wouldn't have a speed to analyze for
thumb.
If a touch starts in HOVERING and exceeds the speed limit, we were previously
increasing the 'exceeded count'. This later leads to an assert() in
tp_detect_thumb_while_moving() when the second finger comes down because
although we have multiple fingers, none of them are in TOUCH_UPDATE.
This only happens when fingers 2 and 3 come down in the same event frame,
because then we have nfingers_down at 2 (the hovering one doesn't count) but
we don't yet have a finger in TOUCH_UPDATE.
Fix this twofold, first by now calculating the speed on anything but
TOUCH_UPDATE. And second by force-resetting the speed count on
TOUCH_BEGIN/TOUCH_END so we definitely cover all the hover transitions.
Fixes#150
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When we disable the touch device, any existing touches should be cancelled,
not just released.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>