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: Wed, 08 Nov 2017 14:21:08 -0800 Message-ID: <87zi7ws97v.fsf@anholt.net> References: <20171108152504.12596-1-ville.syrjala@linux.intel.com> <87k1z0bk4n.fsf@anholt.net> <20171108204523.GJ10981@intel.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Return-path: In-Reply-To: <20171108204523.GJ10981@intel.com> Sender: stable-owner@vger.kernel.org To: Ville =?utf-8?B?U3lyasOkbMOk?= Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, stable@vger.kernel.org, Jani Nikula , Neil Kownacki List-Id: intel-gfx@lists.freedesktop.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ville Syrj=C3=A4l=C3=A4 writes: > 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 HDMI1.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? I had a patch for that at https://patchwork.freedesktop.org/series/30680/ -- fedora folks had run into trouble with 4k monitors. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAloDg1UACgkQtdYpNtH8 nuj+eg/8De2+buSMLAGlKj4jt11M2cD5fINVQ8Why0NkB/X1ecE6OjOx+juYIi8y +D2/n44ynU2m88aF9T10o1PGNOQnM7gXgJHg9Cj6KPcmkeLH2ZGR1m+164WX1lti 6NCkIPr6p18PsuvS+ur2Cob26r8HeG1Sxvgm2IHMDQL3Z0tFJ/oCNNAIp2A546Sz D116B/3Ug1gRg0CTCHuG8ebvm5ABx0O2pRZq2IaSUIC0eHzWv/oMyc9l+PHo993d v0a9hdQlYPGfFLztjZDWq/n2KpTAG4MNcLkWuIVxFiOnzRLe8dyMWzNGRVGh7Pvq nzysm93CvYnOjrmZ+v3RdQCHZou10L67s/p2dwotE2YHgxiOziHunAT/Vy//lcQQ gvDeVydAMAXIe+JXkpUDpNwttQJmxB3sMsPzYMXOQBEsGD7wxyDkc4vlU0M184JX bjqcEwm50Jz2LKNzbR8cgfCIr61teXv2xVVUFVLzd4JZ55wxR9ggkkxwetwrixAc +7QJlrhKuHD7oaPT6G8mgXyMVktw4kJ3aYiWYMRhmpF+yErMh3+fqcsDsKXIuXIC gf+KjgdYjxdJzxUz9cP7RItq9FUQW/VJ4yb2/b6lu+s5R7hg0YnGm72XN31DacAJ 4TTU7hd/qNzvU5AJbcJ1vAoDucmZ/r20ko9Rl8epMcojZyMTHJw= =yHMw -----END PGP SIGNATURE----- --=-=-=--