Description of problem: In Fedora 22, I ran a three monitor setup via Dell docking station. The laptop has optimus enabled as the nvidia card only supports 2 outputs where the intel supports three. Since upgrading to Fedora 23, I can only get output from the laptop screen and one external monitor. In the Displays tool, Gnome sees the third monitor, but enabling it causes Gnome to crash. Attempting this with xrandr shows an an error "crtc 5 failed". If I simply do 'xrandr --auto' it enables the third monitor at full resolution but then mirrors it to the first display. As such, I have no way to get the same functionality I had with this setup in Fedora 22, which worked simply via the Gnome Displays tool. Because this laptop has Optimus, disabling Optimus, brings me down to 2 displays max due to limits on nVidia card. I do not have the nvidia binary or bumblebee installed - only FOSS drivers. Version-Release number of selected component (if applicable): Fedora 23 kernel: 4.2.3-300.fc23.x86_64 xorg-x11-server-Xorg-1.18.0-0.4.20150907.fc23.x86_64 xorg-x11-server-utils-7.7-16.fc23.x86_64 intel-gpu-tools-2.99.917-16.20150729.fc23.x86_64 xorg-x11-drv-intel-2.99.917-16.20150729.fc23.x86_64 How reproducible: Always Steps to Reproduce: 1. Add 2 external monitors to Dell dock with Optimus 2. Login to Gnome session 3. Attempt to enable third monitor as "Secondary" 4. Observe the ensuing crashy spectacle - For best results rinse and repeat, Gnome fully becomes unresponsive after about 3 tries Actual results: Only two monitors can be enabled, with the laptop screen being one of them. Expected results: External monitors work as advertised in the Display tool, as supported by the hardware. In other words, how it worked exactly in Fedora 22. Additional info: $ xrandr -q Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192 LVDS-1 connected (normal left inverted right x axis y axis) 1920x1080 60.01 + 40.01 1680x1050 59.95 1400x1050 59.98 1280x1024 59.89 1280x960 59.94 1152x864 59.96 1024x768 59.92 800x600 59.86 640x480 59.38 720x400 59.55 640x400 59.95 640x350 59.77 DP-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm 1920x1200 59.95*+ 1920x1080 60.00 1600x1200 60.00 1680x1050 59.88 1280x1024 60.02 1280x960 60.00 1024x768 60.00 800x600 60.32 640x480 60.00 720x400 70.08 DP-2 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 59.95*+ 1600x1200 60.00 1680x1050 59.88 1280x1024 75.02 60.02 1152x864 75.00 1024x768 75.08 60.00 800x600 75.00 60.32 640x480 75.00 60.00 720x400 70.08 HDMI-1 disconnected (normal left inverted right x axis y axis) VGA-1 disconnected (normal left inverted right x axis y axis)
Proposed as a Blocker for 23-final by Fedora user vwbusguy using the blocker tracking app because: Severe regression that can crash Gnome entirely. Limits productivity for regular workstation functional use.
For clarification based on IRC conversation in #Fedora-QA: * Two monitors is still a problem. I cannot simply enable the two extarnal monitors and disable the laptop screen. The laptop screen stays enabled even if the lid is closed. * The reason this is a blocker request is that the basic usage of the GUI tool causes an outright DE crash. To that extent alone, the "third monitor" is irrelevant. * This has nothing directly to do with Optimus. Bumblebee is not installed, nor being used. I only mentioned it to demonstrate the hardware situation. Optimus continues to work as far as I've been able to test so far. This is an Intel i915 related issue and not related to nouveau. * This worked out of the box in Fedora 22.
Not sure how to export abrt directly to this ticket, but: https://retrace.fedoraproject.org/faf/reports/863130/
*** Bug 1275784 has been marked as a duplicate of this bug. ***
https://retrace.fedoraproject.org/faf/reports/3732/
Created attachment 1086959 [details] /var/log/messages
*** Bug 1275791 has been marked as a duplicate of this bug. ***
Created attachment 1086976 [details] journalctl output
I'm +1 FE to this, but while this is unfortunate, I don't think it specifically violates any blocker criterion that I can find. It's *fuzzy* on: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test... Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention." I say fuzzy because it doesn't cause a specific app to fail. If you run the system with only a basic hardware configuration (the built-in monitor), things run successfully, which to me meets the "basic user intervention" criteria. So I'm a weak -1 blocker on this due to it being hardware-specific. I think that this is one of those cases where if it was the last blocker on the list, we likely wouldn't slip over it, which pretty much defines "not a blocker" to me.
I experience plenty of crashes of GNOME on Fedora 22 with two chained DisplayPort MST displays, which is also how many docking stations now work. So, I don't see how this is a substantial regression versus the current release.
David, I can't comment on your hardware. There are many vendor variances in docking stations, however, this setup has worked without issue in Fedora 22 and 21 until the 23 upgrade. Scott
If it's helpful, this is from Dell's business lineup: Dell Latitude E6530 with 2 24" Dell monitors connected via DVI. This isn't just some random commodity hardware, but this is a pretty common business setup offering from Dell. Again, this is not using proprietary drivers or bumblebee.
Since kernel 4.2, I also see issues with three monitors. I described them in bug 1256712 comment 13. Most of them are not crashes, but not waking up or forgetting display configuration. I see no crashes when using gnome-control-center to configure them. I have a single intel card in T450s. Lukas Brabec sees similar issues (same hardware). There seem to be severe regressions in the intel driver in the latest kernels.
I was not experiencing this on the latest Fedora 22 kernel, however, if I boot to the Fedora 22 kernel in Fedora 23, the issue still occurs, which means I don't think this is necessarily a kernel problem, but perhaps an xrandr or Gnome problem.
Discussed at 2015-10-29 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2015-10-29/f23-final-go_no_go-meeting_2.2015-10-29-16.00.html . Rejected as a blocker: this was considered to be likely some kind of hardware-specific issue and not to really constitute 'basic functionality' of the GNOME Control Center. Accepted as a freeze exception issue.
Just updating to note that the issue persists with same behavior with the xorg updates today. xorg-x11-server-Xorg-1.18.0-0.6.20151027.fc23.x86_64
I upgraded to 4.2.6 today and still noticed the same issues. On a whim, I downgraded to xorg-1.17 via dnf --releasever=22 and everything works again. It's clearly an issue with the xorg server update. All three monitors work fine otherwise on kernel 4.2.6 with Xorg-1.17.
If it's helpful, it's working with this package set: $ rpm -qa xorg* xorg-x11-drv-vmware-13.0.2-8.20150211git8f0cf7c.fc22.x86_64 xorg-x11-server-common-1.18.0-2.fc23.x86_64 xorg-x11-fonts-misc-7.5-15.fc23.noarch xorg-x11-server-Xorg-1.17.4-1.fc22.x86_64 xorg-x11-proto-devel-7.7-16.fc23.noarch xorg-x11-drv-fbdev-0.4.3-20.fc22.x86_64 xorg-x11-utils-7.5-20.fc23.x86_64 xorg-x11-fonts-ISO8859-1-100dpi-7.5-15.fc23.noarch xorg-x11-drv-nouveau-1.0.11-2.fc22.x86_64 xorg-x11-drv-vmmouse-13.0.99-1.fc22.x86_64 xorg-x11-xinit-1.3.4-10.fc23.x86_64 xorg-x11-drv-evdev-2.9.2-1.fc22.x86_64 xorg-x11-xauth-1.0.9-4.fc23.x86_64 xorg-x11-xkb-utils-7.7-16.fc23.x86_64 xorg-x11-drv-wacom-0.29.0-2.fc22.x86_64 xorg-x11-server-Xwayland-1.18.0-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-15.20150729.fc22.x86_64 xorg-x11-drv-ati-7.5.0-3.fc22.x86_64 xorg-x11-drv-vesa-2.3.2-20.fc22.x86_64 xorg-x11-resutils-7.5-12.fc23.x86_64 xorg-x11-drv-qxl-0.1.3-2.fc22.x86_64 xorg-x11-fonts-Type1-7.5-15.fc23.noarch xorg-x11-font-utils-7.5-29.fc23.x86_64 xorg-x11-drv-v4l-0.2.0-42.fc22.x86_64 xorg-x11-server-utils-7.7-17.fc23.x86_64 xorg-x11-drv-openchrome-0.3.3-14.fc22.x86_64 xorg-x11-drv-synaptics-1.8.2-2.fc22.x86_64
As an update, I tried out the new xorg-x11-server-1.18.0.2 and xorg-x11-drv-intel 2.99.917-18. The experience is now even more degraded. With multiple monitors, one of the external is turned on but cannot actually be accessed - it just shows the GDM background. The laptop monitor is turned on, but the graphics are badly distorted with mouse trails and artifacts making even resizing a window or copy/paste a tedious and painful experience. Again, regressing to the xorg server shipped in F22 removes all these issues.
Since there hasn't been any response from the package maintainers, I'm wondering if there's any more information I can possibly provide to help? I've provided a good amount of testing and details here and am wondering if it's worth any more effort on my part to report on this.
I confirm that I have similar issues as Scott on an HP docking station with two external monitors and the laptop monitor. I could also provide more detailed information if that is of any use for determining the root cause of the three monitor setups.
See also: bug 1269805
Appears to be addressed in an upstream issue: https://bugs.freedesktop.org/show_bug.cgi?id=89589 Maybe airlied can confirm?
Possibly also related to the patch referenced in this thread: https://www.spinics.net/lists/xorg/msg57087.html The same general hardware+symptoms.
I compiled a new RPM from the current xf86-video-intel master branch as there are some relevant recent commits, but still seeing the same issues from original report. Note that everything works with the current f23 kernel (4.2.8-300) and downgraded xorg server/driver from f22. The issue seems to be how xrandr and the driver are interacting with crtc's for i915.
As an aside, if it's helpful to the maintainer, I added this to the SPEC to get it to build: BuildRequires: libXScrnSaver-devel
FWIW, I'm experiencing similar issues with FC32 on a ThinkPad T440s (using an "Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)" according to "lspci"), connected to a Lenovo UltraDock. I use the laptop with the lid closed and two monitors connected to the docking station (one via DVI, the other via analog VGA). Very often, the second external monitor connected to the VGA port does not resume after the screen blanker has put the monitors into power-saving mode. In "dmesg", I see the following message: [176394.553305] [drm:check_crtc_state [i915]] *ERROR* mismatch in ips_enabled (expected 1, found 0) Disabling and enabling the monitor via xrandr brings it back to life, but this is somewhat inconvenient. If there is any update package I could help testing, I'd be glad to.
The issue I originally reported is now fixed as of at least: xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64 xorg-x11-drv-intel-2.99.917-19.20151206.fc23.x86_64