unity8 display flickers and stops responding on Nexus 7 (grouper)

Bug #1238695 reported by Jamie Strandboge on 2013-10-11
This bug affects 41 people
Affects Status Importance Assigned to Milestone
Fix Released
Kevin DuBois
mir (Ubuntu)

Bug Description

Mir is now the default on images. Problem is, it really doesn't work well on grouper and my team primarily has grouper devices.

Test case:
1. flash to an image that has mir by default (eg, I tested on 92)
2. boot into unity and confirm that /home/phablet/.display-mir is present and surfaceflinger is not running (ps auxww|grep [s]urf)
3. move to the Applications scope
4. launch the browser (it comes to the foreground)
5. swipe left to right in an effort to display the underlying Application scope

Expected results:
browser is moved to background and the applications scope is seen

Actual results:
display continuously flashes at a very fast rate and the device is unusable

Use surfaceflinger:
# rm -f /home/phablet/.display-mir && reboot

I'm told by the phonedations team that surfaceflinger will not be getting bug fixes now, so we can expect bugs to creep in there. goldfish is also not available yet for people to develop on.

# system-image-cli -i
current build number: 92
device name: grouper
channel: devel-proposed
last update: 2013-10-10 19:50:03
version version: 92
version ubuntu: 20131010.2
version device: 20131010

Related branches

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mir (Ubuntu):
status: New → Confirmed
Changed in mir:
status: New → Confirmed
tags: added: nexus7
summary: - mir mostly unusable on Nexus 7 (grouper)
+ unity8 mostly unusable on Nexus 7 (grouper)
summary: - unity8 mostly unusable on Nexus 7 (grouper)
+ unity8 display flickers and stops responding on Nexus 7 (grouper)
Barry Warsaw (barry) wrote :

I'm having exactly this problem and the display is highly unstable from the moment the device boots. Sometimes the display is bright, but it always flickers back to very dim (the graphics are barely visible). Touch is also very slow to respond, sometimes not responding to gestures at all.

OTOH, rebooting without mir doesn't seem all that much better. The screen will still go blank randomly, with limited response to touch or button pushes. Then the display comes back and is responsive for a bit before going blank again rather quickly.

Maybe I've got busted hardware? I've flashed it several times without improvement. I'm going to try to factory reset it to see if it's a hardware problem.

Harald Gegenfurtner (alamak) wrote :

Hi Barry, I can confirm your description and I don't think you've got "busted hardware" as my Nexus 7 (2012) works fine with Android but shows the same problems (flickering display, blank screens, complete unresponsiveness) with the present saucy version of Ubuntu touch. I haven't tried the above mentioned surfaceflinger workaround yet, will be trying at the weekend.

Robert Bruce Park (robru) wrote :

Agreed, this problem started when mir became the default in the touch images. Definitely not a hardware problem.

Harald Gegenfurtner (alamak) wrote :

So far, the proposed workaround:

adb shell rm -f /home/phablet/.display-mir && reboot

works fine for me.

