DELL U2415 monitor detection issue

Investigated the issue some more.
Seems that EDID is not always given by the monitor when asked by the OS, for instance via "Detect Monitors" via gui or via xrandr via command line.
The workaround with xorg.conf I have abandoned. It wasnt working great too. Still a lot of time X was detecting resolutions again resulting in garbled screens or non active screen, however it stayed at the right resolution.

I managed to extract the edid for U2415 (256 byte), which i have attached.
Parse-edid has issues reading the extension block, but in Xorg.0.log I never saw issues reading the edid when it was available from the monitor.
My current workaround is by using kernel commandline parameter drm_kms_helper.edid_firmware=DP-1:edid/U2415.edid
This seems to work well.

However the power save issues are still there.
Attached the edid file.

Attached Xorg.0.log with correct detection of all connected monitors.
Also the use of the kernel parameter is visible.

Status changed to 'Confirmed' because the bug affects multiple users.

Just wanted to add that I am experiencing a similar issue with the 2415 not waking after suspend. I don't seem to be having the some problems with screen resolution, monitor detection, or weirdness with xrandr commands. If I can get the monitor working, xrandr works correctly every time.

Essentially, if the screen goes into power save mode, I am forced to reboot in order to wake it up.

My other monitor is an HP ZR24w and I'm running a fully updated 14.04 on a desktop machine.

I'm not sure what further info or log files might be useful, but let me know and I'll try to provide whatever I can.

I neglected to mention that my monitor is also connected via displayport. I am going to order an HDMI cable to see if that fixes it, will post back here again either way.

Connecting via HDMI rather than displayport has completely solved the waking issue for me (so far, at least). The monitor consistently wakes from sleep in the same configuration that I was using before suspending. Monitor settings are still not persistent across reboots, but this seems to be a more general issue that can be fixed via an appropriate startup script.

I have seen some reports of the U2415 having some problems with daisy-chaining via displayport and that Dell is giving people the runaround. Sounds like there is some flaw with the displayport, so perhaps we're seeing another effect of that.

Will report back in case anything changes.

Michiel Janssens, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal as it will automatically gather and attach updated debug information to this report:

apport-collect -p xorg 1412730

Please ensure you have xdiagnose installed, and that you click the Yes button for attaching additional debugging information.

As well, given the information from the prior release is already available, testing a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Hi Christopher,

The issues still exist, so still "unknown display" in All Settings - Displays", wrong resolution (highest 1024x786) on U2415, power saving issue on U2415. The issues seem exactly the same as on trusty.

I was not able to use the daily live iso, for xdiagnose extra debugging option requires /etc/default/grub to be updated and only works after reboot.
I had a physical Vivid install already running on this laptop (multi-boot), which i keep as clean as possible and use for this kind of issues, so no customizations.
So I upgraded this vivid install to the current state with apt-get dist-upgrade. After that I enabled xdiagnose extra debugging, deleted ~/.config/monitors.xml, booted and started the apport collection as you requested.

Please tell me if I can help you with more information.

Michiel Janssens, does fglrx provide a WORKAROUND to this issue?

Christopher,

Vivid with fglrx: none off the reported issues exist. U2415 is detected every time, display resolution is right, also dpms powersaving works as expected. In ATI control Center all hardware is detected. Also no xrandr issues
Trusty with fglrx: same as with vivid, none of the issues.

The main reason I'm not using fglrx is because it's proprietary, but also because the opensource radeon gives much better perfomance.
With fglrx there is lag in windows moving and resizing, also in videos. Next to that there is a lot of tearing visible. Whem turning on tear-free in Catalyst Control Center the lag gets even worse.

So fglrx is a workaround, but not a pleasant one. The lag and tearing is visible too many times during daily work.
At the moment I prefer my own workaround as mentioned above with the radeon driver and drm helper kernel parameter.
This way the displays work great without lag, but when booting, switching users in Unity or just going in suspend/standby I have to put the screen off and on a couple of times to get it out of standby.

One thing I noticed with the radeon driver: switching back and forth between vt7 and and another vt gets the U2415 out of standby too (eventually).

Michiel Janssens, just to clarify, this report will only be scoped to the issue regarding monitor detection on boot, not any of the other issues. You are welcome to file a new report, one report per unique issue. However, please keep in mind that a fix for the issue scoped to this report may very well fix the other issues.

