From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt 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 Message-ID: <874lq3l3md.fsf@anholt.net> References: <20171108152504.12596-1-ville.syrjala@linux.intel.com> <87k1z0bk4n.fsf@anholt.net> <20171108204523.GJ10981@intel.com> <87zi7ws97v.fsf@anholt.net> <20171109082612.kefdoxrr6c2dpq22@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1518350558==" Return-path: In-Reply-To: <20171109082612.kefdoxrr6c2dpq22@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Neil Kownacki , Jani Nikula , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, stable@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org --===============1518350558== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Vetter writes: > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote: >> Ville Syrj=C3=A4l=C3=A4 writes: >>=20 >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: >> >> Ville Syrjala writes: >> >>=20 >> >> > From: Ville Syrj=C3=A4l=C3=A4 >> >> > >> >> > 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=3D0. >> >> > >> >> > The alternative would of course be to always set YQ=3D0. And if >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what >> >> > we'll probably have to do. >> >>=20 >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI= 1.4 >> >> source? >> > >> > As long as you stick to < 340 MHz modes you shouldn't have to do >> > anything. For >=3D340 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? >>=20 >> 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! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAloEm2sACgkQtdYpNtH8 nui5bg//T8XS6knOHzAU32v47LjHPvzsekz74NJJStJkvp9QqLxhAq9biOuLiuJK LSr5HW1Qw+/KlGbHoY0m3pAH81idzNS3xz2q7vboFg8TRCWgVCQb8vOrKFXAGhus qH1X9bHW+bx3vW1UBgCmY1CKxZvvDh7eBGlONluOsKXRvErQ2hIFV5Eb7Pyv30v2 mup7zv2JMfcwx0Yh2y81U9KiPNoE08cQDVjy5bG1YvygHlz+UwzMNp+tCFAnlwNF pF+CUSfD4Rs9U1SKUbqhjdWZ/8np1ll0ccl6/oZailig78fMX+FdjC1l5745HT7Y dGSULtFBgIE4hXHLCuFkStInqc++uo10vfsPWb7oXEoCl2Fr60zLuME/XXpq8MBo fmltx3PuxCdBr0YbEWPG9DZ31uDoDr4DE+owwjcEyYaPg8w+dzdmjmbTf5CnsQpd Jg0voQeMw/chKKnvblqa5PQSwgyNiWi8nKfGLzqARkqqDXH/i9UIz07UEvNmwt49 XYWgpkveFGy6HxtTnSIexbMNtntlJ8XTt7ePw7LUDXWNUw9B1iNlnT02ZK/M3ZKB hC2QGPVyytB64012tVNRXDztxY52mkwJP5Kjh2XyiEYIsQsHLtJf2vew6ZiMVicc TRZ6aq+e4qZ9HzAgYzR3E2cLzqBd58TYzxcD1gAQeAoXrQeTPCs= =HDSZ -----END PGP SIGNATURE----- --=-=-=-- --===============1518350558== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1518350558==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from anholt.net ([50.246.234.109]:35672 "EHLO anholt.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346AbdKISQN (ORCPT ); Thu, 9 Nov 2017 13:16:13 -0500 From: Eric Anholt To: Daniel Vetter Cc: Ville =?utf-8?B?U3lyasOkbMOk?= , Jani Nikula , intel-gfx@lists.freedesktop.org, Neil Kownacki , stable@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks In-Reply-To: <20171109082612.kefdoxrr6c2dpq22@phenom.ffwll.local> References: <20171108152504.12596-1-ville.syrjala@linux.intel.com> <87k1z0bk4n.fsf@anholt.net> <20171108204523.GJ10981@intel.com> <87zi7ws97v.fsf@anholt.net> <20171109082612.kefdoxrr6c2dpq22@phenom.ffwll.local> Date: Thu, 09 Nov 2017 10:16:10 -0800 Message-ID: <874lq3l3md.fsf@anholt.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Sender: stable-owner@vger.kernel.org List-ID: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Vetter writes: > On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote: >> Ville Syrj=C3=A4l=C3=A4 writes: >>=20 >> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: >> >> Ville Syrjala writes: >> >>=20 >> >> > From: Ville Syrj=C3=A4l=C3=A4 >> >> > >> >> > 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=3D0. >> >> > >> >> > The alternative would of course be to always set YQ=3D0. And if >> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what >> >> > we'll probably have to do. >> >>=20 >> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI= 1.4 >> >> source? >> > >> > As long as you stick to < 340 MHz modes you shouldn't have to do >> > anything. For >=3D340 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? >>=20 >> 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! --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAloEm2sACgkQtdYpNtH8 nui5bg//T8XS6knOHzAU32v47LjHPvzsekz74NJJStJkvp9QqLxhAq9biOuLiuJK LSr5HW1Qw+/KlGbHoY0m3pAH81idzNS3xz2q7vboFg8TRCWgVCQb8vOrKFXAGhus qH1X9bHW+bx3vW1UBgCmY1CKxZvvDh7eBGlONluOsKXRvErQ2hIFV5Eb7Pyv30v2 mup7zv2JMfcwx0Yh2y81U9KiPNoE08cQDVjy5bG1YvygHlz+UwzMNp+tCFAnlwNF pF+CUSfD4Rs9U1SKUbqhjdWZ/8np1ll0ccl6/oZailig78fMX+FdjC1l5745HT7Y dGSULtFBgIE4hXHLCuFkStInqc++uo10vfsPWb7oXEoCl2Fr60zLuME/XXpq8MBo fmltx3PuxCdBr0YbEWPG9DZ31uDoDr4DE+owwjcEyYaPg8w+dzdmjmbTf5CnsQpd Jg0voQeMw/chKKnvblqa5PQSwgyNiWi8nKfGLzqARkqqDXH/i9UIz07UEvNmwt49 XYWgpkveFGy6HxtTnSIexbMNtntlJ8XTt7ePw7LUDXWNUw9B1iNlnT02ZK/M3ZKB hC2QGPVyytB64012tVNRXDztxY52mkwJP5Kjh2XyiEYIsQsHLtJf2vew6ZiMVicc TRZ6aq+e4qZ9HzAgYzR3E2cLzqBd58TYzxcD1gAQeAoXrQeTPCs= =HDSZ -----END PGP SIGNATURE----- --=-=-=--