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

added Community Enhancement feature: display/HDMI platform: HSW platform: IVB priority::low + 1 deleted label

Martin Andersen uploaded an attachment:

Attachment 117302, "Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 1 of 3":
xf86-video-intel-debug-2.99.917.nonworking.4.0.9-01.txt.xz

Martin Andersen uploaded an attachment:

Attachment 117303, "Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 2 of 3":
xf86-video-intel-debug-2.99.917.nonworking.4.0.9-02.txt.xz

Martin Andersen uploaded an attachment:

Attachment 117304, "Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 3 of 3":
xf86-video-intel-debug-2.99.917.nonworking.4.0.9-03.txt.xz

Martin Andersen uploaded an attachment:

Attachment 117305, "Xorg debug output from correctly-working 3.13.5 kernel running xf86-video-intel driver 2.99.917":
xf86-video-intel-debug-2.99.917.working.3.13.5.txt.xz

Jani Nikula @jani said:

Can you bisect, please?

Martin Andersen said:

That is a little outside of my scope and I will leave that to the capable people at Intel. The issue started appearing between 3.18.5 and 4.0.2. The bug should not be hard to track down, as it is not something that happens intermittently and not exactly subtle.

Ville Syrjälä @vsyrjala said:

Can't do much with xorg logs here. Please provide dmesg with drm.debug=0xe enabled for both the successful and failing cases.

Martin Andersen uploaded an attachment:

Attachment 117878, "drm.debug=0xe from working 3.13.5 kernel":
dmesg-3.13.5-working.txt

Martin Andersen uploaded an attachment:

Attachment 117879, "drm.debug=0xe from nonworking 4.0.9 kernel":
dmesg-4.0.9-nonworking.txt

Martin Andersen said:

Added two attachments, the first from a correctly-working 3.13.5 and the second with a 4.0.9 kernel exhibiting the bug.

Steps performed after boot:

3.15.5:

$ xrandr -q
$ xrandr --output HDMI2 --rate 24 (HDMI2 switches refreshrate correctly)
$ xrandr --output HDMI2 --rate 23.976 (HDMI2 switches refreshrate correctly)

4.0.9:

$ xrandr -q
$ xrandr --output HDMI2 --rate 24 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 23.976 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 60 (display being output on HDMI2)

<logout from main DE to non-compositing WM>

$ xrandr --output HDMI2 --rate 24 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 23.976 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 60 (display being output on HDMI2)

Martin Andersen said:

Let me know if additional info is needed.

Ville Syrjälä @vsyrjala said:

(In reply to Martin Andersen from comment 10)

Added two attachments, the first from a correctly-working 3.13.5 and the
second with a 4.0.9 kernel exhibiting the bug.

Steps performed after boot:

3.15.5:

$ xrandr -q
$ xrandr --output HDMI2 --rate 24 (HDMI2 switches refreshrate
correctly)
$ xrandr --output HDMI2 --rate 23.976 (HDMI2 switches refreshrate
correctly)

4.0.9:

$ xrandr -q
$ xrandr --output HDMI2 --rate 24 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 23.976 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 60 (display being output on HDMI2)

<logout from main DE to non-compositing WM>

$ xrandr --output HDMI2 --rate 24 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 23.976 (blank screen on HDMI2)
$ xrandr --output HDMI2 --rate 60 (display being output on HDMI2)

Did you grab the logs after performing these steps? I'm not seeing any of these modesets in either log.

Martin Andersen said:

All the logs were grabbed after booting into 3.13.5 (working) and 4.0.9 (nonworking) with the drm.debug=0xe kernel option set using a custom xf86-video-intel Xorg compiled with '--enable-debug=full' and doing the steps outlined above.

What specific log information are you missing (i.e, what do I need to check the presence for in the log files in case they have been truncated due to the attachment size limits?)

I did take care to include everything that was produced for the nonworking 4.0.9 kernel (three compressed chunks of ~2Mb each)

After some digging around however, I managed to find the original log for the 4.0.9 kernel, which I've made available here:

https://www.dropbox.com/s/7e80kcf9pnuqtyj/kernel-4.0.x-dualoutput-issue.Xorg.0.log.xz?dl=0

I can understand that some information might be missing from the 3.13.5 output (63K compressed), but not the other kernel. Is it possible this information is omitted despite the drm.debug option being set?

Thanks for looking into this, btw. (although it took some time;)

Martin Andersen said:

Reinstalled system to 14.04.3 to eliminate any quirks and re-ran tests w/ drm.debug=0xe and xf86-video-intel driver (2.99.917), compiled with '--enable-debug=full' using three kernel revisions as a base:

The previously known-good 3.13.5
The 14.04.3 default kernel 3.19.0
Current bleeding edge 4.4.4 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.4-wily/

Steps performed:

System booted w/ extra kernel flags, user logged in and modes for HDMI2 are attempted modified as follows:

- Switch HDMI2 to 24Hz
- Switch HDMI2 to 30Hz
- Switch HDMI2 to 50Hz
- Switch HDMI2 to 60Hz (default)

Desktop envs tested are plain Gnome (non-DE) session, MATE session (worked perfectly in 3.13.5 & 3.18.5 (on 2nd IVB system) and XFCE4. They all behave the same.

Results:

3.13.5:

All modes are switched correctly. Subsequently an extra step is performed; starting Kodi and launching a movie in 24Hz-> plays correctly. No 23.976 mode tested as it requires a custom modeline (never worked OOB on Intel for either systems)

3.19.0:

Only the 60Hz mode is output. The rest produce no signal.

4.4.4:

Same as 3.19, with the exception of graphical artifacts (green pixel dots) randomly showing in the output.

Logs: (Dropboxed as it's a PITA to upload these to freedesktop due to its low size limits)

3.13.5:
syslog: https://www.dropbox.com/s/cvbd8l8zmb3x8hg/syslog-3.13.5.working.txt.xz?dl=0
Xorg.0.log: https://www.dropbox.com/s/60um14d14qushoc/xorg.0.log.3.13.5.working.txt.xz?dl=0

3.19.0:
syslog: https://www.dropbox.com/s/auci5afmo4cid38/syslog-3.19.0.defunct.txt.xz?dl=0
Xorg.0.log: https://www.dropbox.com/s/dhsokec7hgz0ttj/xorg.0.log.3.19.0.defunct.txt.xz?dl=0

4.4.4:

syslog: https://www.dropbox.com/s/nztrvartf10u6dm/syslog-4.4.4.defunct.txt.xz?dl=0
Xorg.0.log: https://www.dropbox.com/s/02j3tdlhld4d2f6/xorg.0.log.4.4.4.defunct.txt.xz?dl=0

I sincerely hope enough debug output has now been provided in order to properly diagnose the issue (it took most of my day to get the new test platform up and running.)

Martin Andersen said:

Hi,

I need to ask for a confirmation that the required debug information now has been received, and Intel is able to diagnose the issue. The bug was reported in July of last year; and I am hoping that it doesn't take another six months to ask for additional information (previous tests were performed and submitted in September 2015, after which the bug went silent up until now.)

I appreciate it is being looked into–but would expect it to be a little closer to being resolved at some point, as I cannot be the only person running 23.976 on a secondary display.

--Martin

Martin Andersen said:

Same issue with 4.8.1-040801 (from Oct 7th) on Ivy Bridge, HD4000 using the std. packaged kernel from kernels.ubuntu.org

Screens get detected as usual, and xrandr prints all modes. Output is fine on HDMI1, but not HDMI2 - which is going to my projector.

This affects not just the 23.976Hz modes and the 24Hz modes, but regular 60Hz & 50Hz modes as well. Everything switches as usual, but /no/ signal is received.

The only similar issue I have found is;

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

However this was affecting the VGA output, not HDMI. But it suggests to me that the issue might be EDID / modeline related, as the problem does not occur on either of the monitors I have tested (none of which have 24Hz capability, so unfortunately I have only been able to test 60Hz).

xrandr from working setup (also see attachment for the verbose xrandr output which contains EDID information). See other attachments for 'drm=0xe' debugging information.

xrandr -q:

Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 32767 x 32767
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 59.6+ 60.0 59.6
1920x1080 60.0 60.2
1600x1200 60.0 60.1
1280x1024 76.0 76.0 75.0 60.0 60.0 60.0
1152x921 66.0 66.0
1152x864 75.0
1024x768 75.1 75.0 70.1 60.0
832x624 74.6 74.5
800x600 72.2 75.0 60.3 56.2
640x480 75.0 72.8 75.0 72.8 66.7 60.0 60.0
720x400 70.1
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 1600mm x 900mm
1920x1080 60.0*+ 50.0 59.9 24.0 24.0
1920x1080@60edid 60.0
1920x1080@50edid 50.0
1920x1080@59.94p 59.9
1920x1080@25p 25.0
1920x1080i@60 30.0
1920x1080i@50 25.0
1920x1080@24.000 24.0
1920x1080i 30.0 25.0 30.0
1920x1080@23.97610 24.0
1280x720@60 60.0
1280x720@50 50.0
1280x720 60.0 50.0 59.9
1440x576@50 50.0
1440x576 50.0
1440x576i@50 25.0
1440x480 60.0 59.9
1440x480@59.9 59.9
1440x480i@59.9 30.0
720x576@50 50.0
720x576 50.0
720x576i 25.0
720x480 60.0 59.9
720x480@59.9 59.9
720x480i 30.0 30.0
640x480@60 60.0 60.0
640x480 60.0 59.9
640x480@59.9 60.0
DP2 disconnected (normal left inverted right x axis y axis)

Monitor section of xorg.conf which contains ModeLines being used (has also been tested without hardcoding modeline.

Modeline "1920x1080@23.97610" is the one which is providing "true" 23.976Hz (never gets auto-probed)

/etc/X11/xorg.conf

[...]
Section "Monitor"
Identifier "Epson PJ"
VendorName "Epson"
ModelName "TW9000"

HorizSync 15.0 - 92.0
VertRefresh 23.0 - 85.0

ModeLine "1920x1080@25p" 74.400 1920 2448 2492 2622 1080 1084 1089 1135 +hsync +vsync

ModeLine "1920x1080@59.94p" 148.352 1920 1960 2016 2200 1080 1082 1088 1125

Modeline "1920x1080@60edid" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync # commented earlier
Modeline "1920x1080i@60" 74.25 1920 2008 2052 2200 1080 1084 1094 1125 interlace +hsync +vsync
Modeline "1920x1080@50edid" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
Modeline "1920x1080i@50" 74.25 1920 2448 2492 2640 1080 1084 1094 1125 interlace +hsync +vsync # commented earlier
Modeline "1920x1080@24.000" 74.25 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync

Modeline "1920x1080@23.97610" 74.230 1920 2560 2604 2752 1080 1084 1089 1125 +hsync +vsync

Modeline "1280x720@60" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync
Modeline "1280x720@50" 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync
Modeline "1440x576@50" 54.00 1440 1464 1592 1728 576 581 586 625 -hsync -vsync
Modeline "1440x576i@50" 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync
Modeline "1440x576i@50" 27.00 1440 1464 1590 1728 576 580 586 625 interlace -hsync -vsync
Modeline "1440x480@59.9" 54.00 1440 1472 1596 1716 480 489 495 525 -hsync -vsync
Modeline "1440x480i@59.9" 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync
Modeline "1440x480i@59.9" 27.00 1440 1478 1602 1716 480 488 494 525 interlace -hsync -vsync
Modeline "720x576@50" 27.00 720 732 796 864 576 581 586 625 -hsync -vsync
Modeline "720x480@59.9" 27.00 720 736 798 858 480 489 495 525 -hsync -vsync
Modeline "640x480@60" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync
Modeline "640x480@60" 25.18 640 656 752 800 480 490 492 525 -hsync -vsync
Modeline "640x480@59.9" 25.18 640 656 752 800 480 490 492 525 -hsync -vsync

EndSection

Martin Andersen uploaded an attachment:

Attachment 127342, "xrandr -v from working (3.18.5) setup":
xrandr-v.txt

Martin Andersen uploaded an attachment:

Attachment 127399, "drm.debug=0xe from 4.8.1 Haswell system. First with xserver-xorg-video-intel 2.99.917 (no 23.976Hz), revert to 2.21.9: working 23.976Hz mode":
syslog-4.8.1-2.99.917+2.21.9-revert.txt.xz

Martin Andersen uploaded an attachment:

Attachment 127400, "drm.debug=0xe from 4.8.1 Haswell system. First with xserver-xorg-video-intel 2.99.917 (no 23.976Hz), revert to 2.21.9: working 23.976Hz mode - Xorg.0.log":
Xorg.0.log-4.8.1-2.99.917+2.21.9-revert.txt.xz

Martin Andersen uploaded an attachment:

Attachment 127401, "drm.debug=0xe from 4.8.1 Haswell system. Using 2.99.917 xserver-xorg-video-intel drv. which intermittently produce no signal during switching (assuming to the 23.976Hz mode)":
syslog-4.8.1-2.99.917-intermittently-no-signal.txt.xz

Martin Andersen uploaded an attachment:

Attachment 127402, "drm.debug=0xe from 4.8.1 Haswell system. Using 2.99.917 xserver-xorg-video-intel drv. which intermittently produce no signal during switching (assuming to the 23.976Hz mode) - Xorg.0.log":
Xorg.0.log-4.8.1-2.99.917-intermittently-no-signal.txt.xz

Martin Andersen said:

Added more drm.debug=0xe output from my Haswell test system.

In short; the xorg.conf provided 23.976Hz mode (Modeline "1920x1080@23.97610" 74.230 1920 2560 2604 2752 1080 1084 1089 1125 +hsync +vsync) never works with any recent kernel/xserver-xorg-video-intel combo.

On 4.x the 2.99.917 driver is never able to select the mode, outputting everything in 24.000Hz. Moreover, half the time it tries to select the mode the secondary screen (HDMI2, going to the Epson PJ), goes blank. From the logs everything is switched fine, but the signal being output is incompatible with the display.

When reverting to the (ancient) 2.21.9 version of xserver-xorg-video-intel (intel_drv.so) - the Haswell system is able to switch to the provided 23.976Hz mode.

Has there been some changes wrt. mode-validation / edid-probing with the newer 2.99.x drivers? It almost appears so, since despite my numerous tests I cannot get the correct mode to work with them.

Martin Andersen said:

Guys, let's at least try to solve this thing. It's been sitting around for over a year and is impacting basic functionality. I can provide further logs or do additional testing if needed, but I need some input from the devs.

The issue has been verified on three different systems - of which two are Haswell-based and one is Ivy Bridge, so something has definitely changed wrt. how the signal is being output on the secondary display to the projector on both the driver and kernel level.

Jari Tahvanainen said:

Martin - we have neglected this bug waaaayyy too long, apologies.

Do you still have this problem with the latest kernel (preferable from drm-tip) + video-intel ?
Also wondering if this might be related to bug 90128.

Martin Andersen said:

Jari,

Thanks for the resurrection. ;)

This longstanding issue does look quite similar to https://bugs.freedesktop.org/show_bug.cgi?id=90128 - yes. Although that bug is reported as being specific to Haswell, whereas this occurs on both Ivy Bridge and Haswell - and possibly others (Sandy Bridge) Or it could obviously be that the person reporting only has a Haswell system to test on.

Anyway; I will try the latest 4.11.0-994-* from drm-tip this weekend, and boot the system with drm.debug=0xe. Hopefully I'll have time to test on both Haswell & Ivy Bridge so we can get to the bottom of this sucker.

Looks like xf86-video-intel is still on the 2.99.917 version. (Good, as I don't have to build a package for that as well.)

Would be interesting to see whether the output is still completely blank, or if it instead produces the vertical banding reported in bug 90128. (I'm guessing blank, as the projector only accepts a certain number of validated modes..)

Martin Andersen said:

Ok - well, this was interesting. Now the situation as initially reported in the bug is reversed: 24.00Hz & 23.976Hz modes work(!), however 50 & 60Hz modes (which previously were the only ones to be outputted) do not. No output is seen from the virtual terminal either.

Including debug output from my Haswell-based system. The steps taken after boot are as follows:

martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 24
(works!)

martin@meraxes ~ $ xrandr -q

martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
(works!)

martin@meraxes ~ $ xrandr -q
martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 60
(no signal)

martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 50
(no signal)

martin@meraxes ~ $ xrandr -q
martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 30
(30Hz, curiously, also works)

martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 59.9
(no signal)

martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
(works)

martin@meraxes ~ $ xrandr -q
martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 50
(no signal after trying to switch for 10 secs)

martin@meraxes ~ $ xrandr -q
martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 24
(works)

martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 60
(no signal)

martin@meraxes ~ $ xrandr -q
martin@meraxes ~ $ xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
(works)

The 23.976Hz mode is the rightmost on the 1920x1080 list given by xrandr;

$ xrandr -q

HDMI2 connected 1920x1080+2560+0 (normal left inverted right x axis y axis) 0mm x 0mm
1920x1080 60.0 + 50.0 59.9 24.0 24.0*
1920x1080i 60.1 50.0 60.0
1280x720 60.0 50.0 59.9
1440x576 50.0
1440x480 60.0 59.9
720x576 50.0
720x576i 50.1
720x480 60.0 59.9
720x480i 60.1 60.1
640x480 60.0 59.9
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

Martin Andersen uploaded an attachment:

Attachment 130632, "drm.debug=0xe from 4.11.0-994 (201703292316) on Haswell system. Using 2.99.917 xserver-xorg-video-intel drv. 23.976Hz + 24.000Hz modes do work, while 50+60Hz modes do not":
syslog-4.11.0-994-201703292316.drm-tip.txt

Martin Andersen said:

I will probably be able to do some more testing this weekend, so let me know if additional debug output is needed, or whether there are any drm kernel test builds to try, with relevant changes. (I omitted the Xorg output as that did not seem to be of interest before, and since the system also produces no output from the virtual terminal during boot)

To me it seems like the issue has been attempted to be worked around, since it cannot be a coincidence that the 23.976Hz + 24.00Hz modes now work, perhaps due to more lenient modevalidation for those? If so is the case, one should be able to implement these changes for the 'regular' 50+60Hz modes as well. Or maybe I am being too optimistic..

Martin Andersen said:

Please let me know if there is sufficient information to debug the issue, or whether further testing is needed, which I would be happy to do.

Martin Andersen said:

Let me know if there have been any drm fixes which could address this issue, specifically the probing/modevalidation of the 50 + 60Hz modes on the projector; and if further testing is required on my part. It appears special handling has been added for 23.976 & 24Hz which also need to be applied for the regular monitor refresh rates for this to work.

Please don't let this issue die again now that it appears so close to being resolved.

Martin Andersen uploaded an attachment:

Attachment 132027, "drm.debug=0xe from 4.12.0-994_4.12.0-994.201706170150 on Haswell system. Using 2.99.917 xserver-xorg-video-intel drv. 23.976Hz + 24.000Hz modes work, while 50+60Hz modes do not":
syslog-4.12.0-994_4.12.0-994.201706170150.txt

Martin Andersen said:

Did some further testing today (wondering why I still bother as this has now been broken for two whole years), and Intel apparently has utter disregard for its customers.

Tested with the latest kernel from drm-tip, 4.12.0-994_4.12.0-994. 50 & 60Hz modes only work intermittently, and with an erratic picture and white dots showing.

Reverting to either the 24.000Hz or 23.976Hz modes produces a stable picture.

The issue with intermittent output is also present during boot/KMS, indicating it is probably not an Xorg issue.

Modes tested after boot:

988 18-Jun-2017 15:10:34 xrandr -q
990 18-Jun-2017 15:11:05 xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
991 18-Jun-2017 15:11:21 xrandr -q

993 18-Jun-2017 15:11:33 xrandr --output HDMI2 --mode 1920x1080 --rate 60
994 18-Jun-2017 15:11:57 xrandr --output HDMI2 --mode 1920x1080 --rate 50
995 18-Jun-2017 15:12:20 xrandr --output HDMI2 --mode 1920x1080 --rate 24
996 18-Jun-2017 15:12:56 xrandr --output HDMI2 --mode 1920x1080 --rate 60
997 18-Jun-2017 15:13:30 xrandr --output HDMI2 --mode 1920x1080 --rate 50
998 18-Jun-2017 15:14:02 xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
999 18-Jun-2017 15:14:15 xrandr --output HDMI2 --mode 1920x1080 --rate 50
1000 18-Jun-2017 15:14:35 xrandr --output HDMI2 --mode 1920x1080 --rate 60

Kernel debug output with drm.debug=0xe is included as per usual. Maybe it is of usage to /dev/null

Ville Syrjälä @vsyrjala said:

(In reply to Martin Andersen from comment 32)

Tested with the latest kernel from drm-tip, 4.12.0-994_4.12.0-994. 50 & 60Hz
modes only work intermittently, and with an erratic picture and white dots
showing.

Reverting to either the 24.000Hz or 23.976Hz modes produces a stable picture.

Jun 18 15:11:33 meraxes kernel: [ 179.206299] [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 2 HDMI) detected (max TMDS clock: 300000 kHz)
Jun 18 15:11:33 meraxes kernel: [ 179.206401] [drm:drm_add_edid_modes.part.24 [drm]] HDMI: DVI dual 0, max TMDS clock 225000 kHz
Jun 18 15:11:33 meraxes kernel: [ 179.219332] [drm:intel_dump_pipe_config [i915]] crtc timings: 148500 1920 2008 2052 2200 1080 1084 1089 1125, type: 0x0 flags: 0x5
Jun 18 15:11:33 meraxes kernel: [ 179.219362] [drm:intel_dump_pipe_config [i915]] port clock: 222750, pipe src size: 1920x1080, pixel rate 148500

So both the projector and the DP->HDMI dongle are telling is that we can do 12bpc for 1080p @ 60hz, but the unstable picture is telling us something different. I suspect the problem is with the dongle, the cable, or the projector. Do you have other cables/dongles you can try?

Martin Andersen said:

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

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.
The main production system (on IVB) currently runs 3.18.5; it behaves the same with all recent kernel branches also.

I did quite a bit of testing earlier, on two Haswell-based systems and one Ivy Bridge, with kernels ranging from 4.0.9, 4.8.1, 4.11.0 and most recently 4.12.0. They all exhibit consistent behaviour->none work correctly with dual-display under any recent kernel.

Bear in mind that the unstable picture reported with this kernel from Jun 17th 2017 was not an issue with the prior ones, where it produced a stable 50&60Hz picture (but no 23.976 or 24.000Hz (hence the title of this bug report) - which led me to believe someone excplictly tried to fix the film modes between 4.11 & 4.12), but breaking the others in the process (for dual-screen setups).

I have three other sources hooked up to this projector, and none have issues.
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.

Ville Syrjälä @vsyrjala said:

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

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

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

Martin Andersen said:

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

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.

The only strange issue observed with the MacBook is an apparent bug in the Intel driver which, when setting drm.debug=0xe causes the backlight setting to be inverted(!) (regardless of being hooked up to an external output or not). That obviously belongs in a separate bug report.

Nevertheless, I recently tested 4.13.2 (201709132057) on the (main) IVB system and observed the same issue with no signal from both the 50 and 60Hz modes. Nothing during kernel boot, nothing from X.

However, I did not produce (yet another) debug output as it was pretty much identical to the ones provided before, and since this bug appeared to be abandoned (which I am glad is not apparently the case)

After this I tried 3.18.71 (#201709132337) – which worked without issues. So I assume none of the drm stuff is backported to this branch. (Thankfully)

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

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

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

Ville Syrjälä @vsyrjala said:

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

Jani Saarinen @jani.saarinen said:

First of all. Sorry about spam.
This is mass update for our bugs.

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Martin Andersen said:

This bug is still very much relevant. I just tested this again under 4.16.11, and it still behaves in the exact same manner as previously reported. This was on the IVB system, not the HSW system I tested on previously. However, the results (or lack thereof) were identical.

I had some (albeit minor) hopes that the 12bpc validation patches which went in a while ago would solve this (if the error is indeed related to this, as previously suggested). Since there apparently is no option to disable 12bpc or force 8bpc, it is impossible to tell with any certainly whether that is the case.

[btw.-I did look at the proposed patches to force a certain bits per channel, 'force_bpc', but I cannot see that these made it into the i915 driver as it was not a valid parameter to the module]

The behaviour is as follows (same as reported earlier)

50 & 60Hz modes show no output whatsoever on the second display. Nothing during boot (KMS/console), nothing after X-server startup. Output on the primary LCD (HDMI1) is working without any issues.

- The 23.976Hz and 24.000Hz modes are garbled, both showing rectangular patters and intermittent static.

The source source & sink have been hooked up directly and it behaves the same way, eliminating cabling issues.

Reverting to the 3.18 branch (3.18.109) fixes the issue.

However, based on the previous "weakness in source devices" comment, I guess Intel's "solution" to this issue is to replace a fully-working system which works flawlessly under the 3.x kernel branch with something else? Or am I misunderstanding something?

Stay tuned for more logs with debugging information enabled. (If anyone is still interested in solving this, that is.)

--Martin

Martin Andersen uploaded an attachment:

Attachment 139753, "Xorg.0.log from nonworking 4.16.11 kernel":
Xorg.0.log.4.16.11.defunct.txt

Martin Andersen uploaded an attachment:

Attachment 139754, "dmesg (w/ debug output) from nonworking 4.16.11 kernel - directly attached bypassing switch":
dmesg.4.16.11.directattach.txt

Martin Andersen uploaded an attachment:

Attachment 139755, "dmesg (w/ drm.debug=0x1e) from correctly-working 3.18.109 kernel":
dmesg.3.18.109.working.txt

Martin Andersen uploaded an attachment:

Attachment 139756, "Xorg.0.log from correctly-working 3.18.109 kernel":
Xorg.0.log.3.18.109.working.txt

Martin Andersen said:

Logs attached. Steps performed after boot:

$ xrandr -q
$ xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
$ xrandr --output HDMI2 --mode 1920x1080 --rate 24
$ xrandr --output HDMI2 --mode 1920x1080@23.97610
$ xrandr --output HDMI2 --mode 1920x1080 --rate 50
$ xrandr --output HDMI2 --mode 1920x1080 --rate 60

xrandr reports everything as fine when probing and switching modes (as before), and applications - such as Kodi - can be successfully started on the second display without issues (despite the fact that it has no signal to the sink)

Martin Andersen said:

Looking at the 4.16.11 (nonworking) connector probing, there are a lot more 'dp_aux_ch timeout status 0x7145003f' errors when doing the probe. The connectors themselves are also different, [CONNECTOR:61:HDMI-A-1] & [CONNECTOR:68:HDMI-A-2] vs. [CONNECTOR:21:HDMI-A-1] & [CONNECTOR:28:HDMI-A-2], presumably due to a change in naming convention.

The max TMDS values detected are also, seemingly, different. And with latency values attached on the known-good 3.18 kernel:

Good:

[ 4.096894] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 300, latency present 1 1, video latency 46 33, audio latency 255 255
[ 4.424603] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 300, latency present 1 1, video latency 46 33, audio latency 255 255

Bad:

[ 3.141400] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 3.141448] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 3.552559] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 3.552590] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 3.888076] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 3.888108] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 4.243961] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz
[ 4.243993] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 300000 kHz

