From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Wood <thomas.wood@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes
Date: Tue, 1 Dec 2015 11:19:15 +0100 [thread overview]
Message-ID: <20151201101915.GR17050@phenom.ffwll.local> (raw)
In-Reply-To: <CANkqdn06jtsbkXvGMPnST36bLG+Lg5d-k8qc5nfCJPwF-8jJdg@mail.gmail.com>
On Tue, Dec 01, 2015 at 10:11:14AM +0000, Thomas Wood wrote:
> On 1 December 2015 at 08:08, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Two things:
> > - Somehow the kernel's mode list changed with our EDID. No idea
> > whether that's the right thing here since I'm not really an EDID
> > expert. But then again the testcase wants to check that the
> > injection works, not validate the kernel's parser.
>
> If only checking that the injection worked, perhaps it would be more
> robust just to check that at least one of the expected modes is
> present, in any position in the array. Ideally this would be a mode
> that isn't included in the default modes when a connector is enabled.
One option would be to check for the 1920x1080 mode only. That's the
preferred one, so really must be first. And it's way more high-res than
any of the default modes we inject (those top out at 1024x768). Ok with
that?
> > - We need to disable the forcing _before_ we reprobe to check whether
> > everything is back to normal: With the EDID gone but the connection
> > still force to on the kernel will fall back to a default low-res
> > mode list, making the testcase fail.
>
> This should be taken into account with the value of start_n_modes,
> since this is calculated after the connector is enabled.
Oops, I did accidentally break this in my GetConnectorCurrent patch, since
there I consolidated them all to avoid overhead. And didn't notice
because of the earlier breakage.
I'll respin these two and shift the 2nd change to the 2nd patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-12-01 10:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 8:08 [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes Daniel Vetter
2015-12-01 8:08 ` [PATCH i-g-t 2/3] lib/kms+tests: Use cached connector state Daniel Vetter
2015-12-01 8:08 ` [PATCH i-g-t 3/3] tests/kms_force_connector: Include in BAT set Daniel Vetter
2015-12-01 10:11 ` [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes Thomas Wood
2015-12-01 10:19 ` Daniel Vetter [this message]
-- strict thread matches above, loose matches on Subject: below --
2015-12-01 10:24 Daniel Vetter
2015-12-01 11:12 ` Jani Nikula
2015-12-01 13:38 ` Daniel Vetter
2015-12-02 11:50 ` Jani Nikula
2015-12-04 9:51 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151201101915.GR17050@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thomas.wood@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox