Created attachment 117302 [details]
Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 1 of 3

Created attachment 117303 [details]
Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 2 of 3

Created attachment 117304 [details]
Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 3 of 3

Created attachment 117305 [details]
Xorg debug output from correctly-working 3.13.5 kernel running xf86-video-intel driver 2.99.917

Can you bisect, please?

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.

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

Created attachment 117878 [details]
drm.debug=0xe from working 3.13.5 kernel

Created attachment 117879 [details]
drm.debug=0xe from nonworking 4.0.9 kernel

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)

Let me know if additional info is needed.

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

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

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

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

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

Created attachment 127342 [details]
xrandr -v from working (3.18.5) setup

Created attachment 127399 [details]
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

Created attachment 127400 [details]
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

Created attachment 127401 [details]
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)

Created attachment 127402 [details]
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

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.

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.

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.

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

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)

Created attachment 130632 [details]
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

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

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.

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.

Created attachment 132027 [details]
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

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

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

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.

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

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

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

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.

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

Created attachment 139752 [details]
dmesg from nonworking 4.16.11 kernel

Created attachment 139753 [details]
Xorg.0.log from nonworking 4.16.11 kernel

Created attachment 139754 [details]
dmesg (w/ debug output) from nonworking 4.16.11 kernel - directly attached bypassing switch

Created attachment 139755 [details]
dmesg (w/ drm.debug=0x1e) from correctly-working 3.18.109 kernel

Created attachment 139756 [details]
Xorg.0.log from correctly-working 3.18.109 kernel

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)

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]

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.

Created attachment 141702 [details]
drm.debug=0x1e from nonworking 4.19.0-994 kernel

Created attachment 141703 [details]
Xorg.0.log from nonworking 4.19.0-994 kernel

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

Since this ticket has had a strong tendency to be ignored for several months once the requested debug information is provided - only for it to be asked for again when a certain time lapses and the previously-provided information is flagged "out of date" - I ask that someone *please confirm that the necessary information has been received* and that Intel is working on it. Or, if more information is needed *please let me know.*

If not, it appears to me that Intel has little interest in actually solving it, only giving the impression of doing so for posterity.

The bug was reported over three years ago, in July 2015. After which time I have gone through numerous sources, sinks and cables while the problems manifest themselves in precisely the same manner. The issue can always be restored to a functioning state by reverting to the 3.x kernel branch - for which I have also provided extensive debug output for comparison, most recently in May 2018.

Ok, failing any word from Intel after the required debug output was provided again for the n-th time, can it at least be acknowledged whether the option to limit bpc is going to be implemented - see the link to the proposed patch below - so this can at least be confirmed or ruled out once and for all –

https://www.spinics.net/lists/intel-gfx/msg143836.html ([RFC 1/2] drm/i915: Add connector property to force bpc)

Currently there are no options relating to this for the i915 driver. Valid options at the time of writing are as follows:



