Compositors will need to keep provide virtual devices of supported
generic device types (pointer, keyboard, touch etc). Events from each
device capable of a certain device type abstraction should be combined
as if it was only one device.
For key and button events this means counting presses of every key or
button. With this patch, libinput provides two new API for doing just
this; libinput_event_pointer_get_seat_button_count() and
libinput_event_keyboard_get_seat_key_count().
With these functions, a compositor can sort out what key or button events
that should be ignored for a virtual device. This could for example
look like:
event = libinput_get_event(libinput);
switch (libinput_event_get_type(event)) {
...
case LIBINPUT_EVENT_POINTER_BUTTON:
device = libinput_event_get_device(event);
seat = libinput_event_get_seat(device);
pevent = libinput_event_get_pointer_event(event);
if (libinput_event_pointer_get_button_state(pevent) &&
libinput_event_pointer_get_seat_button_count(pevent) == 1)
notify_pointer_button_press(seat);
else if (libinput_event_pointer_get_button_state(pevent) &&
libinput_event_pointer_get_seat_button_count(pevent) == 0)
notify_pointer_button_release(seat);
break;
...
}
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput currently handles 16 per device touch points. Test that we
behave as expected when a device has an even higher number of active
touch points.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
When the kernel sends multiple touch down or touch up for the same slot
in a row, ignore any such subsequent event ensuring libinput always
produces 1 x touch down -> [n x touch motion] -> 1 x touch up event
series.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Don't have a hard coded slot array size; instead allocate the array
needed according to the abs info reported by either libmtdev or libevdev.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
For logging when things happen which should not happen. We may want to do
something more fancy in the future but for now this suffices.
Modelled after log_bug in libevdev.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Looks a bit excessive given how simple the base is but hey, we don't want to
ever break that bit. That'd be embarrassing.
And while we're at it make sure that the 'wrong' event getters return NULL for
each event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
A few functions only work on the base event but once we've converted to the
target event we can't go back. Casting works for now but that would expose
internal ABI.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
And redirect the log to stdout. libinput logs to stderr by default, but if
we're running with --verbose we want all msgs on the same stream.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Remove compiler warning about signed/unsigned comparison. And while we're at
it, rename i to _i in the macro to avoid name clashes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
In litest.h it was called litest_button_click() while in litest.c
litest_click(); update the definition to be the same as the declaration.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Instead of having a test device which only purpose is to test absolute
coordinate transformation, use the litest_create_device_with_overrides()
API to create a specially crafted wacom touch device with high
resolution.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
For specific tests we need something that e.g. looks like a touchpad, but has
a different name, a different number of slots, etc. In this case, the
following code will do exactly that:
struct input_absinfo overrides[] = {
{ .value = ABS_MT_SLOT, .minimum = 0, .maximum = 100 },
{ .value = -1 },
};
litest_create_device_with_overrides(LITEST_SYNAPTICS_CLICKPAD,
NULL, NULL, &overrides, NULL);
For general event codes, overrides can only add to the set of events, they
can't remove.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Most of the test devices now are static descriptions anyway, make them fully
static now, including for touch events.
Switch the synaptics device now as example, the rest comes later for easier
patch review.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Both functions accept a series of event types/codes tuples, terminated by -1.
For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is used
as a property to enable.
The _abs function als takes an array of absinfo, with absinfo.value
determining the axis to change. If none are given, abs axes are initialized
with default settings.
Both functions abort on failure, so the caller does not need to check the
return value.
Example code for creating a rel device:
struct libevdev_uinput *uinput;
struct input_id id = { ... };
uinput = litest_create_uinput_device("foo", &id,
EV_REL, REL_X,
EV_REL, REL_Y,
EV_KEY, BTN_LEFT,
INPUT_PROP_MAX, INPUT_PROP_BUTTONPAD,
-1);
libevdev_uinput_write_event(uinput, EV_REL, REL_X, -1);
libevdev_uinput_write_event(uinput, EV_SYN, SYN_REPORT, 0);
...
libevdev_uinput_destroy(uinput);
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Even though libinput uses no C++, it should be supported to include
libinput.h from C++. Therefore a build test ensuring this possibility
exist. However, since we can not conditionally invoke AC_PROG_CXX
in configure.ac just do it always.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Still leaving the driver itself in place for removal later, but only
initialize the new driver now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On a clickpad, one finger has be on the trackpad to trigger a physical button
press. For drag and drop, we still want motion events though when a second
finger is down.
This patch adds finger-pinning. If the touchpad is pressed, the pressing
finger is "pinned" and ignored for further motion events. A second finger may
then be used to drag.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Unused at the moment, but will be used later to determine if a finger should
trigger motion events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
On touchpads without physical buttons, the number of fingers on the touchpad
at the time the physical click happens decides the button type. 1/2/3 fingers
is handled left/right/middle.
We also swallow the motion event on the actual click event, this reduces
erroneous motion events by a bit. More processing is needed here though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This enables two-finger scrolling and two- and three-finger tapping on a
single-touch touchpad if BTN_TOOL_DOUBLETAP and BTN_TOOL_TRIPLETAP is set.
These require a bit of special processing:
BTN_TOUCH is set with the first finger down, but somewhat randomly unset and
re-set when switching between the various BTN_TOOL_*TAP values.
BTN_TOOL_<N>TAP is only set for N fingers down, thus a double->triple move
will see a release for DOUBLETAP and a press for TRIPLETAP. This may happen in
the same event, or across two consecutive events.
This patch adds a fake_touches mask to the touchpad struct. The mask is set
for each matching BTN_* event and used to count the number of expected
fake touchpoints. From that we begin/end the number of actual touchpoints
required. Fake touchpoints take their x/y coordinates from the first
touchpoint, which reads ABS_X/ABS_Y.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Touchpads without ABS_MT_SLOT create 5 slots by default (for up to QUINTTAP)
and ABS_X/Y is mapped to the 0-slot touchpoint. This commit adds handling for
a single finger, no BTN_TOOL_DOUBLETAP or similar is being processed yet.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