Nonworking 4.16.11 kernel:
==========================

[ 3.741688] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:66:DP-1]
[ 3.741719] [drm:intel_dp_detect [i915]] [CONNECTOR:66:DP-1]
[ 3.746082] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.748575] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.751063] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.753560] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.756044] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.758527] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.761011] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.763499] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.765976] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[...]

[drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110
[ 3.823189] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:66:DP-1] disconnected
[ 3.823195] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:68:HDMI-A-2]
[ 3.823215] [drm:intel_hdmi_detect [i915]] [CONNECTOR:68:HDMI-A-2]
[ 3.850788] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpd] NAK for addr: 0040 w(1)
[ 3.850803] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpd] NAK on first message, retry
[ 3.850975] [drm:gmbus_xfer [i915]] GMBUS [i915 gmbus dpd] NAK for addr: 0040 w(1)
[...]

[ 3.431220] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:70:DP-2]
[ 3.431273] [drm:intel_dp_detect [i915]] [CONNECTOR:70:DP-2]
[ 3.433945] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.437380] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.440077] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.442667] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.445422] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.447949] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.450491] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[ 3.453021] [drm:intel_dp_aux_ch [i915]] dp_aux_ch timeout status 0x7145003f
[...]

[ 3.515129] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110
[ 3.515135] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:70:DP-2] status updated from unknown to disconnected
[ 3.515138] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:70:DP-2] disconnected

