HWC Multimonitor work

Daniel van Vugt daniel.van.vugt at canonical.com
Thu Dec 11 01:34:55 UTC 2014

Regarding Display Posting [2] ...

MultiThreadedCompositor can be easily tricked into creating only one 
thread, one DisplayBufferCompositor and sharing it between an arbitrary 
number of outputs using a single render loop. Alexandros made sure of 
this, but I feel we have not utilised its full potential yet.

All you have to do is convince OverlappingOutputGroup that your two 
Android displays overlap (even when they don't) and you'll get one large 
shared DisplayBuffer to cover them all. Then all you need to do is 
convince the Android display code to scan-out a sub-rectangle of that 

Our DRM code already does all this, although we have not yet made it an 
explicitly configurable option to choose when to have one large shared 
DisplayBuffer. It does work (try clone mode with monitors of different 

On 11/12/14 04:59, Kevin DuBois wrote:
> 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.

More information about the Mir-devel mailing list