parm:           modeset:Use kernel modesetting [KMS] (0=disable, 1=on, -1=force vga console preference [default]) (int)
parm:           panel_ignore_lid:Override lid status (0=autodetect, 1=autodetect disabled [default], -1=force lid closed, -2=force lid open) (int)
parm:           enable_dc:Enable power-saving display C-states. (-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6) (int)
parm:           enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int)
parm:           lvds_channel_mode:Specify LVDS channel mode (0=probe BIOS [default], 1=single-channel, 2=dual-channel) (int)
parm:           panel_use_ssc:Use Spread Spectrum Clock with panels [LVDS/eDP] (default: auto from VBT) (int)
parm:           vbt_sdvo_panel_type:Override/Ignore selection of SDVO panel mode in the VBT (-2=ignore, -1=auto [default], index in VBT BIOS table) (int)
parm:           reset:Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default]) (int)
parm:           vbt_firmware:Load VBT from specified file under /lib/firmware (charp)
parm:           error_capture:Record the GPU state following a hang. This information in /sys/class/drm/card<N>/error is vital for triaging and debugging hangs. (bool)
parm:           enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool)
parm:           enable_ppgtt:Override PPGTT usage. (-1=auto [default], 0=disabled, 1=aliasing, 2=full, 3=full with extended address space) (int)
parm:           enable_psr:Enable PSR (0=disabled, 1=enabled - link mode chosen per-platform, 2=force link-standby mode, 3=force link-off mode) Default: -1 (use per-chip default) (int)
parm:           alpha_support:Enable alpha quality driver support for latest hardware. See also CONFIG_DRM_I915_ALPHA_SUPPORT. (bool)
parm:           disable_power_well:Disable display power wells when possible (-1=auto [default], 0=power wells always on, 1=power wells disabled when possible) (int)
parm:           enable_ips:Enable IPS (default: true) (int)
parm:           fastboot:Try to skip unnecessary mode sets at boot time (default: false) (bool)
parm:           prefault_disable:Disable page prefaulting for pread/pwrite/reloc (default:false). For developers only. (bool)
parm:           load_detect_test:Force-enable the VGA load detect code for testing (default:false). For developers only. (bool)
parm:           force_reset_modeset_test:Force a modeset during gpu reset for testing (default:false). For developers only. (bool)
parm:           invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device ID to dri-devel@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int)
parm:           disable_display:Disable display (default: false) (bool)
parm:           enable_cmd_parser:Enable command parsing (true=enabled [default], false=disabled) (bool)
parm:           mmio_debug:Enable the MMIO debug code for the first N failures (default: off). This may negatively affect performance. (int)
parm:           verbose_state_checks:Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions. (bool)
parm:           nuclear_pageflip:Force enable atomic functionality on platforms that don't have full support yet. (bool)
parm:           edp_vswing:Ignore/Override vswing pre-emph table selection from VBT (0=use value from vbt [default], 1=low power swing(200mV),2=default swing(400mV)) (int)
parm:           enable_guc:Enable GuC load for GuC submission and/or HuC load. Required functionality can be selected using bitmask values. (-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load) (int)
parm:           guc_log_level:GuC firmware logging level. Requires GuC to be loaded. (-1=auto [default], 0=disable, 1..4=enable with verbosity min..max) (int)
parm:           guc_firmware_path:GuC firmware path to use instead of the default one (charp)
parm:           huc_firmware_path:HuC firmware path to use instead of the default one (charp)
parm:           enable_dp_mst:Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true) (bool)
parm:           enable_dpcd_backlight:Enable support for DPCD backlight control (default:false) (bool)
parm:           enable_gvt:Enable support for Intel GVT-g graphics virtualization host support(default:false) (bool)

Martin, My apologies.
We will look in to this issue and come back to you soon.

Max bpc connector property patches are close to being ready:
https://patchwork.freedesktop.org/series/50295/

Thanks for the reply Lakshmi, and for informing about the max bpc connector patches, Ville. Let's hope those are indeed ready soon and those changes will have an impact on this long-running issue.

I still find it curious how three pretty dissimilar systems could - even when hooked up directly to a sink using different cables - all falsely advertise 12bpc capability though.

