DP connector force enable does not work properly
Submitted by a1rwulf @a1rwulf
Assigned to Intel GFX Bugs mailing list
Link to original bug (#106291)
Description
Created attachment 139190
HDMI connected
When I want to override my edid by using the drm.edid_firmware switch, it seems that the intel drm driver does not even try to use the edid.
See attached logs.
Attachment 139190, "HDMI connected":
dmesg_connected.log
Activity
added Community Enhancement Needs Information feature: display/DP platform: KBL priority::low + 1 deleted label
@a1rwulfuploaded an attachment:Attachment 139191, "HDMI disconnected":
dmesg_disconnected.log@a1rwulfuploaded an attachment:Attachment 139192, "Displayinfo when HDMI is connected":
displayinfo_connected.log@a1rwulfuploaded an attachment:Attachment 139193, "Displayinfo when HDMI is disconnected":
displayinfo_disconnected.log
@a1rwulfsaid:Further information:
Linux lrplayer 4.17.0-rc2 #1 (moved) 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.@a1rwulfsaid:Yes, CONFIG_DRM_LOAD_EDID_FIRMWARE=y is in my kernel configuration.
I have several problems, that need a hardcoded EDID.
- 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.- I'm using the nuc as a home theatre solution with kodi, thus I have an AVR and a TV connected.
@a1rwulfsaid:Yes, CONFIG_DRM_LOAD_EDID_FIRMWARE=y is in my kernel configuration.
I have several problems, that need a hardcoded EDID.
- 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.- I'm using the nuc as a home theatre solution with kodi, thus I have an AVR and a TV connected.
@janisaid: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?@janisaid:(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.@a1rwulfsaid: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.@janisaid:(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:``x``e where the e is the force enable.@a1rwulfsaid: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".@a1rwulfuploaded an attachment:Attachment 139235, "dmesg_e.log":
dmesg_e.log@janisaid: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)- 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.- Our GBM kodi implementation needs a valid connector and encoder in order
