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 <[email protected]>
> > ---
> > 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
