Bug 106291

Created attachment 139191 [details]
HDMI disconnected

Created attachment 139192 [details]
Displayinfo when HDMI is connected

Created attachment 139193 [details]
Displayinfo when HDMI is disconnected

Further information:
Linux lrplayer 4.17.0-rc2 #1 SMP Thu Apr 26 20:44:09 CEST 2018 x86_64 GNU/Linux

This build is a drm-tip version (I added some logging to see what's wrong):
https://github.com/a1rwulf/drm-tip/commit/6e830b2204137035d5a2adf9837295e6a527cb03

Seems it does not even try to consider the hardcoded edid and it looks related to:
https://github.com/a1rwulf/drm-tip/blob/7a3cb2048f795289f5857505dcf219216a81bbcc/drivers/gpu/drm/drm_edid.c#L1698

drm_probe_ddc fails when I disconnect hdmi and thus it bails out before trying to load the edid from the filesystem.
If I change this, it at least reads the edid but still fails due to some other errors.
Please let me know how I can help to fix this.

Jani, Ville, Shashank, can you take a look?

Do you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y in your kernel config?

Jani, I don't think this has anything to do with LSPCON.

Wolfgang, also should have asked, what are you trying to accomplish with the firmware EDID?

Yes, CONFIG_DRM_LOAD_EDID_FIRMWARE=y is in my kernel configuration.
I have several problems, that need a hardcoded EDID.

1. I'm using the nuc as a home theatre solution with kodi, thus I have an AVR and a TV connected.
I have problems when AVR is switched on at the same time I switch on the NUC, my AVR does not send appropriate EDID information and I end up without audio.

2. Our GBM kodi implementation needs a valid connector and encoder in order to setup rendering, otherwise the application is stopped, I want to workaround this by hardcoding the edid.

3. I have a broken monitor that does not send an EDID at all, which requires me to hardcode the edid.
I hope this gives you an idea about my use cases.

Yes, CONFIG_DRM_LOAD_EDID_FIRMWARE=y is in my kernel configuration.
I have several problems, that need a hardcoded EDID.

1. I'm using the nuc as a home theatre solution with kodi, thus I have an AVR and a TV connected.
I have problems when AVR is switched on at the same time I switch on the NUC, my AVR does not send appropriate EDID information and I end up without audio.

2. Our GBM kodi implementation needs a valid connector and encoder in order to setup rendering, otherwise the application is stopped, I want to workaround this by hardcoding the edid.

3. I have a broken monitor that does not send an EDID at all, which requires me to hardcode the edid.
I hope this gives you an idea about my use cases.

Somehow I missed this in the logs at first,

[    1.265453] [drm] Got external EDID base block and 1 extension from "edid/edid.bin" for connector "DP-1"

That comes from the EDID firmware loader after it has loaded and parsed the EDID you want.

What appears to be the problem?

N.b. as it is an LSPCON device, it is DP from the driver perspective even though you have an HDMI connector on the chassis.

The complaint, aiui, was that overriding the edid doesn't override the detection status; try echo on > /sys/class/drm/card0-HDMI-A-1/status (replacing HDMI-A-1 as required).

(In reply to Chris Wilson from comment #12)
> The complaint, aiui, was that overriding the edid doesn't override the
> detection status; try echo on > /sys/class/drm/card0-HDMI-A-1/status
> (replacing HDMI-A-1 as required).

Maybe. DDC probe needs to work before firmware EDID gets loaded. It does get loaded. The additionally debugs Wolfgang added concur.

OK thanks for your input so far.
Seems that I need to change my testing procedure.
I did the following:
Hardcode the EDID, disconnect the HDMI cable and see if kodi can still initialize rendering.
As this failed I assumed the driver does not use my edid at all.

Given the new facts, I'll do new tests today:

1)
Hardcode the EDID of my 1080p Monitor and connect to my 4k TV, so I can see if the hardcoded EDID is actually used, when connection status is "connected".

2)
Overwrite the connection status manually and see how dmesg looks like when no HDMI cable is physically connected.

