<div dir="ltr"><div><div>I tested the patch from Ville Syrjälä's email and it works fine on top of 4.14 for me.<br><br></div>Thanks,<br></div>Neil<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 9, 2017 at 1:16 PM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Daniel Vetter <<a href="mailto:daniel@ffwll.ch">daniel@ffwll.ch</a>> writes:<br>
<br>
> On Wed, Nov 08, 2017 at 02:21:08PM -0800, Eric Anholt wrote:<br>
>> Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a><wbr>> writes:<br>
>><br>
>> > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote:<br>
>> >> Ville Syrjala <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a><wbr>> writes:<br>
>> >><br>
>> >> > From: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a><wbr>><br>
>> >> ><br>
>> >> > Apparently some sinks look at the YQ bits even when receiving RGB,<br>
>> >> > and they get somehow confused when they see a non-zero YQ value.<br>
>> >> > So we can't just blindly follow CEA-861-F and set YQ to match the<br>
>> >> > RGB range.<br>
>> >> ><br>
>> >> > Unfortunately there is no good way to tell whether the sink<br>
>> >> > designer claims to have read CEA-861-F. The CEA extension block<br>
>> >> > revision number has generally been stuck at 3 since forever,<br>
>> >> > and even a very recently manufactured sink might be based on<br>
>> >> > an old design so the manufacturing date doesn't seem like<br>
>> >> > something we can use. In lieu of better information let's<br>
>> >> > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is<br>
>> >> > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.<br>
>> >> ><br>
>> >> > The alternative would of course be to always set YQ=0. And if<br>
>> >> > we ever encounter a HDMI 2.0+ sink with this bug that's what<br>
>> >> > we'll probably have to do.<br>
>> >><br>
>> >> Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4<br>
>> >> source?<br>
>> ><br>
>> > As long as you stick to < 340 MHz modes you shouldn't have to do<br>
>> > anything. For >=340 MHz you'd need to use some new HDMI 2.0 features.<br>
>> ><br>
>> > Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up<br>
>> > to bridges/encoders to filter out most things that aren't supported?<br>
>><br>
>> I had a patch for that at<br>
>> <a href="https://patchwork.freedesktop.org/series/30680/" rel="noreferrer" target="_blank">https://patchwork.freedesktop.<wbr>org/series/30680/</a> -- fedora folks had run<br>
>> into trouble with 4k monitors.<br>
><br>
> Ack on the clock limiting patch, silly that it's stuck. No idea about CEC,<br>
> better for Hans/Boris I guess.<br>
<br>
</div></div>Thanks!<br>
</blockquote></div><br></div>