[Bug 91434] [IVB/HSW] 23.976Hz & 24Hz modes broken on dual-display with recent (4.0.x) kernels

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91434

--- Comment #37 from Ville Syrjala <ville.syrjala at linux.intel.com> ---
(In reply to Martin Andersen from comment #36)
> (In reply to Ville Syrjala from comment #35)
> > (In reply to Martin Andersen from comment #34)
> > > 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.

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

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

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.

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

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.

> But surely there is a flag to disable this in the driver, so it can be ruled
> out on a definitive basis?

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

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

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20171019/d2d83488/attachment-0001.html>