Unity does not process events from evdev device created before unity is restarted (autopilot tests)

Dropped to High. We reserve critical for "my desktop/phone is unusable".

Well, we can't run the unity8 test suite until this is fixed, so I'd say this deserving of that importance. It's also been confirmed by more than one person.

I can confirm this is a problem, fortunately Chris found a workaround, but it would still be good to get to the bottom of this.

This is not Fix committed, unfortunately we still need a fix *somewhere* - only a workaround is committed.

racarr / dandrader,

Can you triage this? Any idea if Mir's doing something wrong?

This has crept up again in lp:~allanlesage/unity8/indicator-stubs - all the tests *after* the few added ones are failing due to input disappearing.

I'm trying a workaround again, but we should really look into what's happening. Can someone please start tracing the input from autopilot until it reaches unity8 - and where is it lost in case it is?

To not have to run the whole unity8 suite every time, it should be enough to remove the workaround in unity8:tests/autopilot/unity8/shell/__init__.py:146 - after that only the first test ever in an autopilot run will work.

I *feel* like this got unearthed by the above branch simply because of the number of tests - with the workaround we're creating a new input device for every test - and we don't really know if they're destroyed, do we? I'm trying a del before creating the new device to see if my suspicion has any grounds...

OK, del'ing the touch device doesn't help, but that might simply be because the garbage collector might not have really kicked in yet and the input devices simply still linger.

We found that the device needs to be closed, not deleted. See bug #1267600, already fixed.

For some reason, after unity8 is restarted, touch events coming from the fake device are dispatched to him as hover events (AMOTION_EVENT_ACTION_HOVER_ENTER, _HOVER_MOVE and _HOVER_EXIT) instead of regular ones (AMOTION_EVENT_ACTION_DOWN, _MOVE and _UP).

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.

BTW, thanks for the bug decription. The steps using the python shell were very helpful

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

mir (0.1.4+14.04.20140204-0ubuntu1) trusty; urgency=medium