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? > > > > 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. > >> >
pgpDbRQTq4ZQp.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
