On Mon, Dec 18, 2017 at 2:38 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Fri, 15 Dec 2017 15:35:53 -0500 > Alex Deucher <alexdeuc...@gmail.com> wrote: > >> On Fri, Dec 15, 2017 at 2:27 AM, Pekka Paalanen <ppaala...@gmail.com> wrote: >> > On Thu, 14 Dec 2017 10:11:32 -0500 >> > Alex Deucher <alexdeuc...@gmail.com> wrote: >> > >> >> On Thu, Dec 14, 2017 at 6:40 AM, Pekka Paalanen <ppaala...@gmail.com> >> >> wrote: >> >> > From: Pekka Paalanen <pekka.paala...@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. >> >> > > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
