<div dir="ltr"><div><div>@OverlappingOutputGroup<br></div><div>The first goal is to have a clone mode, so the OverlappingOutputGroup could be a good trick. (We can't designate scanout of a sub-rectangle of a larger framebuffer surface in HWC though, so might be difficult)<br><br>If we try to have different-content monitors that really don't overlap though, I'd want to present the DisplayBuffers as separate, so at some point in the future we'd have to give some hint or requirement from the platform to the server about what's the best way to drive the composition loop. <br><br></div><div>Expounding on point 3) a bit more, a bit more input from the platform about how to run the loop would help robustify against drivers with weird fencing problems (which we've hit in bringup), as it aligns the compositor-drive-model that the drivers are best-tested with. We can also properly implement the HWC invalidate() callback (which, isnt used very often, but we currently just drop the request)<br><br></div><div>@different refresh rate,<br></div>If there are 2 sets inbetween the pageflips, the last one sticks for that display. IMO Mesa has thought about multimonitor better in its api, and 'don't break mesa's goodness" is a goal in accommodating HWC.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 10, 2014 at 9:50 PM, Daniel van Vugt <span dir="ltr"><<a href="mailto:daniel.van.vugt@canonical.com" target="_blank">daniel.van.vugt@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Even displays of the same refresh rate are a problem (see in X/Compiz where all but one of your displays will tear).<br>
<br>
In Mir (the DRM platform) we've solved this with parallel rendering while waiting for the previous page flips. Because if you have multiple monitors at the same refresh rate, the upper limit on time to wait for vsync on all of them is (asymptotically) double that of a single monitor.<br>
<br>
It's possible HWC could support such an approach, so long as we have the required triple-buffering in the compositor.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 11/12/14 10:31, Christopher James Halse Rogers wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Dec 11, 2014 at 7:59 AM, Kevin DuBois<br>
<<a href="mailto:kevin.dubois@canonical.com" target="_blank">kevin.dubois@canonical.com</a>> wrote:<br>
…<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Details of why:<br>
<br>
HWC's prepare() and set() functions post to all the displays in one call.<br>
</blockquote>
<br>
Incidentally, how does this work with displays of different refresh<br>
rate? Does HWC drop pending flips when a new flip is scheduled?<br>
<br>
<br>
</blockquote>
<br>
-- <br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com" target="_blank">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/mir-devel</a><br>
</div></div></blockquote></div><br></div>