[...]
[ 3.515144] [drm:drm_setup_crtcs [drm_kms_helper]] connector 58 enabled? no
[ 3.515148] [drm:drm_setup_crtcs [drm_kms_helper]] connector 61 enabled? yes
[ 3.515151] [drm:drm_setup_crtcs [drm_kms_helper]] connector 66 enabled? no
[ 3.515155] [drm:drm_setup_crtcs [drm_kms_helper]] connector 68 enabled? yes
[ 3.515158] [drm:drm_setup_crtcs [drm_kms_helper]] connector 70 enabled? no

Working 3.18.109 kernel:
========================

[ 4.053910] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:26:DP-1]
[ 4.053912] [drm:intel_dp_detect] [CONNECTOR:26:DP-1]
[ 4.056620] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.059138] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.063443] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.067814] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.069266] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:26:DP-1] disconnected
[ 4.069271] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:28:HDMI-A-2]
[ 4.069273] [drm:intel_hdmi_detect] [CONNECTOR:28:HDMI-A-2]
[ 4.096831] [drm:drm_rgb_quant_range_selectable] CEA VCDB 0xfb
[ 4.096891] [drm:drm_edid_to_eld] ELD monitor EPSON PJ
[ 4.096894] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 300, latency present 1 1, video latency 46 33, audio latency 255 255
[...]

