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

From: Eric Anholt <eric@anholt.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Neil Kownacki <njkkow@gmail.com>,
	Jani Nikula <jani.nikula@intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
Date: Thu, 09 Nov 2017 10:16:10 -0800	[thread overview]
Message-ID: <874lq3l3md.fsf@anholt.net> (raw)
In-Reply-To: <20171109082612.kefdoxrr6c2dpq22@phenom.ffwll.local>

[-- Attachment #1.1: Type: text/plain, Size: 2060 bytes --]

Daniel Vetter <daniel@ffwll.ch> writes:

> On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:
>> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
>> 
>> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:
>> >> Ville Syrjala <ville.syrjala@linux.intel.com> writes:
>> >> 
>> >> > From: Ville Syrjälä <ville.syrjala@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!

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx