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

neil k njkkow at gmail.com
Tue Nov 14 23:38:11 UTC 2017


I tested the patch from Ville Syrjälä's email and it works fine on top of
4.14 for me.

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!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20171114/383a5bc6/attachment.html>


More information about the dri-devel mailing list