Follow-up to
commit 41334b5b40
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Mar 6 11:54:00 2014 +1000
If the tracking ID changes during SYN_DROPPED, terminate the touch first
In normal mode, we may get double tracking ID events in the same slot, but
only if we either have a user-generated event sequence (uinput) or a malicious
device that tries to send data on a slot > dev->num_slots.
Since the client is unlikely to be able to handle these events, discard the
ABS_MT_TRACKING_ID completely. This is a bug somewhere in the stack, so
complain and hobble on along.
Note: the kernel doesn't allow that, but we cap to num_slots anyway, see
66fee1bec4.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
No real effects, but improves readability
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
We can't allocate in sync_mt_state since it may be called in the signal
handler. So pre-allocate based on the device's number of slots, store that in
the libevdev struct and use it for the sync process.
This fixes a remaining bug with the handling of ABS_MT_TRACKING_ID. If a
device had > MAX_SLOTS and a slot above that limit would start or stop during
a SYN_DROPPED event, the slot would not be synced, and a subsequent touch in
that slot may double-terminate or double-open a touchpoint in the client.
For the effects of that see
commit 41334b5b40
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Mar 6 11:54:00 2014 +1000
If the tracking ID changes during SYN_DROPPED, terminate the touch first
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
For protocol A devices we won't get the information from the kernel anyway and
we expect all axes to be updated in the next event.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The EVICOCGMTSLOTS ioctl returns all slot values for the requested code or an
error code, it doesn't return the number of bytes successfully transferred.
Thus all values in the input array are always defined (on success), we don't
need to memset it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Triggered with -O3
../libevdev/libevdev.c: In function ‘libevdev_get_event_value’:
../libevdev/libevdev.c:1112:6: warning: ‘value’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Triggered with -O
../libevdev/libevdev.c: In function ‘libevdev_has_event_code’:
../libevdev/libevdev-util.h:58:20: warning: ‘mask’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
Optimisation clearly shuffles things around here: in the code, if no max is
found, we return -1 and bail out before we access mask.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If a client doesn't sync expliciltly, make sure we sanitize the events when we
update the internal library state.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Most clients can't deal with tracking ID changes unless a -1 is sent first. So
if we notice that the tracking ID has changed during the sync process, send a
set of ABS_MT_TRACKING_ID -1 events for each of those, then send the rest of
the events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If multiple slots have changed during the sync handling, the client must be
re-set to the current slot before continuing with normal events.
Signed-off-by: Benjamin Tissoires <btissoir@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Devices with ABS_MT_SLOT-1 are fake MT devices, they merely overlap the
axis range but don't actually provide slots. The EVIOCGABS ioctl won't work to
retrieve the current value - the kernel does not store values for those axes
and the return value is always 0.
Thus, simply ignore those axes for fake MT devices and instead rely on the
next event to update the caller with the correct state for each axis.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
A malicious device may announce N slots but then send a slot index >= N. The
slot state is almost always allocated (definitely the case in libevdev and
true for most callers), so providing a slot number higher than the announced
maximum is likely to lead to invalid dereferences. Don't allow that.
Likewise, don't allow negative slot numbers.
Note that the kernel filters these events anyway, the only way to trigger this
is to change the device fd to something outside the kernel's control.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Changes the algorithm: before we'd ioctl all axes for all slots, then generate
events for all slots one-by-one.
Now we ioctl the slot state for each axis, copy the new event value into
the device and mark a bitfield that we've updated the value. Then loop through
the slots and generate events where changed.
Side-effect: this makes it easy to check if anything in the slot has updated,
so we can skip empty slot events during sync.
Min memory requirement for the state storage was:
MAX_SLOTS * (ABS_MT_CNT + 1) * sizeof(int) = 1980
Min memory requirement now:
(ABS_MT_CNT + 1) * sizeof(int) + NLONGS((MAX_SLOTS * ABS_MT_CNT) bits) = 544
This is sigsafe code, so this was stack memory. Reducing the requirement
allows us to up MAX_SLOTS in the future if we need to.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Instead of relying on a static MAX_SLOTS array, allocated it based on the
number of slots we have on the device. The previous checks for MAX_SLOTS were
incomplete, causing out-of-bound reads.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device has more than MAX_SLOTS slots, we'd run out-of-bounds on the sync
array. This function is sig-safe, so we can't alloc here, merely limit the
access.
Reported-by: Jonas Ådahl <jadahl@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
If a device is assigned a name, uniq and/or phys before calling
libevdev_set_fd(), those values would leak.
Change the default alloc to calloc, so name, uniq, and phys are initialized to
zero before we call libevdev_reset
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a message is higher than the current priority, filter it. And add a few
tests that the priority is handled the way it should.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
If the first event after a completed device sync is a SYN_DROPPED, warn the
user that they're not fast enough handling this device.
The test for this is rather complicated since we can't write SYN_DROPPED
through uinput so we have to juggle the device fd and a pipe and switch
between the two at the right time (taking into account that libevdev will read
events from the fd whenever it can).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure we have a queue that is at least large enough to do a full sync
after a SYN_DROPPED, plus store a few extra events in case some came in after
the sync.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Some devices (PS3 sixaxis controller) merely have a bunch of axes, without the
semantic information that linux/input.h requires. For those, the ABS_MT range
may be merely another axis, not the special range that we need to treat it
with.
Use a simple heuristic: if ABS_MT_SLOT - 1 is enabled, don't treat ABS_MT as
multitouch axes. The ABS_MT_SLOT - 1 axis is not used for a real axis.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
We shouldn't have a separate API for that, the whole point of libevdev is to
abstract the quirkyness of the ioctls into a common interface. So let's
export the two EV_REP values through libevdev_get_event_value.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
libevdev.c:921:134: warning: ISO C does not allow extra ';' outside of a
function [-Wpedantic]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
There's a gap in the range between EV_SW and EV_LED. Trying to enable one
of those bits will segfault.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Set the bit during device reset and make sure that if we're checking
for the event type we always return true for EV_SYN.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
The documentation already says that, make it happen.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
libevdev_set_fd may fail at a number of points. If it does, it errors out but does nothing
otherwise. Thus, a client may call set_fd again for the same struct but on a different fd and have
it succeed. Depending on when set_fd bailed out the first time, some fields may already be set.
Thus, reset the whole struct at set_fd time to make sure we're nulled out appropriately.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Add a new flag for "initialized" and separate that from the fd logic. This way,
we can call libevdev_change_fd(dev, -1) to signal that the current fd should be
dropped.
Otherwise libevdev can't be told to release the fd and always keeps a reference
to it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Rename from LIBEVDEV_READ_foo to LIBEVDEV_READ_FLAG_foo to differentiate
better from LIBEVDEV_READ_STATUS_foo.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Improved readability in callers, changing magic numbers 0 and 1 to
rc = libevdev_next_event();
if (rc == LIBEVDEV_READ_STATUS_SUCCESS)
do_something();
else if (rc == LIBEVDEV_READ_STATUS_SYNC)
do_something_else()
No ABI changes, the enum values are the previously documented values,
this is just a readability improvement.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Another look at the current API showed some inconsistencies, rectified
in this commit:
libevdev_kernel_*: modify the underlying kernel device
libevdev_event_type_*: something with an event type
libevdev_event_code_*: something with an event code
libevdev_event_*: struct input_event-related functions (i.e. not device-related)
libevdev_property_*: something with a property
libevdev_*: anything applying to a device
Hopefully that's the last API change. Current symbols deprecated and aliased.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The logging we do use atm inside the library is largely
to spot application errors. Log that to stderr by default so
it doesn't get lost.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
There's no need to have separate logging function for each device created.
More likely, libevdev will be hooked up once into the logging system and
expected to deal with it.
Plus, this allows us to log from the uinput code where we don't
have the context anyway.
Requires a rename to libevdev_set_log_function to avoid ABI breaks, and
while we're breaking the ABI make the logging function more sophisticated
to log line, number, etc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
All other functions that check the fd for validity return EBADF, which also makes it
easier to debug if the actual device goes away.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
From errno(3):
ENOMEM Not enough space (POSIX.1)
ENOSPC No space left on device (POSIX.1)
when we run out memory the reason is a failed malloc, for which ENOMEM
seems more appropriate.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The ioctls return the number of bytes copied into the destination, so just
copy them into the device state instead of individually flipping bits.
For easier review: rc is the return value of the EVIOCG* ioctl, which is
the number of bytes copied.
state variables must be initialized to 0 now, in case the kernel's FOO_MAX
is smaller than libevdev's FOO_MAX. If not initialized to 0, the bytes
between the two max values is undefined and we may end up generating bogus
events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
LED_MAX, KEY_MAX, ABS_MT_MAX, etc. are all valid event codes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
