Bug 91434 - [IVB/HSW] 23.976Hz & 24Hz modes broken on dual-display with recent (4.0.x) kernels
Summary: [IVB/HSW] 23.976Hz & 24Hz modes broken on dual-display with recent (4.0.x) ke...
Status: NEW
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-22 20:47 UTC by Martin Andersen
Modified: 2019-03-28 12:47 UTC (History)
2 users (show)

See Also:
i915 platform: HSW, IVB
i915 features: display/HDMI


Attachments
Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 1 of 3 (2.10 MB, application/octet-stream)
2015-07-22 20:55 UTC, Martin Andersen
no flags Details
Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 2 of 3 (1.97 MB, application/octet-stream)
2015-07-22 20:56 UTC, Martin Andersen
no flags Details
Xorg debug output from nonworking 4.0.9 kernel running xf86-video-intel driver 2.99.917, part 3 of 3 (2.44 MB, application/octet-stream)
2015-07-22 20:56 UTC, Martin Andersen
no flags Details
Xorg debug output from correctly-working 3.13.5 kernel running xf86-video-intel driver 2.99.917 (63.08 KB, application/octet-stream)
2015-07-22 20:58 UTC, Martin Andersen
no flags Details
drm.debug=0xe from working 3.13.5 kernel (156.22 KB, text/plain)
2015-08-23 15:00 UTC, Martin Andersen
no flags Details
drm.debug=0xe from nonworking 4.0.9 kernel (231.74 KB, text/plain)
2015-08-23 15:00 UTC, Martin Andersen
no flags Details
xrandr -v from working (3.18.5) setup (18.59 KB, text/plain)
2016-10-17 07:57 UTC, Martin Andersen
no flags 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 (48.69 KB, application/x-xz)
2016-10-19 12:56 UTC, Martin Andersen
no flags 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 (5.89 KB, application/x-xz)
2016-10-19 12:57 UTC, Martin Andersen
no flags 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) (75.69 KB, application/x-xz)
2016-10-19 12:59 UTC, Martin Andersen
no flags 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 (5.74 KB, application/x-xz)
2016-10-19 13:00 UTC, Martin Andersen
no flags 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 (994.46 KB, text/plain)
2017-04-01 14:23 UTC, Martin Andersen
no flags 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 (803.97 KB, text/plain)
2017-06-18 13:27 UTC, Martin Andersen
no flags Details
dmesg from nonworking 4.16.11 kernel (232.21 KB, text/plain)
2018-05-25 10:15 UTC, Martin Andersen
no flags Details
Xorg.0.log from nonworking 4.16.11 kernel (51.09 KB, text/plain)
2018-05-25 10:16 UTC, Martin Andersen
no flags Details
dmesg (w/ debug output) from nonworking 4.16.11 kernel - directly attached bypassing switch (232.38 KB, text/plain)
2018-05-25 10:17 UTC, Martin Andersen
no flags Details
dmesg (w/ drm.debug=0x1e) from correctly-working 3.18.109 kernel (131.08 KB, text/plain)
2018-05-25 10:18 UTC, Martin Andersen
no flags Details
Xorg.0.log from correctly-working 3.18.109 kernel (104.37 KB, text/plain)
2018-05-25 10:19 UTC, Martin Andersen
no flags Details
drm.debug=0x1e from nonworking 4.19.0-994 kernel (219.27 KB, application/x-xz)
2018-09-23 21:20 UTC, Martin Andersen
no flags Details
Xorg.0.log from nonworking 4.19.0-994 kernel (25.41 KB, text/plain)
2018-09-23 21:21 UTC, Martin Andersen
no flags Details
drm.debug=0x1e from working 5.0.0-994 kernel (after xrandr cmd manually issued) (2.62 MB, application/x-xz)
2019-02-06 11:24 UTC, Martin Andersen
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Andersen 2015-07-22 20:47:31 UTC
This is a somewhat similar issue to #87112, which was recently identified as being related to the xf86-video-intel driver. However this bug relates to drm/i915 changes in recent 4.0.x kernels (tested several kernel.ubuntu.com provided wily builds for 4.0.2, 4.0.4 & 4.0.9; both generic and lowlatency versions. They all exhibit the same problem.)

Problem description:

Switching to 24Hz or 23.976Hz modes (which previously worked using the same X setup and drivers) on a secondary display produces no signal. The secondary display is able to output only 50 & 60Hz modes.

Kernel: 4.0.9-040009-lowlatency #201507212131 SMP PREEMPT Wed Jul 22 01:41:54 UTC 2015 x86_64

Correct behaviour is observed by reverting to 3.13.5 & 3.18.5. (w/ no other changes performed)

vainfo:

libva info: VA-API version 0.38.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell - 1.6.0
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264MultiviewHigh      :	VAEntrypointEncSlice
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointEncSlice

