Ville Syrjälä <ville.syrj...@linux.intel.com> writes: > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: >> Ville Syrjala <ville.syrj...@linux.intel.com> writes: >> >> > From: Ville Syrjälä <ville.syrj...@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.
signature.asc
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
