Older kernels don't have UI_GET_SYSNAME, and upstream is adding a few more
ioctls to the uinput code. So ship the header we're using to avoid compilation
errors.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Better protection against buffer overflow, though by the time someone
is manipulating your sysfs, libevdev is unlikely to be the biggest worry.
Slight change in functionality: before we checked the timestamp of
/sys/devices/virtual/input/inputXYZ before looking at /inputXYZ/name, now we
just check the name file for the timestamp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Drop the rest of the stack trace, we know whenever check calls this we get a
valgrind error if sevp in timer_create(2) is NULL.
https://bugs.freedesktop.org/show_bug.cgi?id=79921
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The global log handler isn't a good choice for a low-level library. In the
caser of the X server, both evdev and synaptics are now using the libevdev but
are loaded from the same server process. Thus, there's only one log handler,
but evdev and synaptics don't talk to each other (a bit childish, I know).
Add a per-device log handler that overrides the global log handler, and fall
back to the global log handler if no device log handler is set. The log
macros take care of that automatically, especially as we can't do per-device
log handlers for the uinput code.
Note that we use the same struct for the global and device logging, so in each
instance one of the two function pointers is NULL. Suicide triggers are in
place in case we mess that up.
This also makes libevdev_new_from_fd() a bit less useful since we can't set
the log handler beforehand.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
These macros come from systemd, but CC_CHECK_CFLAGS_SILENT was removed in
systemd commit eb2e280f9c59b66965c9316eadc4c113a13ca744, breaking some of
them.
CC_FLAG_VISIBILITY doesn't need to require CC_CHECK_WERROR because
CC_CHECK_FLAG_APPEND always append -Werror anyway. Which kinda brings into
question why we have CC_CHECK_WERROR in the first place, but whavever.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Triggered by the tests when run as non-root. Simply ignore any attempt to
destroy a NULL device, which also matches the behaviour of libevdev_free().
Reported-by: Andreas Radke <a.radke@arcor.de>
Reviewed-by: Daniel Martin <consume.noise@gmail.com>
Tested-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The tests create devices on the host system, avoid running them in parallel to
avoid interference between the test devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
ioctl points to uninitialized bytes - correct but we didn't use those anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
The kernel ring buffer drops all events on SYN_DROPPED, but then continues to
fill up again. So by the time we read the events, the kernel's client buffer is
essentially like this:
SYN_DROPPED, ev1, ev2, ev3, ...., evN
The kernel's device state represents the device after evN, and that is what
the ioctls return. For EV_KEY, EV_SND, EV_LED and EV_SW the kernel removes
potential duplicates from the client buffer [1], it doesn't do so for EV_ABS.
So we can't actually sync while there are events on the wire because the
events represent an earlier state. So simply discard all events in the kernel
buffer, synchronize, and then start processing again. We lose some granularity
but at least the events are correct.
[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/input/evdev.c?id=483180281f0ac60d1138710eb21f4b9961901294
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
dev2 by definition doesn't initialize, we expect it to fail. Freeing it after
is a bad idea. Also initialize it to NULL so this is a bit more obvious now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
A max of num_slots -1 caused the first MT_SLOT event to be skipped, leading to
wrong tracking IDs in the slots.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch starts and terminates while in SYN_DROPPED, the tracking ID appears
to stay at -1, but the other axes may update. We need to pass these on to the
client since the kernel may buffer the next event with the same value
otherwise. Note this in the documentation so that client's don't create touch
points based on out-of-touchpoint updates.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
This doesn't really do much here, but strictly speaking: if asprintf returns
-1, devnode is undefined. So reset it to NULL to avoid weird pointers. And
also free the rest of the names if we ever have more than one device - which
also shouldn't happen.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
test-libevdev-events.c: In function ‘test_double_syn_dropped_event’:
test-libevdev-events.c:187:2: warning: ignoring return value of ‘read’,
declared with attribute warn_unused_result [-Wunused-result]
This read was there to drain events even when there shouldn't be any on the
pipe anyway. So let's add an assert.
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>
