From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, stable@vger.kernel.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/sdvo: Fallback to current output timings for LVDS fixed mode
Date: Tue, 25 Oct 2022 23:32:23 +0300 [thread overview]
Message-ID: <Y1hH10dyV0bCCSSr@intel.com> (raw)
In-Reply-To: <878rl3eqx7.fsf@intel.com>
On Tue, Oct 25, 2022 at 08:47:32PM +0300, Jani Nikula wrote:
> On Tue, 25 Oct 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > If we can't dig out a fixed mode for LVDS from the VBT or EDID
> > let's fall back to using the current output timings. This should
> > work as long as the BIOS has (somehow) enabled the output.
> >
> > In this case we are dealing with the some kind of BLB based POS
> > machine (Toshiba SurePOS 500) where neither the OpRegion mailbox
> > nor the vbios ROM contain a valid VBT. And no EDID anywhere we
> > could find either.
> >
> > Cc: <stable@vger.kernel.org> # v5.19+
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
>
> But they're saying it's a regression between 4.19 and 5.10...
Yeah. I can't actually figure out how it could have worked even
with 4.19.
Hmm. Actually now that I look at some of the hints in the logs it
does look like it maybe did find an EDID after all. What confused
me was that all the modes very much like the _noedid stuff.
Ah, it looks like we fail to fully initialize the DDC stuff
before setting up the outputs, which I guess explains why the
EDID read fails there. Previously there was this funky feedback
loop in that .get_modes() actually filled in the fixed_mode,
so until you called that (after everything else was fully set
up) you didn't have a fixed mode.
And while looking at this stuff more I can see that the whole
multi output support is still very much snafu :/
I'll see if I can make a fairly minimal fix for now...
--
Ville Syrjälä
Intel
prev parent reply other threads:[~2022-10-25 20:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-25 16:59 [PATCH] drm/i915/sdvo: Fallback to current output timings for LVDS fixed mode Ville Syrjala
2022-10-25 17:47 ` [Intel-gfx] " Jani Nikula
2022-10-25 20:32 ` Ville Syrjälä [this message]
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=Y1hH10dyV0bCCSSr@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).