Bug 82349

Created attachment 104285 [details]
Forgot to run update-grub

Created attachment 104286 [details]
dmesg

I'm seeing this bug too.  It seems the Radeon bug report has a good explanation of what is happening (driver is caching the EDID but never gets updated when system is using drm_kms_helper).  Perhaps the Intel driver has a similar caching issue.

Kind of. It is just that the EDID is queried for audio capability during detect(), which is circumvented by drm_kms_heler.edid= What could do as a workaround is xrandr --output HDMI --off xrandr --set audio off; xrandr --output HDMI1 --preferred --set audio on;

I will try the work around... thanks!

That said, drm_kms_helper supplied EDID, in my case is on HDMI connector... audio *should* be enabled.  In other words, I would expect same behavior whether (same) EDID was detected from monitor or supplied by kernel.

  drm_kms_helper.edid_firmware=HDMI-A-1:edid/lg_D2342P_edid.bin

Am I missing something to properly force enabling my HDMI output (for video and sound) when monitor if off/disconnected during boot?

Hmm, I may be getting the effect of the overrides mixed up then. The xrandr trick may not work if it is not skipping the detect() on the HDMI port. Can you attach the edid you are using just so we can run it through a decoder to check.

The other override for *forced**detection* (my mistake above!) is video=HDMI-1-A:e

Created attachment 104790 [details]
EDID file I am supplying to drm_kms_helper

Rob, does this patch help?

Chris, does this patch make sense? ;) Should we check for connector type and only do this for HDMI/DP?

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 0a235fe61c9b..144a0368ccd0 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -288,6 +288,7 @@ int drm_load_edid_firmware(struct drm_connector *connector)
 
        drm_mode_connector_update_edid_property(connector, edid);
        ret = drm_add_edid_modes(connector, edid);
+       drm_edid_to_eld(connector, edid);
        kfree(edid);
 
        return ret;
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index 6857e9ad6339..5edc61f2f212 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -151,6 +151,7 @@ static int drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect
                        struct edid *edid = (struct edid *) connector->edid_blob_ptr->data;
 
                        count = drm_add_edid_modes(connector, edid);
+                       drm_edid_to_eld(connector, edid);
                } else
                        count = (*connector_funcs->get_modes)(connector);
        }

Timing out.  Seems like we need something like the fix Jani mentioned, but would need someone to test it (assuming it isn't already pushed).

Hi,

I can confirm that this patch works; tested with 4.0-rc5.

Background:

I have an ASUS Chromebox (Celeron 2955U) connected to an Onkyo RT-393 AVR via HDMI.  It very rarely (5-10% of the time) can initiate a successful handshake to the AVR so I dumped the EDID and have been using grub to enable the output and force the EDID:

drm_kms_helper.edid_firmware=HDMI-A-1:edid/edid.bin video=HDMI-A-1:D

This caused video to work 100% of the time but audio to work 0% of the time; eld was always empty and the AVR was indicating no signal:

/proc/asound/card0/eld#0.0
monitor_present	0
eld_valid	0

Now with this patch I rebooted and audio/video worked 3/3 times which has never happened in the ~6 weeks that I've had this hardware combo.

Patch submitted http://patchwork.freedesktop.org/patch/45675/

Jolan, thanks for picking this up and testing the patch.

To sidetrack a bit, have you reported your EDID issues? Is there a bug? If you're having issues reading EDID, you might want to give drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel a spin. There are some fixes headed for v4.1 kernel that might help. Just be sure to drop the edid_firmware part.

N.b. we'll want to fix this EDID override issue no matter what.

(In reply to Jani Nikula from comment #12)
> To sidetrack a bit, have you reported your EDID issues? Is there a bug? If
> you're having issues reading EDID, you might want to give drm-intel-nightly
> branch of http://cgit.freedesktop.org/drm-intel a spin. There are some fixes
> headed for v4.1 kernel that might help. Just be sure to drop the
> edid_firmware part.

No, I haven't reported the EDID issues yet as I haven't yet collected enough info to make a decent bug report.

There's definitely some sort of bug. Sometimes no EDID, sometimes EDID but the connector isn't enabled. I have a Raspberry Pi 2 connected to the same hardware with the same cable and it works 100% of the time so I don't think it's the other side.

I'll give drm-intel-nightly a try and report back results.

I just booted a drm-intel-nightly kernel remotely and the EDID/ELD info is populated and connector is reporting connected. So it seems it woke the receiver out of stand by and properly initialized which is a good sign.

Will do some more tests once I'm home to verify.

Created attachment 114673 [details]
nightly dmesg w/debug

Picks 720x480 instead of 1920x1080 but otherwise seems to initialize fine.

I can switch to 1920x1080 in X and audio has no problems either.

Created attachment 114674 [details]
HT-R393 edid

commit ad692b46dbf122ef90aadce3b389ef64c90e861d
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Mar 26 10:42:00 2015 +0200

    drm/edid: set ELD for firmware and debugfs override EDIDs

in Linus' tree. Thanks for the report.