HWC Multimonitor work

Kevin DuBois kevin.dubois at canonical.com
Thu Dec 11 19:03:19 UTC 2014


@OverlappingOutputGroup
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)

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.

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)

@different refresh rate,
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.

On Wed, Dec 10, 2014 at 9:50 PM, Daniel van Vugt <
daniel.van.vugt at canonical.com> wrote:

> Even displays of the same refresh rate are a problem (see in X/Compiz
> where all but one of your displays will tear).
>
> 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.
>
> It's possible HWC could support such an approach, so long as we have the
> required triple-buffering in the compositor.
>
>
>
> On 11/12/14 10:31, Christopher James Halse Rogers wrote:
>
>> On Thu, Dec 11, 2014 at 7:59 AM, Kevin DuBois
>> <kevin.dubois at canonical.com> wrote:
>>>>
>>>
>>> Details of why:
>>>
>>> HWC's prepare() and set() functions post to all the displays in one call.
>>>
>>
>> Incidentally, how does this work with displays of different refresh
>> rate? Does HWC drop pending flips when a new flip is scheduled?
>>
>>
>>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/mir-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20141211/d1dbcf70/attachment.html>


More information about the Mir-devel mailing list