Activity log for bug #1620553

Date Who What changed Old value New value Message
2016-09-06 10:17:22 Andrea Bernabei bug added bug
2016-09-06 10:23:51 Andrea Bernabei attachment added video showing the sympthoms https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1620553/+attachment/4735390/+files/video_2016-09-06_10-48-11.mov
2016-09-06 10:24:16 Andrea Bernabei description Krillin, rc-proposed/bq_aquaris.en r422 Description: All at once taps have become incredibly delayed, by 1 or 2 secs. Gestures still work ok, no delay there. Swiping the greeter -> no delay. Tapping numbers to input code on the greeter --> 2 secs delay. Even though both are parts of unity8. So it doesn't seem to only be a problem of unity8 clients, but also unity8 itself. I have no idea why horizontal/vertical swipes would be unaffected, though. The virtual keyboard is also completely unusable because of the huge delay that each tap has. Also noticed that the vibration is gone, taps don't trigger vibration anymore. Webview also seemed to be unaffected by the delays (although I'm not entirely sure, the bug is now gone) I also restarted unity8 and unity8-dash with Mir input logging enabled. That showed that the touch events were being delivered as expected, no delay. restart unity8 MIR_CLIENT_INPUT_RECEIVER_REPORT=log and restart unity8-dash MIR_CLIENT_INPUT_RECEIVER_REPORT=log Restarting lightdm (that forces the restart of unity-system-compositor) fixed the issue. Additional info: I had Mir touchspots visualization enabled, which are known to cause more stuttering, but I think they're unlikely to be the cause of this bug, I had them enabled for 2 weeks and haven't noticed any problem like this before. This is the log from a tap on an icon in the shell: [2016-09-06 10:52:51.876400] <DEBUG> input-receiver: Received event:touch_event(when=54593678129000 (6.030520ms ago), from=3, touch = {{id=0, action=down, tool=finger, x=426.211, y=292.695, pressure=0.85098, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.953821] <DEBUG> input-receiver: Received event:touch_event(when=54593751953000 (9.709366ms ago), from=3, touch = {{id=0, action=change, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.954343] <DEBUG> input-receiver: Received event:touch_event(when=54593761256000 (0.958751ms ago), from=3, touch = {{id=0, action=up, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) Krillin, rc-proposed/bq_aquaris.en r422 Description: All at once taps have become incredibly delayed, by 1 or 2 secs. Gestures still work ok, no delay there. Swiping the greeter -> no delay. Tapping numbers to input code on the greeter --> 2 secs delay. Even though both are parts of unity8. So it doesn't seem to only be a problem of unity8 clients, but also unity8 itself. I have no idea why horizontal/vertical swipes would be unaffected, though. The virtual keyboard is also completely unusable because of the huge delay that each tap has. Also noticed that the vibration is gone, taps don't trigger vibration anymore. Webview also seemed to be unaffected by the delays (although I'm not entirely sure, the bug is now gone) I also restarted unity8 and unity8-dash with Mir input logging enabled. That showed that the touch events were being delivered as expected, no delay. restart unity8 MIR_CLIENT_INPUT_RECEIVER_REPORT=log and restart unity8-dash MIR_CLIENT_INPUT_RECEIVER_REPORT=log Restarting lightdm (that forces the restart of unity-system-compositor) fixed the issue. Additional info: I had Mir touchspots visualization enabled, which are known to cause more stuttering, but I think they're unlikely to be the cause of this bug, I had them enabled for 2 weeks and haven't noticed any problem like this before. This is the log from a tap on an icon in the shell: [2016-09-06 10:52:51.876400] <DEBUG> input-receiver: Received event:touch_event(when=54593678129000 (6.030520ms ago), from=3, touch = {{id=0, action=down, tool=finger, x=426.211, y=292.695, pressure=0.85098, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.953821] <DEBUG> input-receiver: Received event:touch_event(when=54593751953000 (9.709366ms ago), from=3, touch = {{id=0, action=change, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.954343] <DEBUG> input-receiver: Received event:touch_event(when=54593761256000 (0.958751ms ago), from=3, touch = {{id=0, action=up, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) SEE VIDEO ATTACHMENT BELOW
2016-09-06 10:31:40 Michał Sawicz affects unity8 (Ubuntu) ubuntu-ui-toolkit (Ubuntu)
2016-09-06 14:55:06 Andrea Bernabei description Krillin, rc-proposed/bq_aquaris.en r422 Description: All at once taps have become incredibly delayed, by 1 or 2 secs. Gestures still work ok, no delay there. Swiping the greeter -> no delay. Tapping numbers to input code on the greeter --> 2 secs delay. Even though both are parts of unity8. So it doesn't seem to only be a problem of unity8 clients, but also unity8 itself. I have no idea why horizontal/vertical swipes would be unaffected, though. The virtual keyboard is also completely unusable because of the huge delay that each tap has. Also noticed that the vibration is gone, taps don't trigger vibration anymore. Webview also seemed to be unaffected by the delays (although I'm not entirely sure, the bug is now gone) I also restarted unity8 and unity8-dash with Mir input logging enabled. That showed that the touch events were being delivered as expected, no delay. restart unity8 MIR_CLIENT_INPUT_RECEIVER_REPORT=log and restart unity8-dash MIR_CLIENT_INPUT_RECEIVER_REPORT=log Restarting lightdm (that forces the restart of unity-system-compositor) fixed the issue. Additional info: I had Mir touchspots visualization enabled, which are known to cause more stuttering, but I think they're unlikely to be the cause of this bug, I had them enabled for 2 weeks and haven't noticed any problem like this before. This is the log from a tap on an icon in the shell: [2016-09-06 10:52:51.876400] <DEBUG> input-receiver: Received event:touch_event(when=54593678129000 (6.030520ms ago), from=3, touch = {{id=0, action=down, tool=finger, x=426.211, y=292.695, pressure=0.85098, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.953821] <DEBUG> input-receiver: Received event:touch_event(when=54593751953000 (9.709366ms ago), from=3, touch = {{id=0, action=change, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.954343] <DEBUG> input-receiver: Received event:touch_event(when=54593761256000 (0.958751ms ago), from=3, touch = {{id=0, action=up, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) SEE VIDEO ATTACHMENT BELOW Krillin, rc-proposed/bq_aquaris.en r422 UPDATE: see comment #5, it turns out it's the haptics plugin doing SYNC dbus calls and blocking the UI thread when the dbus service does not reply or the replies come with a big delay Description: All at once taps have become incredibly delayed, by 1 or 2 secs. Gestures still work ok, no delay there. Swiping the greeter -> no delay. Tapping numbers to input code on the greeter --> 2 secs delay. Even though both are parts of unity8. So it doesn't seem to only be a problem of unity8 clients, but also unity8 itself. I have no idea why horizontal/vertical swipes would be unaffected, though. The virtual keyboard is also completely unusable because of the huge delay that each tap has. Also noticed that the vibration is gone, taps don't trigger vibration anymore. Webview also seemed to be unaffected by the delays (although I'm not entirely sure, the bug is now gone) I also restarted unity8 and unity8-dash with Mir input logging enabled. That showed that the touch events were being delivered as expected, no delay. restart unity8 MIR_CLIENT_INPUT_RECEIVER_REPORT=log and restart unity8-dash MIR_CLIENT_INPUT_RECEIVER_REPORT=log Restarting lightdm (that forces the restart of unity-system-compositor) fixed the issue. Additional info: I had Mir touchspots visualization enabled, which are known to cause more stuttering, but I think they're unlikely to be the cause of this bug, I had them enabled for 2 weeks and haven't noticed any problem like this before. This is the log from a tap on an icon in the shell: [2016-09-06 10:52:51.876400] <DEBUG> input-receiver: Received event:touch_event(when=54593678129000 (6.030520ms ago), from=3, touch = {{id=0, action=down, tool=finger, x=426.211, y=292.695, pressure=0.85098, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.953821] <DEBUG> input-receiver: Received event:touch_event(when=54593751953000 (9.709366ms ago), from=3, touch = {{id=0, action=change, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.954343] <DEBUG> input-receiver: Received event:touch_event(when=54593761256000 (0.958751ms ago), from=3, touch = {{id=0, action=up, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) SEE VIDEO ATTACHMENT BELOW
2016-09-06 14:55:58 Andrea Bernabei bug task added platform-api (Ubuntu)
2016-09-06 14:56:07 Andrea Bernabei bug task deleted ubuntu-ui-toolkit (Ubuntu)
2016-09-06 15:13:12 Launchpad Janitor platform-api (Ubuntu): status New Confirmed
2016-09-06 15:13:25 Cris Dywan platform-api (Ubuntu): importance Undecided Critical
2016-09-06 15:43:07 Andrea Bernabei summary [Krillin] Taps are delayed by 1-2seconds, although gestures are not. Keyboard is thus unusable [Krillin] Haptics engine uses sync dbus calls. Was: "Taps are delayed by 1-2seconds, although gestures are not. Keyboard is thus unusable"
2016-09-06 15:43:13 Andrea Bernabei summary [Krillin] Haptics engine uses sync dbus calls. Was: "Taps are delayed by 1-2seconds, although gestures are not. Keyboard is thus unusable" Haptics engine uses sync dbus calls. Was: "Taps are delayed by 1-2seconds, although gestures are not. Keyboard is thus unusable"
2016-09-06 15:44:04 Thomas Voß branch linked lp:~thomas-voss/platform-api/fix-1620553
2016-09-06 15:44:38 Andrea Bernabei bug task added usensord (Ubuntu)
2016-09-06 15:45:32 Thomas Voß platform-api (Ubuntu): importance Critical High
2016-09-06 15:45:38 Thomas Voß platform-api (Ubuntu): assignee Thomas Voß (thomas-voss)
2016-09-06 16:02:37 Pat McGowan tags regression-proposed
2016-09-06 16:04:30 Pat McGowan usensord (Ubuntu): importance Undecided High
2016-09-06 16:04:30 Pat McGowan usensord (Ubuntu): status New Confirmed
2016-09-06 16:06:07 Pat McGowan bug task added canonical-devices-system-image
2016-09-06 16:17:01 Pat McGowan canonical-devices-system-image: status New Incomplete
2016-09-06 16:17:07 Pat McGowan canonical-devices-system-image: assignee Pat McGowan (pat-mcgowan)
2016-09-06 16:23:28 Pat McGowan canonical-devices-system-image: importance Undecided Medium
2016-09-06 16:23:35 Pat McGowan tags regression-proposed
2016-09-07 01:18:35 Daniel van Vugt tags performance
2016-09-07 01:42:49 Daniel van Vugt summary Haptics engine uses sync dbus calls. Was: "Taps are delayed by 1-2seconds, although gestures are not. Keyboard is thus unusable" Haptics engine uses sync dbus calls. OSK becomes unusable as taps are delayed by 1-2 seconds and vibration doesn't occur any more (although gestures continue to work)
2016-09-07 01:42:57 Daniel van Vugt platform-api (Ubuntu): status Confirmed In Progress
2016-09-07 01:43:02 Daniel van Vugt canonical-devices-system-image: status Incomplete In Progress
2016-09-07 01:46:03 Daniel van Vugt summary Haptics engine uses sync dbus calls. OSK becomes unusable as taps are delayed by 1-2 seconds and vibration doesn't occur any more (although gestures continue to work) OSK becomes unusable as taps are delayed by 1-2 seconds and vibration doesn't occur any more (although gestures continue to work)
2016-09-07 13:16:44 Pat McGowan canonical-devices-system-image: importance Medium Critical
2016-09-07 13:16:44 Pat McGowan canonical-devices-system-image: milestone 13
2016-09-07 13:17:01 Pat McGowan tags performance performance regression-proposed
2016-09-08 21:04:29 Pat McGowan usensord (Ubuntu): assignee Zhang Enwei (zhangew401)
2016-09-09 08:21:04 Jean-Baptiste Lallement tags performance regression-proposed lt-blocker performance regression-proposed
2016-09-09 08:22:36 Jean-Baptiste Lallement description Krillin, rc-proposed/bq_aquaris.en r422 UPDATE: see comment #5, it turns out it's the haptics plugin doing SYNC dbus calls and blocking the UI thread when the dbus service does not reply or the replies come with a big delay Description: All at once taps have become incredibly delayed, by 1 or 2 secs. Gestures still work ok, no delay there. Swiping the greeter -> no delay. Tapping numbers to input code on the greeter --> 2 secs delay. Even though both are parts of unity8. So it doesn't seem to only be a problem of unity8 clients, but also unity8 itself. I have no idea why horizontal/vertical swipes would be unaffected, though. The virtual keyboard is also completely unusable because of the huge delay that each tap has. Also noticed that the vibration is gone, taps don't trigger vibration anymore. Webview also seemed to be unaffected by the delays (although I'm not entirely sure, the bug is now gone) I also restarted unity8 and unity8-dash with Mir input logging enabled. That showed that the touch events were being delivered as expected, no delay. restart unity8 MIR_CLIENT_INPUT_RECEIVER_REPORT=log and restart unity8-dash MIR_CLIENT_INPUT_RECEIVER_REPORT=log Restarting lightdm (that forces the restart of unity-system-compositor) fixed the issue. Additional info: I had Mir touchspots visualization enabled, which are known to cause more stuttering, but I think they're unlikely to be the cause of this bug, I had them enabled for 2 weeks and haven't noticed any problem like this before. This is the log from a tap on an icon in the shell: [2016-09-06 10:52:51.876400] <DEBUG> input-receiver: Received event:touch_event(when=54593678129000 (6.030520ms ago), from=3, touch = {{id=0, action=down, tool=finger, x=426.211, y=292.695, pressure=0.85098, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.953821] <DEBUG> input-receiver: Received event:touch_event(when=54593751953000 (9.709366ms ago), from=3, touch = {{id=0, action=change, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.954343] <DEBUG> input-receiver: Received event:touch_event(when=54593761256000 (0.958751ms ago), from=3, touch = {{id=0, action=up, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) SEE VIDEO ATTACHMENT BELOW Krillin, rc-proposed/bq_aquaris.en r422 TEST CASE: 1. Create to alarms that'll trigger at the same time 2. Wait until they go off 3. Dismiss the alarms 4. Verify that there is still haptic feedback and OSK is still responsive ACTUAL RESULT Step 4 fails. UPDATE: see comment #5, it turns out it's the haptics plugin doing SYNC dbus calls and blocking the UI thread when the dbus service does not reply or the replies come with a big delay Description: All at once taps have become incredibly delayed, by 1 or 2 secs. Gestures still work ok, no delay there. Swiping the greeter -> no delay. Tapping numbers to input code on the greeter --> 2 secs delay. Even though both are parts of unity8. So it doesn't seem to only be a problem of unity8 clients, but also unity8 itself. I have no idea why horizontal/vertical swipes would be unaffected, though. The virtual keyboard is also completely unusable because of the huge delay that each tap has. Also noticed that the vibration is gone, taps don't trigger vibration anymore. Webview also seemed to be unaffected by the delays (although I'm not entirely sure, the bug is now gone) I also restarted unity8 and unity8-dash with Mir input logging enabled. That showed that the touch events were being delivered as expected, no delay. restart unity8 MIR_CLIENT_INPUT_RECEIVER_REPORT=log and restart unity8-dash MIR_CLIENT_INPUT_RECEIVER_REPORT=log Restarting lightdm (that forces the restart of unity-system-compositor) fixed the issue. Additional info: I had Mir touchspots visualization enabled, which are known to cause more stuttering, but I think they're unlikely to be the cause of this bug, I had them enabled for 2 weeks and haven't noticed any problem like this before. This is the log from a tap on an icon in the shell: [2016-09-06 10:52:51.876400] <DEBUG> input-receiver: Received event:touch_event(when=54593678129000 (6.030520ms ago), from=3, touch = {{id=0, action=down, tool=finger, x=426.211, y=292.695, pressure=0.85098, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.953821] <DEBUG> input-receiver: Received event:touch_event(when=54593751953000 (9.709366ms ago), from=3, touch = {{id=0, action=change, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) [2016-09-06 10:52:51.954343] <DEBUG> input-receiver: Received event:touch_event(when=54593761256000 (0.958751ms ago), from=3, touch = {{id=0, action=up, tool=finger, x=426.211, y=292.695, pressure=0.843137, major=19.963, minor=0, size=19.963}, modifiers=1) SEE VIDEO ATTACHMENT BELOW
2016-09-09 08:30:09 Yuan-Chen Cheng bug added subscriber Yuan-Chen Cheng
2016-09-09 08:30:38 Zhang Enwei usensord (Ubuntu): status Confirmed In Progress
2016-09-09 13:07:50 Andrea Bernabei attachment added go_stacktrace https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1620553/+attachment/4737644/+files/go_stacktrace
2016-09-09 13:15:35 Andrea Bernabei attachment added go_stacktrace2 https://bugs.launchpad.net/ubuntu/+source/platform-api/+bug/1620553/+attachment/4737646/+files/go_stacktrace2
2016-09-09 15:46:26 Pat McGowan branch linked lp:~zhangew401/usensord/bug-1620553
2016-09-16 20:24:56 Pat McGowan usensord (Ubuntu): status In Progress Fix Committed
2016-09-16 20:25:00 Pat McGowan canonical-devices-system-image: status In Progress Fix Committed
2016-09-20 21:07:42 Pat McGowan canonical-devices-system-image: status Fix Committed Fix Released