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

[Pekka Paalanen]

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?

> >
> > 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.


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.
> >> >  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171218/fdd8a93a/attachment.sig>