Mir

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

Bug #1238417 reported by Christopher Lee
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Autopilot
Invalid
Undecided
Unassigned
Mir
Fix Released
High
Daniel d'Andrada
mir (Ubuntu)
Fix Released
High
Unassigned
unity8 (Ubuntu)
Vivid
Fix Released
Undecided
Michał Sawicz

Bug Description

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

Brief:
In an autopilot test if you have a touch device object, launch unity, do some tapping/dragging, stop unity, start it again the same created device will have no effect on the new unity.
(i.e. attempt to swipe greeter will fail)

* To reproduce using python shell:

(Have 2 terminals, both on the device(ssh/adb shell); one for python shell the other for starting/stopping unity)

1. Make sure unity8 is running on the device

2. In the python shell execute:
from autopilot.input import Touch
touch = Touch.create()
touch.drag(717,669,144,669) # assuming maguro, but some movement will happen regardless

3. You will see the greeter disappear/dash move/some movement.

4. Restart unity (without restarting the python shell)
stop unity8
start unity8

5. Back in the python terminal, re-execute the drag:
touch.drag(717,669,144,669)

6. Nothing will happen to unity (no greeter movement etc.)

7. (Work around) Re-create the device to get movement back (in python terminal):
from autopilot.input import _uinput
_uinput._touch_device = _uinput.create_touch_device()
touch.drag(717,669,144,669) # Movement happens again.

7b. Or you can kill the python shell and do the pythno steps from scratch, but that just does `_uinput.create_touch_device()` again

* To reproduce using autopilot:
Any test after the first fails due to input not being processed by the evdev device that was created before unity8 is started.

# Run at least 2 tests:
$ autopilot run -v unity8.shell.tests.test_hud.TestHud.test_show_hud_appears unity8.shell.tests.test_hud.TestHud.test_hide_hud_dragging

The second test will fail due to failing to swipe the greeter away.

* Extra details:
If I add extra logging:
$ initctl set-env MIR_SERVER_INPUT_REPORT=log
$ initctl set-env MIR_SERVER_LEGACY_INPUT_REPORT=log

I see details in the logs (~/.cache/upstart/unity8.log) when the drag is attempted:
...
[II, input] Received event (when, type, code, value) from kernel: (1381464336335967000ns, 3, 54, 621)
[II, input] Received event (when, type, code, value) from kernel: (1381464336335967000ns, 0, 0, 0)
[II, input] Published motion event (seq_id, event_time) to fd 65: (305, 1381464336335967000)
[II, input] Received event finished (seq_id) from fd 65: 305
...

But nothing happens on the screen (I am able to manually swipe the screen).

* Workaround

A work around is to add this to the test setup:
        from autopilot.input import _uinput
        _uinput._touch_device = _uinput.create_touch_device()

Which forces the creation of a new device for this specific test run and instance of unity.

related https://bugs.launchpad.net/mir/+bug/1237784

Related branches

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir:
importance: Critical → High
status: Confirmed → New
Revision history for this message
Thomi Richards (thomir-deactivatedaccount) wrote :

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.

Changed in mir:
importance: High → Critical
status: New → Confirmed
Revision history for this message
Michał Sawicz (saviq) wrote :

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.

kevin gunn (kgunn72)
Changed in mir:
status: Confirmed → Fix Committed
Revision history for this message
Michał Sawicz (saviq) wrote :

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

Changed in mir:
status: Fix Committed → Confirmed
Changed in unity8:
assignee: nobody → Michał Sawicz (saviq)
status: New → Fix Committed
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

racarr / dandrader,

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

Changed in mir:
status: Confirmed → Incomplete
tags: added: doesnt-need-test
Revision history for this message
Michał Sawicz (saviq) wrote :

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.

Changed in unity8:
status: Fix Committed → Fix Released
Revision history for this message
Michał Sawicz (saviq) wrote :

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...

Revision history for this message
Michał Sawicz (saviq) wrote :

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.

kevin gunn (kgunn72)
description: updated
Changed in autopilot:
status: New → Invalid
Revision history for this message
Leo Arias (elopio) wrote :

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

Changed in mir:
assignee: nobody → Daniel d'Andrada (dandrader)
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

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).

Changed in mir:
status: Incomplete → In Progress
Changed in mir:
milestone: none → 0.1.5
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

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.

Revision history for this message
Daniel d'Andrada (dandrader) wrote :

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

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in mir:
status: In Progress → Fix Committed
Changed in mir:
importance: Critical → High
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

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

Changed in mir (Ubuntu):
importance: Undecided → High
status: New → Fix Released
Changed in mir:
status: Fix Committed → Fix Released
Michał Sawicz (saviq)
Changed in unity8 (Ubuntu Vivid):
assignee: nobody → Michał Sawicz (saviq)
status: New → Fix Released
no longer affects: unity8
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.