(As I'm new to Ubuntu touch, it took me some time to figure out that the rm command must be sent to "adb shell".)

vasilisc (vasilisc) wrote :

# system-image-cli -i
current build number: 5
device name: grouper
channel: trusty
last update: 2013-10-30 13:43:35
version version: 5
version ubuntu: 20131024
version device: 20131024

display continuously flashes at a very fast rate and the device is unusable

wbonline (wesleybons) wrote :

Can confirm this, i am having this issue also. it began when mir became default, when i am using SurfaceFlinger (workaround) the tablet is smooth again and its not crashing anymore

Changed in mir:
importance: Undecided → High
Changed in mir (Ubuntu):
importance: Undecided → High
Changed in mir:
status: Confirmed → Triaged
Changed in mir (Ubuntu):
status: Confirmed → Triaged
Ryan Whited (dergottdergrunten) wrote :

http://www.youtube.com/watch?v=TZdtqgvQbj0 for video (sort of) of the bug. When you see the display become dim, that is when the flashing begins.

Robert Bruce Park (robru) wrote :

This seems to be fixed in latest trusty proposed. Not all the animations work quite right, but it at least no longer becomes unresponsive during edge swipes, at least for me.

Kevin DuBois (kdub) wrote :

Taking a look at this, I see it on my tegra3.

I've eliminated:
#1 Application switching (this seems okay with mir_demo_server_shell)

#2 logcat messages about:
E/hwcomposer( 6696): Failed to set DIDIM level
E/hwcomposer( 6696): /sys/class/graphics/fb0/device/smartdimmer/enable: open failed, errno = 13
these don't really seem to affect anything

#3 Display loop hangs
During the flicker/static image, the display loop is still updating in response to touch events.

The most likely cause is something is going awry with screenshotting on this device. The problem happens around the time unity8 would take a screenshot, and I see messages like:
file:///usr/lib/arm-linux-gnueabihf/qt5/imports/Unity-Mir/Unity/Application/ApplicationImage.qml:37:5: QML QQuickImage: Failed to get image from provider: image://screenshot/ubuntu-system-settings

Changed in mir:
assignee: nobody → Kevin DuBois (kdub)
status: Triaged → In Progress
Changed in mir:
milestone: none → 0.1.2
Kevin DuBois (kdub) wrote :

my suspicions are correct... it appears that, with the tegra3 driver, the use of a texture with glReadPixels is simply broken. If you use a renderbuffer with glReadPixels, screenshotting is okay. I have something working on my device here, have to figure out the best way to land

Changed in mir:
milestone: 0.1.2 → 0.1.3
Changed in mir:
milestone: 0.1.3 → 0.1.4
Kevin DuBois (kdub) wrote :

okay, given the chance of us poking nvidia to fix this old/rotting driver, i'm working on accomodating the brokenness by acquiring snapshots via renderbuffers instead of textures.

I noticed surfaceflinger notes in some of the comments for code around the time of this driver that some 'old drivers' have difficulty with this as well.

Kevin DuBois (kdub) wrote :

my testing reveals that the branch lp:~kdub/mir/fix-1238695 fixes the problem on the nexus 7... but cause problems on the nexus 4. Need to find a way that makes everyone happy.

Kevin DuBois (kdub) wrote :

Working on proposing lp:~kdub/mir/snapshot-error-checking to fail more gracefully.

This should provide relief from taking Unity8 down on this device, although it will not provide application thumbnails yet (so the bug probably should remain open)

Kevin DuBois (kdub) wrote :

I abandoned my efforts in lp:~kdub/mir/snapshot-error-checking, as it turned out not to be that robust (errors were still being generated).

Rather, I kept investigating, and found that the same EGLImages bound in the rendering thread and the snapshot thread on this driver (but not any of the others) cause problems. I put a workaround for this (make different contexts generate EGLImage siblings) in lp:~kdub/mir/fix-1238695

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:
status: Fix Committed → Fix Released
Fishscene (fishscene-hotmail) wrote :

Pardon my unfamiliarity, but I'm not sure if this has been fixed or not.
Ubuntu 14.04 r128
Last updated: 2014-01-14
Device: Nexus 7 (original)
I have not yet found way to reliably reproduce the following behavior:
Sometimes when I'm in an application and swipe rightedge-to-left, screen kind of fades in-and-out a couple of times (flickers?), then blacks out (Display server crash?). But this is nowhere near as bad as the flickering it used to go through.
The only way to recover is to power cycle the Nexus 7 as nothing will be displayed until it is powered off. Should I be seeing the released fix by now? or am I experiencing another bug?

Daniel van Vugt (vanvugt) wrote :

No the fix is not in Ubuntu yet.

The fix is in Mir 0.1.4 (see at the top), and Ubuntu (including touch) only has Mir 0.1.3 right now:

Fishscene (fishscene-hotmail) wrote :

Thanks for clearing that up Daniel. I received an e-mail saying this had been resolved right around the time Mir 0.1.3 was released. Onwards and upwards!

Heads up: This bug has been fixed in r141.

Nevermind, ran into it twice in the file manager, it does however occur a lot less now.

Fishscene (fishscene-hotmail) wrote :

Thought I'd share the following for those anticipating this bugfix:
Popey showed me the command he uses to check the Mir version.
adbshell dpkg -l "*mir*"
It should say something like "ii libmirclient4: 0.1.3+14.04. armhf" (A.K.A. Mir 0.1.3)
...bug should be fixed in 0.1.4.

Ran into it some more in r144. What Mir is this?

Huh. 0.1.3.

Jamie Strandboge (jdstrand) wrote :

I tested the packages in https://jenkins.qa.ubuntu.com/job/mir-trusty-armhf-ci/25/? (built from lp:~mir-team/mir/trunk-0.1.4) and mir seems to be working great! I installed apps, did all edge swipes, etc. Thanks!

The only issue is that libunity-mir1 needs to be built against the new libmirserver13 for my work it seems.

Launchpad Janitor (janitor) wrote :
Download full text (6.8 KiB)

This bug was fixed in the package mir - 0.1.4+14.04.20140204-0ubuntu1

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

  [ Daniel van Vugt ]
  * New upstream release 0.1.4 (https://launchpad.net/mir/+milestone/0.1.4)
    - Fixed snapshotting and flicker problems for Unity8 on various Nexus
    - Enhanced reporting of performance information:
      . Report input latency in InputReport/InputReceiverReport.
      . Added a CompositorReport for logging compositor performance and state.
    - Added a new package "mir-utils" containing new tools:
      . mirping: Displays round-trip times between client and server
      . mirout: Displays the monitor layout/configuration details
    - Added GL texture caching to improve performance when multiple surfaces
      are visible.
    - Added opacity controls to mir_demo_server_shell
    - Mir server ABI bumped to 13. Client ABI bumped to 5.
    - Removed lots of Android headers, replaced by build-dep: android-headers
    - Added support for translucent nested servers.
    - tests: Fix unitialized values and incorrect fd closing loops
    - Fix unitialized values and incorrect fd closing loops.
    - client: Add basic MirScreencast C API.
    - config: start moving default values for config options from all the
      call sites to the setup
    - tests: Provide a helper for running clients with a stub ClientPlatform.
    - android: split out HWC layers into their own file and add a
      mga::CompositionLayer type that depends on the interface mg::Renderable.
    - client: Add basic MirOutputCapture class.
    - client: Don't create mesa ClientBuffer objects from invalid
    - Optimize surface resizing to avoid doing anything if the dimensions
      are unchanged.
    - SwitchingBundle - add operator<< for debugging.
    - support hwcomposer 1.2 for android 4.4 on nexus 4 (which needs hwc1.2
      support). This patch adds hwc1.2 device construction, as well as progs
      the 'skip' layer in HWC to the buffer properties of the framebuffer.
    - demo-shell: Add simple keyboard controls to rotate outputs; Ctrl +
      Alt + <arrow-key>. Fixes: https://bugs.launchpad.net/bugs/1203215.
    - frontend: exposing internals of the RPC mechanism to enable custom
      function calls to be added.
    - Make udev wrapper into a top-level citizen
    - compositor: ignore double requests to start or stop the
    - Add DisplayBuffer::orientation(), to tell the Renderer if we need it
      to do screen rotation in GL (for platforms which don't implement
      rotation natively) Fixes: https://bugs.launchpad.net/bugs/1203215.
    - graphics: add an post_update function that takes a list of renderables
      to the display buffer. This will let the display buffer take advantage
      of full-surface overlays on android.
    - android-input: Improve debug output
    - the stock qcom 8960 hwcomposer chokes on getDisplayAttributes if the
      submitted arrays are not at least size 6. patched the qcom android 4.2
      hwcomposer driver on the ubuntu touch images to work properly, but
      causes us problems with in-the wild...


Changed in mir (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers