On Mon, Oct 24, 2016 at 11:04:35AM +0200, Daniel Vetter wrote: > On Sat, Oct 22, 2016 at 09:32:41AM +0100, Chris Wilson wrote: > > Before we start trying random combinations of connectors and CRTCs, we > > should first ensure we have a blank slate so that if we only change a > > subset of the CRTC we do not conflict with a residual setup on the other > > CRTC. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > --- > > tests/kms_setmode.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c > > index 24fb34c..df958f0 100644 > > --- a/tests/kms_setmode.c > > +++ b/tests/kms_setmode.c > > @@ -268,6 +268,10 @@ static void setup_crtcs(drmModeRes *resources, struct connector_config *cconf, > > int i; > > int encoder_usage_count[resources->count_encoders]; > > > > + for (i = 0; i < resources->count_crtcs; i++) > > + drmModeSetCrtc(drm_fd, resources->crtcs[i], > > + 0, 0, 0, 0, 0, NULL); > > Shouldn't this be in some modeset helper library, or is kms_setmode not > using that one? Especially with atomic it's much neater to just clear our > software state (and then applying all the changes we want in one go). Otoh, something as simple as kms_setmode, one can argue should just be using (cleanly and clearly, ofc) the raw interfaces and iterating over them. kms_setmode_legacy / kms_setcrtc / drm_setcrtc, kms_setmode_atomic, igt_setmode / kms_setmode would all then serve slightly different purposes (both testing and pedagogy). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