(In reply to Ville Syrjala from comment #54)
> Max bpc connector property patches are close to being ready:
> https://patchwork.freedesktop.org/series/50295/

Ville, is this patch ready and available in drm-tip/upstream?

It would be good to receive some indication as to when the bpc connector patches will be available in drm-tip/upstream so this can finally be tested. (Looks like the latest activity is from Sep 28th.)

Two and a half months later and no further info. :/ "Close to being ready", indeed. :/ The latest activity is still from Sept 28th of last year.

Sorry, seems no one remembered to update the bug. The patches were apparently merged in October.

commit f1a1217222a24775eaaafbcbd386101dc44f8a81
Author:     Radhakrishna Sripada <radhakrishna.sripada@intel.com>
AuthorDate: Mon Oct 22 18:44:00 2018 -0700
Commit:     Rodrigo Vivi <rodrigo.vivi@intel.com>
CommitDate: Fri Nov 2 09:16:03 2018 -0700

    drm/i915: Allow "max bpc" property to limit pipe_bpp

(In reply to Ville Syrjala from comment #59)
> Sorry, seems no one remembered to update the bug. The patches were
> apparently merged in October.

Err, make that November.

> 
> commit f1a1217222a24775eaaafbcbd386101dc44f8a81
> Author:     Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> AuthorDate: Mon Oct 22 18:44:00 2018 -0700
> Commit:     Rodrigo Vivi <rodrigo.vivi@intel.com>
> CommitDate: Fri Nov 2 09:16:03 2018 -0700
> 
>     drm/i915: Allow "max bpc" property to limit pipe_bpp

How does one actually use this new property?

I have tested several kernels from mainline 4.18.x, 4.19.x to drm-tip and there is still no "max bpc" option to drm.ko or i915.ko -

name:           i915
vermagic:       5.0.0-994-lowlatency SMP preempt mod_unload 
signat:         PKCS#7
signer:         
sig_key:        
sig_hashalgo:   md4
parm:           modeset:Use kernel modesetting [KMS] (0=disable, 1=on, -1=force vga console preference [default]) (int)
parm:           enable_dc:Enable power-saving display C-states. (-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6) (int)
parm:           enable_fbc:Enable frame buffer compression for power savings (default: -1 (use per-chip default)) (int)
parm:           lvds_channel_mode:Specify LVDS channel mode (0=probe BIOS [default], 1=single-channel, 2=dual-channel) (int)
parm:           panel_use_ssc:Use Spread Spectrum Clock with panels [LVDS/eDP] (default: auto from VBT) (int)
parm:           vbt_sdvo_panel_type:Override/Ignore selection of SDVO panel mode in the VBT (-2=ignore, -1=auto [default], index in VBT BIOS table) (int)
parm:           reset:Attempt GPU resets (0=disabled, 1=full gpu reset, 2=engine reset [default]) (int)
parm:           vbt_firmware:Load VBT from specified file under /lib/firmware (charp)
parm:           error_capture:Record the GPU state following a hang. This information in /sys/class/drm/card<N>/error is vital for triaging and debugging hangs. (bool)
parm:           enable_hangcheck:Periodically check GPU activity for detecting hangs. WARNING: Disabling this can cause system wide hangs. (default: true) (bool)
parm:           enable_psr:Enable PSR (0=disabled, 1=enabled) Default: -1 (use per-chip default) (int)
parm:           alpha_support:Enable alpha quality driver support for latest hardware. See also CONFIG_DRM_I915_ALPHA_SUPPORT. (bool)
parm:           disable_power_well:Disable display power wells when possible (-1=auto [default], 0=power wells always on, 1=power wells disabled when possible) (int)
parm:           enable_ips:Enable IPS (default: true) (int)
parm:           fastboot:Try to skip unnecessary mode sets at boot time (default: false) (bool)
parm:           prefault_disable:Disable page prefaulting for pread/pwrite/reloc (default:false). For developers only. (bool)
parm:           load_detect_test:Force-enable the VGA load detect code for testing (default:false). For developers only. (bool)
parm:           force_reset_modeset_test:Force a modeset during gpu reset for testing (default:false). For developers only. (bool)
parm:           invert_brightness:Invert backlight brightness (-1 force normal, 0 machine defaults, 1 force inversion), please report PCI device ID, subsystem vendor and subsystem device ID to dri-devel@lists.freedesktop.org, if your machine needs it. It will then be included in an upcoming module version. (int)
parm:           disable_display:Disable display (default: false) (bool)
parm:           mmio_debug:Enable the MMIO debug code for the first N failures (default: off). This may negatively affect performance. (int)
parm:           verbose_state_checks:Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state conditions. (bool)
parm:           nuclear_pageflip:Force enable atomic functionality on platforms that don't have full support yet. (bool)
parm:           edp_vswing:Ignore/Override vswing pre-emph table selection from VBT (0=use value from vbt [default], 1=low power swing(200mV),2=default swing(400mV)) (int)
parm:           enable_guc:Enable GuC load for GuC submission and/or HuC load. Required functionality can be selected using bitmask values. (-1=auto, 0=disable [default], 1=GuC submission, 2=HuC load) (int)
parm:           guc_log_level:GuC firmware logging level. Requires GuC to be loaded. (-1=auto [default], 0=disable, 1..4=enable with verbosity min..max) (int)
parm:           guc_firmware_path:GuC firmware path to use instead of the default one (charp)
parm:           huc_firmware_path:HuC firmware path to use instead of the default one (charp)
parm:           dmc_firmware_path:DMC firmware path to use instead of the default one (charp)
parm:           enable_dp_mst:Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true) (bool)
parm:           enable_dpcd_backlight:Enable support for DPCD backlight control (default:false) (bool)
parm:           enable_gvt:Enable support for Intel GVT-g graphics virtualization host support(default:false) (bool)


name:           drm
vermagic:       5.0.0-994-lowlatency SMP preempt mod_unload 
signat:         PKCS#7
signer:         
sig_key:        
sig_hashalgo:   md4
parm:           edid_firmware:Do not probe monitor, use specified EDID blob from built-in data or /lib/firmware instead.  (string)
parm:           vblankoffdelay:Delay until vblank irq auto-disable [msecs] (0: never disable, <0: disable immediately) (int)
parm:           timestamp_precision_usec:Max. error on timestamps [usecs] (int)
parm:           edid_fixup:Minimum number of valid EDID header bytes (0-8, default 6) (int)
parm:           debug:Enable debug output, where each bit enables a debug category.
		Bit 0 (0x01)  will enable CORE messages (drm core code)
		Bit 1 (0x02)  will enable DRIVER messages (drm controller code)
		Bit 2 (0x04)  will enable KMS messages (modesetting code)
		Bit 3 (0x08)  will enable PRIME messages (prime code)
		Bit 4 (0x10)  will enable ATOMIC messages (atomic code)
		Bit 5 (0x20)  will enable VBL messages (vblank code)
		Bit 7 (0x80)  will enable LEASE messages (leasing code)
		Bit 8 (0x100) will enable DP messages (displayport code) (int)


Running strings on the drm.ko module reveals the following:

strings /lib/modules/5.0.0-994-lowlatency/kernel/drivers/gpu/drm/drm.ko|grep -i bpc
max bpc
%s: Assigning HDMI sink color depth as %d bpc.
%s: Assigning DFP sink color depth as %d bpc.
%s: Assigning EDID-1.4 digital sink color depth as %d bpc.
drm_connector_attach_max_bpc_property
__ksymtab_drm_connector_attach_max_bpc_property
__kstrtab_drm_connector_attach_max_bpc_property


Which is different from previous versions. However, I still do not have the Correct(tm) syntax to pass this along to the driver as a kernel option and actually test it.

Some guesswork was tried;

[    0.074177] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-994-lowlatency root=UUID=83d53be4-28c6-4c1c-8a5d-bba7b62e6470 ro quiet splash vt.handoff=1 drm.drm_connector_attach_max_bpc_property=8 i915.max_bpc=8

[    1.491819] drm: unknown parameter 'drm_connector_attach_max_bpc_property' ignored
[    1.537074] i915: unknown parameter 'max_bpc' ignored


[    0.074292] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-994-lowlatency root=UUID=83d53be4-28c6-4c1c-8a5d-bba7b62e6470 ro "drm.max bpc=8" i915.max_bpc=8 i915.bpc=8 drm.i915.bpc=8 drm.debug=0xe vt.handoff=1
[    5.024459] i915: unknown parameter 'max_bpc' ignored
[    5.049545] i915: unknown parameter 'bpc' ignored


[    0.074731] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-994-lowlatency root=UUID=83d53be4-28c6-4c1c-8a5d-bba7b62e6470 ro "drm.max bpc=8" drm.max_bpc=8 drm.debug=0xe vt.handoff=1
[    4.648024] drm: unknown parameter 'max_bpc' ignored


[    0.074400] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-994-lowlatency root=UUID=83d53be4-28c6-4c1c-8a5d-bba7b62e6470 ro quiet splash vt.handoff=1 drm.bpc=8
[    1.467922] drm: unknown parameter 'bpc' ignored

If someone can give the correct parameters to pass the bpc setting to the driver and/or a link to a kernel which has this fix in place I could finally be able to test this and see whether it made any difference.

I'm sorry, but how to use this functionality is far from obvious.

xrandr --output <something> --set 'max bpc' 8

I was under the impression that this was a kernel option(?). The issue is that *no signal is displayed* at all during boot (i.e, before X, as mentioned several times), so running an xrandr command is a somewhat sub-optimal solution as it requires logging into the system to issue it.

Nevertheless, having the early boot-messages show up on HDMI2 is also very useful. The display is immediately blanked after BIOS post when out using newer kernels. It is not simply an Xorg issue.

It took me a bit longer than anticipated to test this, but this has now finally been done.

I will cut right to it - setting bpc to 8 with xrandr *does ensure proper output* on the HDMI2 port, at least on the Haswell system I am testing with. Tested 23.976Hz, 24Hz, 50Hz & 60Hz modes.

The limitiation of doing this with xrandr does present some other major issues though which Intel needs to consider:

- No display is visible before Xorg has been started, a user logged in and the xrandr command issued. This necessitates use of a second monitor simply to accomplish the bpc switch.

- Any application can override this setting by requesting 10 or 12 bpc (for 
whatever reason, presumably by requesting the maximum bpc 'supported')

- For systems where the output which does not work properly on 10- or 12-bpc is the sole means of interacting, having to rely on xrandr is not an option, as it requires logging into a system which does not have a working display.

- More importantly, for systems which are using encrypted root-volumes via – i.e, LUKS – there is no way to interact with the password prompt as the system does not have display output.


Another point I need to make is that this issue is *only* present on Intel systems using the built-in iGPU.

None of my other hardware devices consisting of:

- An Oppo Blu-Ray player
- A PS3
- A PS4
- A CableTV box
- An Nvidia Shield

Exhibit this issue, and they are hooked up *precisely the same way* as the standalone Intel iGPU systems. Point being, the default should be 8bpc unless an application specifically requests it. No functionality should be lost this way.

Furthermore, the setting to lock one or more outputs to a certain bpc needs to be set via a kernel parameter to the i915.ko or drm.ko kernel modules themselves, in order to *ensure* that the system is not going black during boot (or going black during operation due to an application requesting higher bpc). 

Once set, the output is working as the system shuts down (i.e, after X has terminated)

Surely Intel sees the value of having the functionality work this way; especially now that the source of the problem has been identified and the mechanism for setting a lower bpc - has been implemented. It would certainly affect more HTPC systems than just mine.

I will include debug logs for the sake of completeness.

Created attachment 143317 [details]
drm.debug=0x1e from working 5.0.0-994 kernel (after xrandr cmd manually issued)

All that remains for this case to finally be closed is the ability to set max bpc during boot, see prior comments as to why this is very relevant. Now that the mechanism to do this with xrandr has been implemented it should be a small matter to be able to pass it directly to the kernel module.

Original issue is resolved, this is now an enhancement request for additional kernel param for setting max_bpc at boot

Has there been any development wrt. implementing a boot-time max_bpc setting (kernel parameter to the i915 module), which mirrors the functionality of 'xrandr --set 'max bpc' 8' ?
 
I am afraid that the lack of this functionality will rule out running an Intel GPU on affected systems, as the display is completely blank during boot and logging in to the X-server (which becomes an impossibility) is required in order to override the detected bpc setting and return the system to a functioning state.

You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.

I actually just provided a comment for this issue (Nov 11th). Yes, I am still experiencing an issue which prevents me from using the Intel driver with recent kernels.

The absence of a boot-time setting (module paramenter to i915) makes the bpc setting  - which requires logging into X in order to put into effect - rather hard to achieve when a working display is not available.

Please read the comments I have provided, as they are quite descriptive wrt. explaining the bug and subsequent feature request in full. The functionality for setting the bpc has already been implemented, and surely it would be possible to have a parameter to the kernel module directly which bypass xrandr.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/24.