I am attaching a full Xorg.0.log when running the latest xf86-video-intel driver (2.99.917), compiled with '--enable-debug=full' on this Haswell (Intel Iris Graphics 5100) system. I am also attaching similar output from a working system (although the output is more limited)

Steps done on the client side while debug output was running: (steps not included are logging in from MDM and starting a Gnome Mate session) –

martin@meraxes ~ $ xrandr --output HDMI2 --rate 24 --mode 1920x1080
martin@meraxes ~ $
martin@meraxes ~ $ xrandr -q
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 286mm x 179mm
   2560x1600      60.0 +
   2048x1536      60.0
   1920x1440      60.0
   1856x1392      60.0
   1792x1344      60.0
   1920x1200      60.0
   1920x1080      59.9*
   1600x1200      60.0
   1680x1050      60.0     59.9
   1600x1024      60.2
   1400x1050      60.0
   1280x1024      60.0
   1440x900       59.9
   1280x960       60.0
   1360x768       59.8     60.0
   1152x864       60.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        59.9
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 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
   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@meraxes ~ $
martin@meraxes ~ $ xrandr --output HDMI2 --rate 23.976 --mode 1920x1080
martin@meraxes ~ $ xrandr --output HDMI2 --rate 25 --mode 1920x1080
martin@meraxes ~ $
martin@meraxes ~ $ xrandr --output HDMI2 --rate 50 --mode 1920x1080
martin@meraxes ~ $
martin@meraxes ~ $ xrandr -q
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 286mm x 179mm
   2560x1600      60.0 +
   2048x1536      60.0
   1920x1440      60.0
   1856x1392      60.0
   1792x1344      60.0
   1920x1200      60.0
   1920x1080      59.9*
   1600x1200      60.0
   1680x1050      60.0     59.9
   1600x1024      60.2
   1400x1050      60.0
   1280x1024      60.0
   1440x900       59.9
   1280x960       60.0
   1360x768       59.8     60.0
   1152x864       60.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        59.9
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI1 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
   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@meraxes ~ $
