[PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure

[Alex Deucher]

On Mon, Dec 18, 2017 at 2:38 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 15 Dec 2017 15:35:53 -0500
> Alex Deucher <alexdeucher at gmail.com> wrote:
>
>> On Fri, Dec 15, 2017 at 2:27 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Thu, 14 Dec 2017 10:11:32 -0500
>> > Alex Deucher <alexdeucher at gmail.com> wrote:
>> >
>> >> On Thu, Dec 14, 2017 at 6:40 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> >> > From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>> >> >
>> >> > Hi all,
>> >> >
>> >> > this is v5 (to match the numbering of my public branches) of the libweston user
>> >> > facing API and infrastructure for supporting shared-CRTC clone mode.
>> >> >
>> >> > Previous submission with rationale:
>> >> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html
>> >> >
>> >> > Design document:
>> >> > https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/
>> >> >
>> >> > The goal:
>> >> > https://phabricator.freedesktop.org/T7727
>> >>
>> >> FWIW, at least with the DC modesetting code in amdgpu, we can
>> >> synchronize multiple crtcs to the same timing when the monitors all
>> >> support the same mode timing or with monitors that have different
>> >> timings using variable length blanking periods on freesync capable
>> >> monitors.
>> >
>> > Hi Alex,
>> >
>> > that's cool. How does userspace take advantage of that, how do you
>> > configure KMS/atomic to make use of that? Is it supported through
>> > legacy KMS (non-atomic) as well?
>>
>> the driver automatically syncs all heads that it can at modeset time I think.
>
> Ok, but we need strong timing guarantees to be able to use it, just
> like we have when we have a single CRTC routed to several connectors.
> Is there such a guarantee that continues not only on initial modeset
> but through all following flips as well?

The timing is synchronized so in theory the flips should happen during
the same blanking period.  I think atomic may be able to guarantee
that, but while likely I don't think non-atomic can guarantee it.

>
>> >
>> > Does it involve things like the driver stealing an unused CRTC for each
>> > additional clone?
>>
>> No, there is logic in the gpu to sync the timing of multiple crtcs.
>> You just need 1 crtc per display.
>
> That is a bit awkward for Weston if userspace needs to assign a CRTC
> per connector and then quess whether all the CRTCs will be gen-locked
> for good so it needs only a single repaint loop, or not and it needs a
> repaint loop per CRTC.
>
> Is there a way to know for sure whether a set of CRTCs will be
> gen-locked? Preferably with ATOMIC_TEST_ONLY.

I don't think so.

Alex

>
>
> Thanks,
> pq
>
>>
>> >
>> > The feature would fit perfectly under the "shared-CRTC clone mode" from
>> > libweston API point of view, even though it's not actually a single
>> > shared CRTC.
>> >
>> >
>> > Thanks,
>> > pq
>> >
>> >>
>> >>
>> >> Alex
>> >>
>> >> >
>> >> > Changes in v5 compared to v3 are minor:
>> >> > - "libweston: properly orphan wl_output resources" is new.
>> >> > - Removal of wl_output global, when a head is detached from an enabled output.
>> >> > - Print "Detected a monitor change" only for enabled heads.
>> >> >
>> >> > You can find this series in the branch:
>> >> > https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5
>> >> >
>> >> > I went through the same testing procedure as with v3, the previous submission.
>> >> >
>> >> >
>> >> > However, the interesting bits are in the branch:
>> >> > https://gitlab.collabora.com/pq/weston/commits/clonemode-4
>> >> >
>> >> > As new things compared to clonemode-user-API-2, that one contains:
>> >> > - support for configuring clone mode in weston.ini
>> >> > - main.c implementation to configure a clode using the new API
>> >> > - desktop-shell enhancements to avoid redundant panel and background surfaces
>> >> >   in clone mode
>> >> > - hooking up custom data to weston_output via a new user-side destroy signal
>> >> > - naming outputs freely
>> >> > - DRM-backend support for shared-CRTC clone mode
>> >> > - video mode list merging in the DRM-backend
>> >> >
>> >> > The shared-CRTC clone mode has been tested to work on an i.MX6 device.
>> >> > Unfortunately it seems that PC hardware that would support it is becoming
>> >> > scarce AFAIU.
>> >> >
>> >> > Most of the patches in clonemode-4 depend on the atomic modesetting series and
>> >> > can therefore be submitted only after that one.
>> >> >
>