eventcomm: drop calculation of slot offset

The kernel guarantees slots start at 0

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
(cherry picked from commit 5b7e1726369d4973859996f225bec743c2e21288)
eventcomm: drop assumption of non-zero slot offset

The kernel guarantees this is always 0

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Avoid erroneously handling two touchpoints in the same slot

If a slot's ABS_MT_TRACKING_ID event was received during SYN_DROPPED, the
driver isn't aware that a touchpoint has started or ended in that slot. When
the next ABS_MT_TRACKING_ID event arrives, the driver would unconditionally
close or open a new touchpoint. This could lead to two or more touchpoints
being opened in the same slot, the first of which is never terminated.
Or it could lead to a touchpoint being terminated that was never opened.

The event sequences that trigger this are:
    ABS_MT_TRACKING_ID 83
    ABS_MT_TRACKING_ID -1
    SYN_DROPPED             // new touchpoint started here
    ABS_MT_TRACKING_ID -1

and

    ABS_MT_TRACKING_ID 83
    SYN_DROPPED             // touchpoint ended here
    ABS_MT_TRACKING_ID 84
    ABS_MT_TRACKING_ID -1

We don't properly handle SYN_DROPPED, but we can avoid this by only starting a
new touchpoint when we transition between -1 and a valid tracking ID.

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

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Dualhead resolution patch
2-finger tap patch
False release filtering patch