martin@meraxes ~ $ xrandr --output HDMI2 --rate 24.0 --mode 1920x1080
martin@meraxes ~ $
martin@meraxes ~ $ xrandr --output HDMI2 --rate 60 --mode 1920x1080
Comment 1 Martin Andersen 2015-07-22 20:55:35 UTC
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
Comment 2 Martin Andersen 2015-07-22 20:56:09 UTC
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
Comment 3 Martin Andersen 2015-07-22 20:56:53 UTC
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
Comment 4 Martin Andersen 2015-07-22 20:58:08 UTC
Created attachment 117305 [details]
Xorg debug output from correctly-working 3.13.5 kernel running xf86-video-intel driver 2.99.917
Comment 5 Jani Nikula 2015-08-20 14:05:32 UTC
Can you bisect, please?
Comment 6 Martin Andersen 2015-08-20 14:20:30 UTC
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.
Comment 7 Ville Syrjala 2015-08-20 15:34:25 UTC
Can't do much with xorg logs here. Please provide dmesg with drm.debug=0xe enabled for both the successful and failing cases.
Comment 8 Martin Andersen 2015-08-23 15:00:04 UTC
Created attachment 117878 [details]
drm.debug=0xe from working 3.13.5 kernel
Comment 9 Martin Andersen 2015-08-23 15:00:37 UTC
Created attachment 117879 [details]
drm.debug=0xe from nonworking 4.0.9 kernel
Comment 10 Martin Andersen 2015-08-23 15:06:20 UTC
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)
Comment 11 Martin Andersen 2015-09-18 16:09:17 UTC
Let me know if additional info is needed.
Comment 12 Ville Syrjala 2016-03-04 17:38:15 UTC
(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.
Comment 13 Martin Andersen 2016-03-05 11:34:45 UTC
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;)
Comment 14 Martin Andersen 2016-03-06 16:36:39 UTC
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.)
Comment 15 Martin Andersen 2016-03-17 08:42:47 UTC
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
Comment 16 Martin Andersen 2016-10-17 07:43:23 UTC
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
Comment 17 Martin Andersen 2016-10-17 07:57:08 UTC
Created attachment 127342 [details]
xrandr -v from working (3.18.5) setup
Comment 18 Martin Andersen 2016-10-19 12:56:08 UTC
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
Comment 19 Martin Andersen 2016-10-19 12:57:18 UTC
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
Comment 20 Martin Andersen 2016-10-19 12:59:55 UTC
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)
Comment 21 Martin Andersen 2016-10-19 13:00:39 UTC
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
Comment 22 Martin Andersen 2016-10-19 13:09:49 UTC
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.
Comment 23 Martin Andersen 2016-10-28 10:12:53 UTC
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.
Comment 24 Jari Tahvanainen 2017-03-29 10:55:35 UTC
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.
Comment 25 Martin Andersen 2017-03-30 15:21:50 UTC
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..)
Comment 26 Martin Andersen 2017-04-01 14:21:31 UTC
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)
Comment 27 Martin Andersen 2017-04-01 14:23:58 UTC
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
Comment 28 Martin Andersen 2017-04-05 09:10:04 UTC
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..
Comment 29 Martin Andersen 2017-04-18 19:36:47 UTC
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.
Comment 30 Martin Andersen 2017-04-27 15:44:50 UTC
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.
Comment 31 Martin Andersen 2017-06-18 13:27:14 UTC
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
Comment 32 Martin Andersen 2017-06-18 13:32:11 UTC
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
Comment 33 Ville Syrjala 2017-07-05 17:40:45 UTC
(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?
Comment 34 Martin Andersen 2017-07-05 18:08:42 UTC
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.
Comment 35 Ville Syrjala 2017-10-11 18:15:22 UTC
(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.
Comment 36 Martin Andersen 2017-10-12 09:17:15 UTC
(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.
Comment 37 Ville Syrjala 2017-10-19 14:08:30 UTC
(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.
Comment 38 Jani Saarinen 2018-03-29 07:11:49 UTC
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.
Comment 39 Martin Andersen 2018-05-25 10:13:34 UTC
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
Comment 40 Martin Andersen 2018-05-25 10:15:53 UTC
Created attachment 139752 [details]
dmesg from nonworking 4.16.11 kernel
Comment 41 Martin Andersen 2018-05-25 10:16:30 UTC
Created attachment 139753 [details]
Xorg.0.log from nonworking 4.16.11 kernel
Comment 42 Martin Andersen 2018-05-25 10:17:22 UTC
Created attachment 139754 [details]
dmesg (w/ debug output) from nonworking 4.16.11 kernel - directly attached bypassing switch
Comment 43 Martin Andersen 2018-05-25 10:18:11 UTC
Created attachment 139755 [details]
dmesg (w/ drm.debug=0x1e) from correctly-working 3.18.109 kernel
Comment 44 Martin Andersen 2018-05-25 10:19:12 UTC
Created attachment 139756 [details]
Xorg.0.log from correctly-working 3.18.109 kernel
Comment 45 Martin Andersen 2018-05-25 10:24:00 UTC
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)
Comment 46 Martin Andersen 2018-07-04 09:01:45 UTC
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]
Comment 47 Lakshmi 2018-09-18 13:18:21 UTC
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.
Comment 48 Martin Andersen 2018-09-23 21:20:05 UTC
Created attachment 141702 [details]
drm.debug=0x1e from nonworking 4.19.0-994 kernel
Comment 49 Martin Andersen 2018-09-23 21:21:12 UTC
Created attachment 141703 [details]
Xorg.0.log from nonworking 4.19.0-994 kernel
Comment 50 Martin Andersen 2018-09-23 21:35:02 UTC
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
Comment 51 Martin Andersen 2018-09-25 13:43:08 UTC
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.
Comment 52 Martin Andersen 2018-10-02 13:11:25 UTC
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)
Comment 53 Lakshmi 2018-10-02 13:29:19 UTC
Martin, My apologies.
We will look in to this issue and come back to you soon.
Comment 54 Ville Syrjala 2018-10-02 13:56:49 UTC
Max bpc connector property patches are close to being ready:
https://patchwork.freedesktop.org/series/50295/
Comment 55 Martin Andersen 2018-10-02 14:38:48 UTC
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.
Comment 56 Lakshmi 2018-10-21 18:58:20 UTC
(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?
Comment 57 Martin Andersen 2018-11-01 15:45:20 UTC
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.)
Comment 58 Martin Andersen 2019-01-14 09:54:43 UTC
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.
Comment 59 Ville Syrjala 2019-01-14 17:20:28 UTC
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
Comment 60 Ville Syrjala 2019-01-14 17:20:55 UTC
(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
Comment 61 Martin Andersen 2019-01-21 11:21:13 UTC
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
Comment 62 Martin Andersen 2019-01-22 08:47:32 UTC
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.
Comment 63 Ville Syrjala 2019-01-22 14:09:28 UTC
xrandr --output <something> --set 'max bpc' 8
Comment 64 Martin Andersen 2019-01-22 15:11:22 UTC
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.
Comment 65 Martin Andersen 2019-02-06 11:22:33 UTC
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.
Comment 66 Martin Andersen 2019-02-06 11:24:59 UTC
Created attachment 143317 [details]
drm.debug=0x1e from working 5.0.0-994 kernel (after xrandr cmd manually issued)
Comment 67 Martin Andersen 2019-03-28 12:47:30 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.