HWC Multimonitor work

[Kevin DuBois]

Hello All,
Have already embarked a bit on some android multimonitor work, and wanted
to share the plan as it stands for team comment/input.

There are two bigger chunks to the work:

Display Configuration and Control:
This is currently buried too deep behind mga::DisplayDevice. I'm going to
hoist it out of mga::DisplayDevice and mga::DisplayBuffer and put it in
mga::Display. Here it will be in a good position to control and gather the
display configuration of all the connected monitors. I'll be able to get
rid of ConfigurableDisplayDevice, make mga::Framebuffers lighter, and
remove  HwcCommonDevice. [1]

Display Posting:
MultiThreadedCompositor currently has one thread per display buffer, but
this isn't very friendly to android multimonitor. [2]. My plan is to rework
the MultiThreadedCompositor to figure out via mg::Display and
mg::DisplayBuffer how to setup and control its renderloop.

Cheers,
Kevin

[1]
This also has the added benefit of helping prepare for HWC 1.4, and giving
some of the classes a renaming or a removal.
[2]
Details of why:

HWC's prepare() and set() functions post to all the displays in one call.
We can't submit to the primary and external displays independently, because
we wind up with situations where the releaseFence of DisplayA feeds to the
acquireFences of DisplayB, and we ping-pong or deadlock with each display
waiting for the other to post.

So, given that we need to synchronize, and submit from one thread, I
considered if we could synchronize internally in the android code to make
the existing MultiThreadedCompositor work. The following reasons led me to
wanting to rework MultiThreadedCompositor to sometimes prefer
single-threaded operation:

1) We would have an superfluous thread for no reason, that incurs more
context switches.
2) The android code becomes more ropey because we're trying to synchronize
in the wrong place.
3) We've had a longstanding problem (even with single monitor) that some
badly written / buggy android drivers break when we deviate from the exact
threating model that SurfaceFlinger uses. This would simplify our threading
model and support junky drivers better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20141210/d885ba8f/attachment.html>