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
@a1rwulfsaid:(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.@vsyrjalasaid:(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.@a1rwulfuploaded an attachment:Attachment 139320, "drm.debug=14":
dmesg_debug_14.log@a1rwulfuploaded an attachment: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.Attachment 139321, "dpcd dump":
dpcd@vsyrjalasaid:(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.@vsyrjalasaid:(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.@janisaid:Remotely related bug 106596. NOT a dupe.
Related bug 103347
@janisaid:Here's a crazy idea I got, please try:
http://patchwork.freedesktop.org/patch/msgid/20180620081105.31868-1-jani.nikula@intel.com
@janiclosed a related bug:*** Bug 103347 has been marked as a duplicate of this bug. ***
mentioned in issue #347 (closed)
