Comment 11 for bug 1238417

The problem seems to be a limitation of the kernel multitouch type B protocol compounded with the fact that the autopilot fake input device never changes the value of its pressure axis (it's always 400).

In the type B protocol it seems that you're not able to query the current value of an MT axis of a specific slot (you can specify an axis but not a slot in the iotcl(..., EVIOCGABS..) command). And the touch device sends only what has changed in its state intead of the whole state (i.e. the value of all axes, like x, y, pressure, etc).

Since the pressure of the autopilot fake touch device is always 400, that device informs on its first event that the pressure value is 400 and never again mention it (because it never changes). This is fine if unity8 gets that first event. But if you restart it, unity8 won't know about that pressure value and will assume 0 (zero). But a zero or negative pressure means that the finger is hovering, and thus unity8 starts interpreting that the touch point from the autopilot device is hovering and the UI doesn't respond to a hovering touch (like an unpressed mouse pointer moving around the screen).

android-input shouldn't assume any value for the pressure. Instead it should consider that axis as as effectively non-existent (and therefore not use it) until it's informed about its value (i.e., once it changes). I will do that change.

But from the autopilot side things can be improved and fixed by:
 - either disabling the pressure axis (as you never change it anyway)
 - or properly fake it by changing it throughout the touch lifetime (low-to-high in the beginning and high-to-low in the end)

NB: when I say "unity8" I mean the android-input code in mir that runs in the unity8 process.