Merge lp://qastaging/~alan-griffiths/mir/workaround-1441553 into lp://qastaging/mir

Actually, that makes sense now.

Approved: Tested on arale and bug 1441553 appears to be fixed!
Needs Information: I think this branch might also fix bug 1391261. Needs testing.

PASSED: Continuous integration, rev:2874
http://jenkins.qa.ubuntu.com/job/mir-ci/4670/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/3662
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-ts-vivid-amd64-build/83
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/2573
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/3612
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/819
        deb: http://jenkins.qa.ubuntu.com/job/mir-wily-amd64-ci/819/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3612
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3612/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6381
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/22799

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-ci/4670/rebuild

Crap. And then bug 1441553 started happening again. Not fixed at all.

Rebuilt again to be sure. This branch is definitely not solving the problem...

# glmark2-es2-mir --fullscreen
=======================================================
    glmark2 2014.03
=======================================================
    OpenGL Information
    GL_VENDOR: Imagination Technologies
    GL_RENDERER: PowerVR Rogue G6200
    GL_VERSION: OpenGL ES 3.0 build 1.3@3304414
=======================================================
[build] use-vbo=false:[1440496067.577266] <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use

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

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

...

Although I feel we're on the right track. There might be a "3" constant in the Android code somewhere that should be "4".

Double crap. Those failures might just be because glmark2 is using the older libmirclient.

OK, this might be the final solution after all. Out of time to retest today.

+1, although this has the side effect of having lingering resources around on the client side. Seems a better side effect than flickering problems though. With client-initiated buffer allocations and frees, there is better agreement between the client and server about the buffer count; which is the side effect free solution.

I need to retest on more devices, and check both bugs.

Nice. Confirmed again everything is fixed. LP: #1441553 and LP: #1391261, where the latter was just the pre-BufferStream form of the same bug. It also has a historical workaround we can now revert (once glmark2 in CI is correctly loading the fixed libmirclient).

Although the comment is possibly wrong:
   "TODO this ought to be 3"

As we do sometimes legitimately need 4 buffers (framedropping + bypass/overlays simultaneously). I'm not sure why we'd say the limit ought to be 3.

FAILED: Autolanding.
Approved revid is not set in launchpad. This is most likely a launchpad issue and re-approve should fix it. There is also a chance (although a very small one) this is a permission problem of the ps-jenkins bot.
http://jenkins.qa.ubuntu.com/job/mir-autolanding/1804/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/3674
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-ts-vivid-amd64-build/95
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/2585
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/3624
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-wily-amd64-autolanding/357
        deb: http://jenkins.qa.ubuntu.com/job/mir-wily-amd64-autolanding/357/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3624
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/3624/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6393
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/22825

Nothing failed. That's just because I set it to "Needs review" again, due to my previous comment.

I'd be happy to drop the comment, but the explanation I had from Kevin was that the need for 4 buffers was, while real, not legitimate.

Is this a misunderstanding or a meaningful disagreement about the correct behaviour?

I think just a misunderstanding, the correct value for this number is "how ever many buffers are in this stream". This is between 2-4 right now, depending on overallocation and buffer scaling. Server and client don't have good agreement on this number right now.

Thanks Kevin