delta/libevdev.git/libevdev, branch libevdev-1.2

Drain all events before synchronizing after SYN_DROPPED

2014-04-23T22:17:01+00:00

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

Move read_more_events() up in the file

2014-04-23T22:17:01+00:00

No functional change

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Actually make the min queue size a minimum

2014-04-10T01:00:56+00:00

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Clarify what signal-safe means

2014-04-10T01:00:56+00:00

Just in case...

Signed-off-by: Peter Hutterer

Calling libevdev_enable_event_code() overwrites EV_ABS/EV_REP values

2014-04-07T23:01:56+00:00

Document this behaviour

Signed-off-by: Peter Hutterer

Split the SYN_DROPPED page into a few sections

2014-04-07T04:26:31+00:00

Signed-off-by: Peter Hutterer

Fix a typo, add a @ref in the documentation

2014-04-07T04:23:21+00:00

Signed-off-by: Peter Hutterer

Drop invalid ABS_MT_TRACKING_ID changes

2014-04-03T03:31:40+00:00

Follow-up to
commit 41334b5b40cd5456f5f584b55d8888aaafa1f26e
Author: Peter Hutterer 
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
66fee1bec4c4b021e1b54adcd775cf6e2aa84869.

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Move slot-related initialization down

2014-04-03T03:31:39+00:00

No real effects, but improves readability

Signed-off-by: Peter Hutterer 
Reviewed-by: Benjamin Tissoires

Drop hardcoded MAX_SLOTS in favour of pre-allocated memory

2014-04-03T03:30:49+00:00

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 41334b5b40cd5456f5f584b55d8888aaafa1f26e
Author: Peter Hutterer 
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 
Reviewed-by: Benjamin Tissoires