[ 4.097086] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:30:DP-2]
[ 4.097088] [drm:intel_dp_detect] [CONNECTOR:30:DP-2]
[ 4.099705] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.102223] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.105794] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.109786] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.111269] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:30:DP-2] disconnected
[ 4.111272] [drm:drm_setup_crtcs]
[ 4.111275] [drm:drm_enable_connectors] connector 18 enabled? no
[ 4.111276] [drm:drm_enable_connectors] connector 21 enabled? yes
[ 4.111278] [drm:drm_enable_connectors] connector 26 enabled? no
[ 4.111279] [drm:drm_enable_connectors] connector 28 enabled? yes
[ 4.111280] [drm:drm_enable_connectors] connector 30 enabled? no
[...]

[ 4.376826] [drm:drm_mode_getconnector] [CONNECTOR:21:?]
[ 4.379352] usbcore: registered new interface driver snd-usb-audio
[ 4.380460] [drm:drm_mode_getconnector] [CONNECTOR:26:?]
[ 4.380465] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:26:DP-1]
[ 4.380467] [drm:intel_dp_detect] [CONNECTOR:26:DP-1]
[ 4.382978] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.385472] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.389733] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.393733] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.395253] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:26:DP-1] disconnected
[ 4.395261] [drm:drm_mode_getconnector] [CONNECTOR:26:?]
[ 4.395265] [drm:drm_mode_getconnector] [CONNECTOR:28:?]
[ 4.395266] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:28:HDMI-A-2]
[ 4.395270] [drm:intel_hdmi_detect] [CONNECTOR:28:HDMI-A-2]
[ 4.424556] [drm:drm_rgb_quant_range_selectable] CEA VCDB 0xfb
[ 4.424601] [drm:drm_edid_to_eld] ELD monitor EPSON PJ
[ 4.424603] [drm:parse_hdmi_vsdb] HDMI: DVI dual 0, max TMDS clock 300, latency present 1 1, video latency 46 33, audio latency 255 255
[...]

