As advised on launchpad.net I'm reporting this issue upstream: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1412730 HW: HP Elitebook 8749w video: Mobility Radeon HD 5870 OS: Ubuntu 14.04.2 xorg: 1:7.7+1ubuntu8 My Laptop HP Elitebook 8740w has two external screens connected, 1 DELL U2412M connected to vga connector, and 1 DELL U2415 connected to Displayport. When booting up and with screens attached and active, the 2415 boots in 1024x768 resolution, the 2412 boots at the same moment in 1920x1200 as it should. At the point where the login screen appears the 2415 goes in power save mode, most of the time. After logging in, turning the 2415 off and on, sometimes helps the get the screen active (out of power save). Also switching VT7 to another and back helps. When it gets active, the resolution is 1024x768, not 1920x1200. In unity-control-center in display settings the 2415 is displayed as "Unknown Display" and the maximum resolution I can select is 1024x768. Tried windows 8.1, no issues with both screens. Tried fglrx, not theses issues, but lag. Current partial workaround: Exported edid form U2415 and booting now with kernel commandline parameter drm_kms_helper.edid_firmware=DP-1:edid/U2415.edid With this workaround, only power save issue exists. Please advise if you need more info
Is this still an issue with a newer kernel?
Tested with 3.19.0-031900-generic. Same behaviour.
Just an update. At the moment I'm running a newer kernel. 4.1.1-040101-generic Behaviour has changed. I don't have to use the extra kernel parameter drm_kms_helper.edid_firmware. Without it the monitor seems to be detected properly. So resolution is as it should be 1920X1200, at boot time, and also when logging in. However the power save issue still remains. - when the system tell the monitors to go to sleep, they both do, but when wakingg the screens, the U2415 offten won't come out of power save mode, the system is very sluggish at that moment. I'm not able to trigger the monitor to come out of standby. Not by calling xrandr in terminal, switching between VT's, or powering down the monitor. After plugging out the displayport of the U2415, the system becomes responsive again. - after a system suspend to ram the same as above happens. With a reboot everything seems normal again, and in the event the U2415 has gone into power save mode during login, switching between VT's will normally get it out off power save.
Created attachment 120036 [details] Reverse bisect log Did a reverse bisect. This commit seems to have fixed the detection issue. [1d002fa720738bcd0bddb9178e9ea0773288e1dd] drm/dp: Use large transactions for I2C over AUX For the other issue I will file a separate report.
I have the same powersave issue with a Dell U2414H (1920*1080). It's a simple monitor setup (only one screen plugged to the videocard). On a Radeon HD5850 or a GeForce GTX 950 (both with free drivers), my motherboard POST is displayed, but when Fedora begins to load the screen goes to powersave. I have to unplug and plug again the DisplayPort cable on the videocard to get the screen back. Note that if I remember well, sometimes it works perfectly. The problem also occurs when I reboot the computer from Fedora, then the screen stays in powersave mode, I don't even see the motherboard POST. The screen is plugged with a DisplayPort (to videocard) <--> MiniDisplayPort (to the screen). This is cable which comes with the screen. The screen is configured in DP1.1a mode. I can switch to DP1.2 with the OSD screen menu, in that case the Radeon seems to handle it (though the powersave issue remains) but the GeForce card get not more screen at all. I just got a second screen from Dell RMA, and the problem remains. My config: Fedora 23 (x86-64) kernel 4.4.6-300.fc23.x86_64 libdrm 2.4.66-1.fc23 Please please fix it, this is a really boring issue :(
The problem is still present in Fedora 24: - kernel 4.6.7-300.x86_64 - libdrm 2.4.70-1.x86_64
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/590.
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.