[regression] Screen flickering and error messages on Android overlay surfaces: <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use

Our Android devices have always suffered from a little flickering with software buffers. It doesn't happen too much now and is certainly not a major priority for Unity8. But I think this is a duplicate of one of:

  bug 1406725
  bug 1418035
  bug 1373696

Note, that I don't see the problematic behavior with mir 0.12.1 on krillin.

Sounds like it might be a BufferStream regression in that case. But we have other open bugs relating to Android flicker as you can see.

Also reproduced with glmark2-es2-mir running on arale; flickering and:

[1433494388.426779] <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use

[1433494388.456680] <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use

[1433494388.468927] <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use

That's using the latest trunk Mir 0.14.0 for the server, and glmark2-es2-mir is using the system installed libmirclient8 from Mir 0.13.1.

Also easy to reproduce with: mir_demo_client_target -n
particularly if you have a mouse plugged into the device.

Workaround:
Start your Mir server with: --disable-overlays

Could be related to bug 1391261 too.

This bug seems to have been introduced fairly recently with the 0.11 release:
------------------------------------------------------------
revno: 2261 [merge]
author: Robert Carr <email address hidden>
committer: Tarmac
branch nick: development-branch
timestamp: Mon 2015-01-26 21:29:52 +0000
message:
  Factor a common buffer stream implementation out of MirScreencast and MirSurface.

  Approved by PS Jenkins bot, Alberto Aguirre, Chris Halse Rogers, Alexandros Frantzis.
------------------------------------------------------------

Seems overly pessimistic that we'll need a separate "bufferstream-regression" tag.

could reproduce on adreno-based nexus7, so doesn't seem to be a device specific, probably affects an android-in-general

corresponding messages from the driver:

E/qdgralloc(17786): gralloc_register_buffer: gralloc_map failed
E/qdmemalloc(17786): ion: Failed to map memory in the client: Bad file descriptor
E/qdgralloc(17786): Could not mmap handle 0xb5c05608, fd=1701978226 (Bad file descriptor)

So, from initial investigation, seems to be a problem with mf::client_buffer_cache_size. System starts out with 3 buffers, and works okay. An overallocation occurs, which kicks one of the 3 original buffers out. (calls gralloc_module_t::unregisterBuffer()).
Android has this t̶e̶r̶r̶i̶b̶l̶e̶ quirky bit about its client-side gralloc functions that once a buffer is unmapped in the client process, you can never map it again. So when the kicked-out-original buffer comes back around to the client, it tries to set it up again, and the driver rejects the mapping. The flickering is because one of the buffers in the cycle can never be written to again in software, and is stuck in the past, while the other buffers have never been kicked out and can still be written to

potential solutions:
1) "new buffer semantics" has better client/server synchronization between the number of buffers in the system, so the problem will go away when the client becomes aware of how many buffers are in the swapping chain.
2) increase mf::client_buffer_cache_size to 4. This is slightly disadventageous because it doesn't solve the problem outright (there can be more than one overallocation), and leaves buffers lingering.

Seems like this can also manifest as "hang" in mir_performance_test (lp:~alan-griffiths/mir/fix-1486496/+merge/268747)

Kind of, yeah. The client doesn't get buffers back cleanly so nothing gets rendered sometimes. That would appear as a hang.

Fix committed into lp:mir at revision 2882, scheduled for release in mir, milestone 0.16.0

mir (0.16.0+15.10.20150921.1-0ubuntu1) wily; urgency=medium