[ 4.424747] [drm:drm_mode_getconnector] [CONNECTOR:28:?]
[ 4.427495] [drm:drm_mode_getconnector] [CONNECTOR:30:?]
[ 4.427500] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:30:DP-2]
[ 4.427501] [drm:intel_dp_detect] [CONNECTOR:30:DP-2]
[ 4.429977] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.432440] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.436727] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.440753] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145003f
[ 4.442263] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:30:DP-2] disconnected
[ 4.442274] [drm:drm_mode_getconnector] [CONNECTOR:30:?]
[ 4.442292] [drm:drm_mode_addfb] [FB:54]
[ 4.454217] [drm:drm_mode_addfb] [FB:54]
[ 4.454234] [drm:drm_mode_addfb] [FB:65]
[ 4.458498] [drm:drm_mode_setcrtc] [CRTC:8]
[ 4.458505] [drm:drm_mode_setcrtc] [CONNECTOR:21:HDMI-A-1]

LAKSHMINARAYANA VUDUM @l4kshmi said:

Martin, sorry for the delay.

can you try to reproduce this issue with latest drm-tip (https://cgit.freedesktop.org/drm-tip)?
If the issue persists, Can you send dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.

Martin Andersen uploaded an attachment:

Attachment 141702, "drm.debug=0x1e from nonworking 4.19.0-994 kernel":
syslog-4.19.0-994-defunct.txt.xz

Martin Andersen uploaded an attachment:

Attachment 141703, "Xorg.0.log from nonworking 4.19.0-994 kernel":
Xorg.0.log-4.19.0-994-defunct.txt

Martin Andersen said:

Hi Lakshmi,

Added logs from one of my Haswell systems running the latest - as of today - DRM tip kernel 4.19.0-994 for your viewing pleasure.

Exactly the same behaviour as on my Ivy Bridge is witnessed - no output during boot, no output at all from 50 & 60 Hz modes, and garbled text from the 23.976 & 24.000Hz modes which all work correctly on the 3.x branch.

Steps performed after login -

$ xrandr -q
$ xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
$ xrandr --output HDMI2 --mode 1920x1080 --rate 24
$ xrandr --output HDMI2 --mode 1920x1080 --rate 50
$ xrandr --output HDMI2 --mode 1920x1080 --rate 60

$ xrandr --output HDMI2 --mode 1920x1080 --rate 23.976
$ xrandr --output HDMI2 --mode 1920x1080 --rate 24
$ xrandr --output HDMI2 --mode 1920x1080 --rate 50
$ xrandr --output HDMI2 --mode 1920x1080 --rate 60

The cynic in me suspects that this ticket will now lay dormant again for a few months, whereupon I will again be asked to provide output from the latest DRM tip kernel (as if hoping that it magically solved this without any specific changes for this issue having been made)

If so is the case, please refer to a patch which - potentially - restores this functionality so that there is at least a inkling that it might behave differently.
It has previously been suggested that this is due to "newer" kernels not defaulting to 8bpc.

And before Intel again points to issues with "dongles, cables, sources & sinks" bear in mind that these have all been eliminated.

By hooking up directly, bypassing any switches
Loss of signal is occurring with three separate systems/sources - one IVB, two HSW
All cables have been replaced
There are no dongles in between
Sinks have been replaced also

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

Submitted by Martin Andersen

Description

See also

Child items 0

Activity

Admin message

Admin message

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

Submitted by Martin Andersen

Description

See also

Activity