Created attachment 84538 [details] Xorg logfile I have a Gigabyte GA-H87N-wifi motherboard, which explicitly supports 3 monitors at the same time from the motherboards' onboard graphics (2x HDMI, 1x DVI). The CPU is an Intel 4570S with HD4600 graphics (also supporting 3 heads at the same time). However, I can only get 2 monitors (any 2, but not all 3) working. All monitors are identical 1600x1200 (NEC LCD2070NX). The KDE systemsettings GUI helpfully shows icons for all 3 monitors, but one is always greyed out, and attempting to enable it emits "Failed to set mode: Invalid argument" in Xorg.0.log. Xrandr compians "Configure crtc 2 failed". However, it's clear that the graphics hardware can handle 3 outputs, since it refers to "pipe 0, pipe 1 and pipe 2" in the logs. Google doesn't show anything very helpful, except to warn that in older graphics hardware (definitely not this motherboard) there may be more output connectors than graphics pipelines, and that in the HD4600 there are only 2x PLL, so 2 of the monitors need to be identically clocked (as they indeed are). I'm using the xorg-edgers package, built a couple of days ago from git, and this probleme affects both the latest Ubuntu (Saucy), and Mageia Alpha 4. I'm using a very recent kernel, 3.11.0. Thanks for your help - please let me know if there's anything I can do to assist in debugging/testing. P.S. I originally filed this here, but I think it is really an Xorg bug, rather than an Ubuntu-specific one. https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1215449
Can you please try to set up the 3 pipe configuration using the xrandr tool? This way we can exclude a bug in the kde gui tool. If that doesn't help please boot with drm.debug=0xe added to your kernel cmdline, reproduce the issue (using raw xrandr, no gui tools) and then attach the output of dmesg. Please make sure that dmesg is complete (including early boot logs). If that's not the case please increase the dmesg buffer by adding log_buf_size=4M or so to your kernel bootline.
Thanks for your help. Here's what happens with xrandr: $ xrandr --verbose --output HDMI1 --auto --output HDMI2 --auto --output HDMI3 --auto crtc 0: 1600x1200 60.0 +1600+0 HDMI3" crtc 1: 1600x1200 60.0 +3200+42 "HDMI2" crtc 2: 1600x1200 60.0 +0+0 "HDMI1" xrandr: Configure crtc failed crtc 0: disable crtc 1: disable crtc 2: disable screen 0: revert crtc 0: revert crtc 1: revert crtc 2: revert .... and this in Xorg.0.log [102235.666] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [102235.820] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [103210.958] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [103211.108] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [103511.282] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [103511.436] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [108079.743] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [108079.896] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [108979.952] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [108980.104] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [109280.268] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [109280.420] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [116494.044] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [116494.196] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal [116505.236] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 2 using HDMI1, position (0, 0), rotation normal [116505.238] (EE) intel(0): failed to set mode: Invalid argument [116505.294] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 0 using HDMI3, position (1600, 0), rotation normal [116505.448] (II) intel(0): switch to mode 1600x1200@60.0 on pipe 1 using HDMI2, position (3200, 42), rotation normal I'll try the drm.debug in a moment.
Created attachment 84542 [details] Output of dmesg (gzipped) 1. Modified kernel command line. This is the output of /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.11.0-3-generic root=UUID=770c7876-5e8a-48db-aff0-96494bf2f248 ro drm.debug=0xe log_buf_size=4M vt.handoff=7 2. Booted. 3. Repeated the xrandr command to enable all 3 outputs. (same thing happens: it fails, and reverts to the 2 that were initially enabled). 4. Attached dmesg.
Oh, 3 hdmi monitors and we don't yet support pll sharing on Haswell for hdmi clocks. Feature request ... but please stay around, somewhere on my todo list is to fix this ;-)
For now you either need to connect one screen with DP or VGA to work around the clock limit for hdmi ...
I haven't got 3 x HDMI ports. The ports on the motherboard are: HDMI 1, HDMI 2, DVI picture here: http://www.gigabyte.com/products/product-page.aspx?pid=4601#ov Though I see what you mean, in that the outputs all name themselves HDMI1-3. My monitors all have DVI ports, so I have one cable with DVI-DVI and 2 cables with HDMI-DVI. Anyway, let me know what else you need from me, and I'll do my best to help.
Just wondering - is there anything I can do to help. I think this is going to become quite a popular feature, given that many Linux users are now specifically opting for Intel graphics because it is a more open driver than the alternatives... and Intel is heavily promoting the NUC with a triple-head graphics capability. Alternatively, if this feature isn't planned for a while, can I suggest it would be worth placing a message in Xorg.0.log such as "3rd-monitor support not implemented in this driver yet, see bug 68485", so that others can easily find it without going through hours of debugging and googling.
I've got the same problem (slightly different board: GA-Z87N-WIFI, but with 2x HDMI, 1x DVI). The symptoms seem to be the same, though I'm running a slightly different kernel (3.10.7). I'm running Arch, not Ubuntu, and I'm also happy to play around with possible fixes, including patching compiling new kernels as necessary.
I have Intel graphics card and it supports triple head setup very well. My setup is: intel-dri 9.2.0-2 mesa 9.2.0-2 xorg-server 1.14.3-1 libdrm 2.4.46-2 linux 3.10.10-1 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) I updated kernel to 3.11.1 after it appeared in Archlinux's repo and one of screens stopped working. I tried to fix it with xrandr but I got only "xrandr: Configure crtc failed" errors and these in Xorg.0.log: [ 10.661] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 0 using HDMI1, position (0, 0), rotation normal [ 10.903] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 1 using VGA1, position (2560, 0), rotation normal [ 11.043] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 2 using HDMI2, position (1280, 0), rotation normal [ 11.043] (EE) intel(0): failed to set mode: Invalid argument I am ready to help in fixing this.
(In reply to comment #9) > I have Intel graphics card and it supports triple head setup very well. My > setup is: > intel-dri 9.2.0-2 > mesa 9.2.0-2 > xorg-server 1.14.3-1 > libdrm 2.4.46-2 > linux 3.10.10-1 > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen > Core processor Graphics Controller (rev 09) > > I updated kernel to 3.11.1 after it appeared in Archlinux's repo and one of > screens stopped working. > I tried to fix it with xrandr but I got only "xrandr: Configure crtc failed" > errors and these in Xorg.0.log: > > [ 10.661] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 0 using > HDMI1, position (0, 0), rotation normal > [ 10.903] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 1 using > VGA1, position (2560, 0), rotation normal > [ 11.043] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 2 using > HDMI2, position (1280, 0), rotation normal > [ 11.043] (EE) intel(0): failed to set mode: Invalid argument > > I am ready to help in fixing this. I have a similar setup and am experiencing the same thing. Downgrading to 3.10 fixed the issue. I'm also happy to help fix this.
(In reply to comment #10) > (In reply to comment #9) > > I have Intel graphics card and it supports triple head setup very well. My > > setup is: > > intel-dri 9.2.0-2 > > mesa 9.2.0-2 > > xorg-server 1.14.3-1 > > libdrm 2.4.46-2 > > linux 3.10.10-1 > > 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen > > Core processor Graphics Controller (rev 09) > > > > I updated kernel to 3.11.1 after it appeared in Archlinux's repo and one of > > screens stopped working. > > I tried to fix it with xrandr but I got only "xrandr: Configure crtc failed" > > errors and these in Xorg.0.log: > > > > [ 10.661] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 0 using > > HDMI1, position (0, 0), rotation normal > > [ 10.903] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 1 using > > VGA1, position (2560, 0), rotation normal > > [ 11.043] (II) intel(0): switch to mode 1280x1024@60.0 on pipe 2 using > > HDMI2, position (1280, 0), rotation normal > > [ 11.043] (EE) intel(0): failed to set mode: Invalid argument > > > > I am ready to help in fixing this. > > I have a similar setup and am experiencing the same thing. Downgrading to > 3.10 fixed the issue. I'm also happy to help fix this. This is a different issue, since your systems should work. Can you please file a new bug report about it?
To clarify: This bug is about triple monitor not work with 3x any combination of HDMI/DVI-D. If any of your screens is a VGA/DP/DVI-I or if triple display worked and regressed in recent kernels then you have a different bug.
Interestingly, I can now make it work if I use a passive DVI->VGA adapter. This configuration works for me (albeit with slightly imperfect quality on the VGA-connected monitor): Monitor #1 HDMI output -> adapter -> DVI input (1600x1200) Monitor #2 HDMI output -> adapter -> DVI input (1600x1200) Monitor #3 DVI output -> adapter -> VGA input (1600x1200) The 3rd one has to be VGA, or it won't work. Using a direct DVI->DVI cable is problematic. Also, the VGA port isn't autidetected as 1600x1200 capable, but this can be fixed with: xrandr --addmode VGA1 1600x1200 xrandr --output VGA1 --mode 1600x1200
Passive DVI->VGA means you're using the analog side of the DVI connector, which has a different reference clock. So yup, 2x hdmi + 1x VGA is expected to work, it doesn't matter that you have a dvi connector in-between. Of course this only applies to passive conversion cables, for active cables you need to look at the input.
Created attachment 88373 [details] [review] Bug fix Hi The attached patch allows you to share the HDMI/DVI clocks when you have 2 monitors using the same exact pixel clock. With this, you can have your 3-pipe setup working if any 2 monitors are using the same configuration. Please notice that you can have 2 modes with the same resolution but not the same pixel clock, so just looking at the resolution doesn't help you: you have to run "xrandr --verbose" and then look at the pixel clock. On xrandr, the line for a mode will be: WIDTHxHEIGHT (identifier) pixel_clock hsync_vsync Example: 1920x1080 (0x46) 148.5MHz +HSync +VSync To select this precise mode, you have to use the identifier when using xrandr, so you'll do something like: xrandr --output HDMI1 --mode 0x46 xrandr --output HDMI2 --mode 0x46 (only if both monitors support the mode with identifier 0x46) In case you need help, please just attach the output of "xrandr --verbose" and I'll help you. Thanks, Paulo
Patch merged, closing bug. http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queued&id=0694001b27efe5878ba5bd273e39b384821d865e Thanks, Paulo
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.