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. -Daniel