This cannot ever be unset on any real device, but coverity is unhappy and
that's not making me happy.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Clang doesn't support variable length arrays inside a struct so we could
either make our life complicated or just assume no-one is using more than 256
slots and hard-code that. Let's go for the easy solution until someone
notices.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Where at least one touch ends during SYN_DROPPED, we send out two event
frames: one with all applicable touch sequences ending (tracking id -1) and
the second one with the whole device state *and* the applicable touch
sequences starting (tracking id != -1).

This requires us to also update the BTN_TOOL_ bits correctly so that they are
correct after the first frame. For that we count the number of previously
known touches and send a 0 event for the matching BTN_TOOL_ bit, together with
a 1 event for the currently known touches.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

The previous event processing had subtle issues with touches stopping during
SYN_DROPPED. All of the device state was processed in the same frame, but if
any touch changed tracking ID during SYN_DROPPED, an inserted SYN_REPORT
resulted in a weird split of events:
- the first frame had all key/sw/abs updates including those slots that
  changed tracking ID, but not the ones that were fully terminated.
- the second frame had only the slots states for newly started touches **and**
  the slot state for touches terminated during SYN_DROPPED but not restarted.

In other words, where three fingers were on the touchpad and slot 0 was lifted
and put down again and slot 1 was lifted but *not* put down again, our frames
contained:
- frame 1: terminate slot 0, BTN_TOOL_TRIPLETAP 0, BTN_TOOL_DOUBLETAP 1
- frame 2: start slot 0, terminate slot 1

Where there was no touch changing tracking ID, only one frame was generated.
The BTN_TOOL updates were buggy, they may not match the number of fingers down
as seen on a frame-by-frame basis. This triggered libinput bug
https://gitlab.freedesktop.org/libinput/libinput/issues/422

This patch changes the above example to
- frame 1: terminate slot 0, terminate slot 1
- frame 2: start slot 0, BTN_TOOL_TRIPLETAP 0, BTN_TOOL_DOUBLETAP 1

Notably, the first frame no longer contains the BTN_TOOL bits. This patch is
one of two, the BTN_TOOL sync bits are part of a follow-up patch.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Go from:
  if (a != b)
     continue;
  foo;

to:
  if (a == b) {
      foo;
  }

Basically just an indentation change after the condition inversion, makes the
follow-up patch easier to review.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

No functional changes.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

In the near future, we will need to handle slot termination *before* any other
state synchronization. So let's start splitting things up.

This is functionally equivalent though dropping the need_tracking_id_changes
variable means we run through all slots now to check if we need to terminate
one of them. Given the normal number of slots on a device and that this should
only ever run very rarely anyway... meh.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Keep a better state of each touch before/after the SYN_DROPPED. Most of this
is currently unused, it's functionally the same as before but the new code
serves to increase readability and it can be passed around easier this way.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>