[igt-dev] [CI] lib/igt_kms: Don't reprobe connectors during igt_display_init

[Chris Wilson]

Quoting Arkadiusz Hiler (2018-02-16 15:44:26)
> On Fri, Feb 16, 2018 at 10:41:32AM +0000, Chris Wilson wrote:
> > Quoting Arkadiusz Hiler (2018-02-16 10:32:25)
> > > On Thu, Feb 15, 2018 at 04:31:42PM +0000, Chris Wilson wrote:
> > > > Quoting Arkadiusz Hiler (2018-02-15 14:22:06)
> > > > > Cc: Ville Syrjala <ville.syrjala at linux.intel.com>
> > > > > Cc: Petri Latvala <petri.latvala at intel.com>
> > > > > Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>
> > > > > ---
> > > > >  lib/igt_kms.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > > > > index ecc7a799..1f742bb4 100644
> > > > > --- a/lib/igt_kms.c
> > > > > +++ b/lib/igt_kms.c
> > > > > @@ -1919,7 +1919,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
> > > > >                  * We don't assign each output a pipe unless
> > > > >                  * a pipe is set with igt_output_set_pipe().
> > > > >                  */
> > > > > -               output->force_reprobe = true;
> > > > > +               output->force_reprobe = false;
> > > > 
> > > > The very first application needs to do a force probe or else the tests
> > > > don't work on a non-fbdev system.
> > > > -Chris
> > > 
> > > Good to know. Still we may consider adding a cmd line switch / detection
> > > for fbdev / some other mechanism to make sure that probe was done.
> > > 
> > > Reprobing each subtest is quite expensive. This simple change saves us
> > > 2/3 of time on kms skips (with just a single display).
> > 
> > Make reprobing faster, everybody wins. Only do a force if the current
> > status is uncertain; sadly UNKNOWN status was removed even though it was
> > for this purpose.
> > -Chris
> 
> What has happened to UNKNOWN and why?

It was confusing to userspace(!), so it was hidden.

> Is there any other way to check for the uncertainty?

I would do something like check for 0 connected connectors and if so
force a probe.

> Why we do not probe on i915 init?

Just the sequence of events, aiui, the userspace information isn't
updated until the probe request from userspace; that includes things
like MST topology discovery. (It's not just probe on init, why shouldn't
i915 maintain the status across all the hotplugs and changes, rather
than requiring userspace to do a forced full reprobe after i915 detects a
change, when i915 already knows the result?)
-Chris