Sending separate axis events instead of one unified events is limiting,
especially when simultaneously scrolling in both directions and the caller
tries to implement kinetic scrolling.
Take a page from the tablet-support branch and instead implement the axis
event as a generic event that can contain multiple axes simultaneously.
Right now we only have two (scroll) axes and we could easily just check both
for non-zero values. If we want to allow further axes in the future, we need
a check whether an axis is set in an event, that's what
libinput_event_pointer_has_axis to scroll events() is for.
We also need the mask to notify of a scroll stop event, which could otherwise
be confused as a vertical-only or horizontal-only event.
This is an API and ABI break.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of using a hard coded mouse DPI value, we query it from udev.
If it's not present or the property is obviously broken we fall back
to default.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This adds "struct ratelimit" and "ratelimit_test()". It's a very simple
rate-limit helper modeled after Linux' lib/ratelimit.c by Dave Young.
This comes in handy to limit log-messages in possible busy loops etc..
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current conditions result in _elem being assigned _arr[i] before the
condition is checked. This is fine since we then break from the loop and don't
access it anyway, but it makes Coverity unhappy.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The kernel may send a 'release' event without ever having sent a key
'pressed' event in case the key was pressed before libinput was
initiated. Ignore these events so that we always guarantee a release
event always comes after a pressed event for any given key or button.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Makes it possible to use from the touchpad code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
For those whose eyes struggle to focus on 5 zeros in a row, or those just sick
of forgetting one zero and wondering why things don't work.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fixed point numbers can easily overflow, and double to fixed point
conversion is lossy. Use floating point (double) where fixed point
numbers where previously used and remove the li_fixed_t type.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
Instead of having the user manage added and removed fd's as well as the
fd used for creating evdev devices, introduce a libinput object that
itself has an epoll fd.
The user no longer manages multiple fd's per libinput instance, but
instead handles one fd, dispatches libinput when data is available, then
reading events using libinput_get_event().
libinput_event's are now per libinstance, but divided into categories.
So far the only category is device events. Device events are categorized
by the presence of a non-NULL device pointer in the event.
The current API usage should look like:
struct libinput libinput = ...;
struct libinput_event *event;
if (libinput_dispatch(libinput) != 0)
return -1;
while ((event = libinput_get_event(libinput))) {
if (event->device)
process_device_event(event);
free(event);
}
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
