[Intel-gfx] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed Nov 8 20:45:23 UTC 2017
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?
>
> That said, as far as vc4, this patch is
>
> Acked-by: Eric Anholt <eric at anholt.net>
Ta.
--
Ville Syrjälä
Intel OTC
More information about the Intel-gfx
mailing list