(In reply to Wolfgang Haupt from comment #14)
> Hardcode the EDID, disconnect the HDMI cable and see if kodi can still
> initialize rendering.

Right, as Chris noted, using the firmware EDID does not change the detection status. If the hotplug and DDC probe work, then you get the firmware EDID as you plug in the cable. If the detection does not work (or you want to override it) you can use sysfs, or if you want to force it from boot, you can use something like video=DP-1:<xres>x<yres>e where the e is the force enable.

Chris, does just video=DP-1:e work? drm_mode_parse_command_line_for_connector() is painful to read...

OK this is what I get:

Test No. 1 (HDMI connected):
Storing the EDID from a 1080p monitor and using it on a 4k TV.
I only see 1080p modes with 50, 59.94 and 60Hz modes.
So everything working as expected.

Test No. 2 (HDMI disconnected):
I have the "video=" setting in my kernel config.
Depending on what format I use, I see different results, but none of them works.
Most promising is "video=DP-1:e" see log "dmesg_e.log".

Created attachment 139235 [details]
dmesg_e.log

It seems to me the drm.edid_firmware option (that this bug was originally about) works as expected.

Obviously everything about DP link fail when you don't have a cable connected. I'm not sure what your expectation is. That can't work.

(In reply to Wolfgang Haupt from comment #9)
> 2. Our GBM kodi implementation needs a valid connector and encoder in order
> to setup rendering, otherwise the application is stopped, I want to
> workaround this by hardcoding the edid.

I'm turning to this one, and wondering if that's reasonable behavior for your userspace.

(In reply to Jani Nikula from comment #19)
> It seems to me the drm.edid_firmware option (that this bug was originally
> about) works as expected.

Yes we can agree on that one.

> Obviously everything about DP link fail when you don't have a cable
> connected. I'm not sure what your expectation is. That can't work.

I want to force display on digital output and hardcode the edid.
May I ask about the "why" it can't work, prior to kernel 4.15 it was possible to use:
"initrd=/edid.cpio drm_kms_helper.edid_firmware=DP-1:edid/edid.bin video=DP-1:D"


> (In reply to Wolfgang Haupt from comment #9)
> > 2. Our GBM kodi implementation needs a valid connector and encoder in order
> > to setup rendering, otherwise the application is stopped, I want to
> > workaround this by hardcoding the edid.
> 
> I'm turning to this one, and wondering if that's reasonable behavior for
> your userspace.

We are working towards a better solution already, but it's a huge undertaking and could easily take us another year.
As stated above, I was able to workaround this in older kernels.

(In reply to Wolfgang Haupt from comment #20)
> (In reply to Jani Nikula from comment #19)
> > It seems to me the drm.edid_firmware option (that this bug was originally
> > about) works as expected.
> 
> Yes we can agree on that one.
> 
> > Obviously everything about DP link fail when you don't have a cable
> > connected. I'm not sure what your expectation is. That can't work.
> 
> I want to force display on digital output and hardcode the edid.
> May I ask about the "why" it can't work

In order to light up a DP link we have to talk to the device at the other end of the cable. There's a whole slew of parameters that have to be negotiated between the source and sink devices. If there's nothing connected we won't get an answer to any of the queries and things will probably go badly hence forth. In order to do this properly, we'd basically have to implement a simulated DP sink in the driver and talk to that instead of the real thing. And once the real thing would get plugged in we'd have to switch over to talking to it instead of the simulation, and renegotiate everything.

In the case of LSPCON the DP device is actually right there on the motherboard, so in theory we should be able to talk to it. However I believe the LSPCON devices may snoop the EDID of the actual display and change their behaviour accordingly. If there's nothing to snoop they may just fail to respond in a meaningful manner to our queries.

In this case it looks like the LSPCON devices is maybe telling us that it doesn't support any DP link rates, and we print out a warning since that isn't a valid response as far as the DP spec is concerned.

It migth be interesting to see what it's reporting actually:
dd if=/dev/drm_dp_aux0 > dpcd

and attach the file to the bug. Use ddrescue instead of you get an error and resulting dump isn't the full 1 MiB in size.

Please attach dmesg with drm.debug=14 for the failing case (drm.edid_firmware=DP-1:edid/edid.bin video=DP-1:D).

Created attachment 139320 [details]
drm.debug=14

Created attachment 139321 [details]
dpcd dump

Please note:
I have done this using ubuntu with drm-tip mainline kernel from 2.5.2018, as my other system is a LibreELEC linux which has no packetmanager, dd didn't work and I have no ddrescue there.
Hope it doesn't matter, both are quite recent drm-tip kernels.

(In reply to Wolfgang Haupt from comment #24)
> Created attachment 139321 [details]
> dpcd dump
> 
> Please note:
> I have done this using ubuntu with drm-tip mainline kernel from 2.5.2018, as
> my other system is a LibreELEC linux which has no packetmanager, dd didn't
> work and I have no ddrescue there.
> Hope it doesn't matter, both are quite recent drm-tip kernels.

00000000  12 14 c4 01 01 15 01 81  00 00 04 00 0f 00 04 00  |................|

So it does in fact advertize 5.4Gbps link rate.

So it seems the the problem is due to the driver not reading/parsing the DPCD when we force the connector state. Not and impossible thing to do, but would certainly require shuffling a bunch of code around.

(In reply to Ville Syrjala from comment #25)
> (In reply to Wolfgang Haupt from comment #24)
> > Created attachment 139321 [details]
> > dpcd dump
> > 
> > Please note:
> > I have done this using ubuntu with drm-tip mainline kernel from 2.5.2018, as
> > my other system is a LibreELEC linux which has no packetmanager, dd didn't
> > work and I have no ddrescue there.
> > Hope it doesn't matter, both are quite recent drm-tip kernels.
> 
> 00000000  12 14 c4 01 01 15 01 81  00 00 04 00 0f 00 04 00 
> |................|
> 
> So it does in fact advertize 5.4Gbps link rate.
> 
> So it seems the the problem is due to the driver not reading/parsing the
> DPCD when we force the connector state. Not and impossible thing to do, but
> would certainly require shuffling a bunch of code around.

Actually, it just occurred to me that maybe the best option would be to change the connector force to simply ignore the SINK_COUNT for DP, and otherwise work exactly the same way as the normal detect path. That way the status could only be forced in cases where there is an actual DP device we can talk to but there's nothing plugged into its downstream ports.

Looks like we'd have to redo the locking scheme for the ->force() hook to match how we handle the detect hook. Might be a good idea to do that anyway, since the current scheme is rather inconsistent.

Updated subject to reflect the underlying problem, it's the DP connector forcing that fails. It's not trivial to fix, and it's frankly pretty low on the list of priorities. (Adjusting priority as well.)

Remotely related bug 106596. *NOT* a dupe.

Related bug 103347

Here's a crazy idea I got, please try:

http://patchwork.freedesktop.org/patch/msgid/20180620081105.31868-1-jani.nikula@intel.com

Priority to low/enhancement. It's pretty safe to say we're not working on this, but will accept patches.

*** Bug 103347 has been marked as a duplicate of this bug. ***

You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.

-- 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/intel/issues/113.