<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - [IVB/HSW] 23.976Hz & 24Hz modes broken on dual-display with recent (4.0.x) kernels"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=91434#c37">Comment # 37</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - [IVB/HSW] 23.976Hz & 24Hz modes broken on dual-display with recent (4.0.x) kernels"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=91434">bug 91434</a>
              from <span class="vcard"><a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> <span class="fn">Ville Syrjala</span></a>
</span></b>
        <pre>(In reply to Martin Andersen from <a href="show_bug.cgi?id=91434#c36">comment #36</a>)
<span class="quote">> (In reply to Ville Syrjala from <a href="show_bug.cgi?id=91434#c35">comment #35</a>)
> > (In reply to Martin Andersen from <a href="show_bug.cgi?id=91434#c34">comment #34</a>)
> > > There is no DP-HDMI dongle involved. The output is fed directly from a
> > > MacBook Retina system via full-size/regular HDMI cable. (Yes, I've also
> > > noticed it says DP.)
> > 
> > That just means the DP++ chip is likely soldered onto the motherboard. It's
> > definitely somewhere because it answers when we talk to it.

> As mentioned earlier, the exact same issue occurs with an Ivy Bridge system
> -with no DP output or chip - alongside the other two systems tested on.</span >

Well, it's definitely not a generic IVB/HSW issue since deep color works just
fine here on both.

<span class="quote">> 
> The sole reason a MacBook is being used is purely for practical reasons. 

> The MacBook also behaves correctly using older kernels, which should
> eliminate any perceived Apple-weirdness causing this.</span >

Like I said, older kernels didn't use deep color, so comparisons with older
kernels don't really prove anything beyond deep color being the likely problem
here.

<span class="quote">> 
> > > However; the exact same setup works 100% correctly with older kernels, as
> > > outlined earlier in the ticket. By 100% i mean: never any picture dropouts,
> > > never any dots (which only were seen with this most recent kernel) or other
> > > graphical glitches.
> > 
> > That's probably because older kernels only did 8bpc, whereas newer ones do
> > 12bpc whenever possible.

> Maybe, though I doubt it. Why then do the other modes work? I have sent Deep
> Color signals to the PJ before but frankly see no reason for this.</span >

They work because they require less bandwidth, and thus we drive it a lower
clock rate, which makes it less sensitive to noise and whatnot.

<span class="quote">> But surely there is a flag to disable this in the driver, so it can be ruled
> out on a definitive basis?</span >

Not currently. There are some patches now being proposed though
<a href="https://patchwork.freedesktop.org/series/32251/">https://patchwork.freedesktop.org/series/32251/</a>
You may want to give those a try.

<span class="quote">> 
> > > I have three other sources hooked up to this projector, and none have
> > > issues.
> > 
> > Can you tell whether any of them do 12bpc HDMI output, or just 8bpc?

> The sources are 2x PS3s and one Blu-Ray player, all of which are capable of
> 12bpc.

> > > The same behaviour is seen when hooked up directly to either of the
> > > projector's two HDMI ports - with another cable - as well. So I believe
> > > 'cabling issues' can be ruled out.
> > 
> > The cables aren't unusually long are they?
> >
> > It's definitely possible that the signal degradation happens either in the
> > source of sink side. I could almost excuse the source side for not being
> > tested to handle 12bpc iff Apple's own driver always uses 8bpc and they
> > didn't expect anyone to install another OS on the thing. If the problem is
> > in the projector then I think it's less excusable, and they should have
> > tested to make sure the device works with the maximum TMDS clock it's
> > advertising to the source.

> I feel the focus on what is causing this is entirely misguided. As mentioned
> before, testing has been performed when the source has been hooked up
> directly to the PJ (using a 6ft cable), with the same issues.

> But I'd like to emphasize: the same cabling has been used since 2012 without
> any issues what-so-ever relating to signal dropouts or interference on
> either 60/50Hz or 23.976/24Hz material - both in 2D and 3D. This is from a
> total of six sources: two PS3s, one Blu-Ray player, one analog-to-digital
> converter+upscaler (to 1080p50), and two DVB set-top boxes. (Hope this
> information does not not lead to a 'your cables are too old', 'your system
> too complex' comment) ;)

> This is also the fourth projector which is hooked up to this IVB system - if
> there was something even sligthly strange relating to cabling it surely
> would have been detected at a significantly earlier stage.

> But to re-iterate, all of the above cabling has been bypassed and the system
> hooked up directly. It is therefore with high probability *not* cabling
> related.</span >

OK. Then it seems likely to be a weakness in the source devices. But as stated
IVB/HSW in general are perfectly capable of working deep color output, so this
must be something specific with those machines. Either poor signal quality on
the main board itself (crappy level shifters, bad signal routing etc.). Or it
might be a problem with the system firmware not telling us to use decent
voltage/pre-emphasis settings on the HDMI output.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>