[Intel-gfx] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

[Ville Syrjälä]

On Tue, Nov 14, 2017 at 06:38:11PM -0500, neil k wrote:
> I tested the patch from Ville Syrjälä's email and it works fine on top of
> 4.14 for me.

Thanks for confirming.

Patch pushed to drm-misc-fixes.

> 
> Thanks,
> Neil
> 
> On Thu, Nov 9, 2017 at 1:16 PM, Eric Anholt <eric at anholt.net> wrote:
> 
> > Daniel Vetter <daniel at ffwll.ch> writes:
> >
> > > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
> > >> Ville Syrjälä <ville.syrjala at linux.intel.com> writes:
> > >>
> > >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
> > >> >> Ville Syrjala <ville.syrjala at linux.intel.com> writes:
> > >> >>
> > >> >> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >> >> >
> > >> >> > Apparently some sinks look at the YQ bits even when receiving RGB,
> > >> >> > and they get somehow confused when they see a non-zero YQ value.
> > >> >> > So we can't just blindly follow CEA-861-F and set YQ to match the
> > >> >> > RGB range.
> > >> >> >
> > >> >> > Unfortunately there is no good way to tell whether the sink
> > >> >> > designer claims to have read CEA-861-F. The CEA extension block
> > >> >> > revision number has generally been stuck at 3 since forever,
> > >> >> > and even a very recently manufactured sink might be based on
> > >> >> > an old design so the manufacturing date doesn't seem like
> > >> >> > something we can use. In lieu of better information let's
> > >> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
> > >> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
> > >> >> >
> > >> >> > The alternative would of course be to always set YQ=0. And if
> > >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what
> > >> >> > we'll probably have to do.
> > >> >>
> > >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an
> > HDMI1.4
> > >> >> source?
> > >> >
> > >> > As long as you stick to < 340 MHz modes you shouldn't have to do
> > >> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.
> > >> >
> > >> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up
> > >> > to bridges/encoders to filter out most things that aren't supported?
> > >>
> > >> I had a patch for that at
> > >> https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run
> > >> into trouble with 4k monitors.
> > >
> > > Ack on the clock limiting patch, silly that it's stuck. No idea about
> > CEC,
> > > better for Hans/Boris I guess.
> >
> > Thanks!
> >

-- 
Ville Syrjälä
Intel OTC