Despite this, the issue you are reporting is an upstream one. Could you please report this problem to them via https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/Radeon ?

Please provide a direct URL to your bug report once you have made it so that it may be tracked.

Thank you for your understanding.

Christopher, thanks for helping out. I understand your scoping point and will file the bug upstream.

Upstream bug report URL:
https://bugs.freedesktop.org/show_bug.cgi?id=89420

Hi,

Is there a workaround for this ? Or when can I expect this to work, I'm using Ubuntu 15.x

Michiel Janssens, could you please test the latest upstream kernel available from the very top line at the top of the page from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release names are irrelevant for testing, and please do not test the daily folder)? Install instructions are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds . This will allow additional upstream developers to examine the issue.

If the latest kernel did not allow you to test to the issue (ex. you couldn't boot into the OS) please make a comment in your report about this, and continue to test the next most recent kernel version until you can test to the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this issue is fixed in the mainline kernel, please add the following tags by clicking on the yellow circle with a black pencil icon, next to the word Tags, located at the bottom of the report description:
kernel-fixed-upstream
kernel-fixed-upstream-X.Y-rcZ

Where X, Y, and Z are numbers corresponding to the kernel version.

If the mainline kernel does not fix the issue, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-X.Y-rcZ

Please note, an error to install the kernel does not fit the criteria of kernel-bug-exists-upstream.

Once testing of the latest upstream kernel is complete, please mark this report's Status as Confirmed. Please let us know your results.

Thank you for your understanding.

Ambreen, so your hardware is tracked, and priority increased, it will help immensely if you filed a new report via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

Hi, I did some exhaustive testing, but first mi current setup:
Current base install is 14.04.3 with HWE Vivid, so that's kernel 3.19.0-30.
With no extra parameters bootup will still give wrong resolution and monitor is not properly detected, so “unknown”. Bootup with kernel parameter drm_kms_helper.edid_firmware=DP-1:edid/U2415.edid gives consistently correct resolution and monitor is properly detected. Once in a while the U2415 is off when it should be on, but switching back and forth with VT gets the monitor on. So not much changes since last tests.

But testing with the following newer kernels:
4.0.0-040000, 4.0.9-0400090, 4.1.0-040100, 4.1.10-040110, 4.2.3-040203 and 4.3.0-040300rc6
Monitor is properly detected and resolution is correct since 4.1.0-040100. Still correct in 4.3.0-040300rc6.
So since 4.1.0-040100 there's no need for me to add the extra edid kernel parameter anymore.
So you I guess we can say its fixed in 4.1.0-040100.

However since 4.0.0-040000 I got another issue that might be related.
After suspend/resume the graphics are sloppy, kind of slow motion feel, mouse and keyboard input have great lag, response very slow.
A reboot can solve that, but also disconnecting displayport. And this only happens with displayport connected with U2415.
Should I file this in a new bug report?

Think I will report these results in the upstream bug report too.

Michiel Janssens:
>"Should I file this in a new bug report?"

Not at this point.

>"Think I will report these results in the upstream bug report too."

It's best not to mix and match multiple, even seemingly highly related issues into one report. What would be best, is this issue is settled first, and then any others may be dealt with separately.

With this in mind, the next step is to fully reverse commit bisect from kernel 3.13 to 4.1 in order to identify the last bad commit, followed immediately by the first good one. Once this commit has been identified, then it may be reviewed as a candidate for backporting into your release. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection#How_do_I_reverse_bisect_the_upstream_kernel.3F ?

Please note, finding adjacent kernel versions is not fully commit bisecting.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Hi Christopher, you are right. Thanks for guiding this in the right direction.
This is the first time for me digging this deep into the kernel, but happy to learn.

I will do bisecting as described in the article and will report back.

Hi Christopher,

I knew this would take some time, but the result is in de git bisect log.
Following the wiki I first did a mainline kernel reverse bisect from 3.13.11-ckt27 to v4.3-wily
Last bad was v4.0.9-wily
First good was v4.1-rc1-vivid

So after that I did a reverse commit bisect from 4.0 to 4.1-rc1

# first bad commit: [1d002fa720738bcd0bddb9178e9ea0773288e1dd] drm/dp: Use large transactions for I2C over AUX
So since this commit the monitor is properly detected and resolution is correct.