Bug 106291 - DP connector force enable does not work properly
Summary: DP connector force enable does not work properly
Status: NEEDINFO
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: low enhancement
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev, Triaged
Keywords:
: 103347 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-04-28 08:03 UTC by Wolfgang Haupt
Modified: 2018-09-11 08:07 UTC (History)
6 users (show)

See Also:
i915 platform: KBL
i915 features: display/DP


Attachments
HDMI connected (279.53 KB, text/x-log)
2018-04-28 08:03 UTC, Wolfgang Haupt
no flags Details
HDMI disconnected (342.74 KB, text/x-log)
2018-04-28 08:04 UTC, Wolfgang Haupt
no flags Details
Displayinfo when HDMI is connected (4.32 KB, text/x-log)
2018-04-28 08:04 UTC, Wolfgang Haupt
no flags Details
Displayinfo when HDMI is disconnected (20.20 KB, text/x-log)
2018-04-28 08:05 UTC, Wolfgang Haupt
no flags Details
dmesg_e.log (3.85 MB, text/plain)
2018-04-30 19:59 UTC, Wolfgang Haupt
no flags Details
drm.debug=14 (3.61 MB, text/x-log)
2018-05-03 16:06 UTC, Wolfgang Haupt
no flags Details
dpcd dump (1.00 MB, application/octet-stream)
2018-05-03 16:43 UTC, Wolfgang Haupt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Haupt 2018-04-28 08:03:42 UTC
Created attachment 139190 [details]
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.
Comment 1 Wolfgang Haupt 2018-04-28 08:04:16 UTC
Created attachment 139191 [details]
HDMI disconnected
Comment 2 Wolfgang Haupt 2018-04-28 08:04:47 UTC
Created attachment 139192 [details]
Displayinfo when HDMI is connected
Comment 3 Wolfgang Haupt 2018-04-28 08:05:08 UTC
Created attachment 139193 [details]
Displayinfo when HDMI is disconnected
Comment 4 Wolfgang Haupt 2018-04-28 08:14:44 UTC
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.
Comment 5 Jani Saarinen 2018-04-30 07:02:21 UTC
Jani, Ville, Shashank, can you take a look?
Comment 6 Jani Nikula 2018-04-30 07:17:04 UTC
Do you have CONFIG_DRM_LOAD_EDID_FIRMWARE=y in your kernel config?
Comment 7 Jani Nikula 2018-04-30 07:23:34 UTC
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?
Comment 8 Wolfgang Haupt 2018-04-30 09:20:58 UTC
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.
Comment 9 Wolfgang Haupt 2018-04-30 09:21:16 UTC
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.
Comment 10 Jani Nikula 2018-04-30 09:49:32 UTC
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?
Comment 11 Jani Nikula 2018-04-30 09:52:10 UTC
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.
Comment 12 Chris Wilson 2018-04-30 09:54:53 UTC
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).
Comment 13 Jani Nikula 2018-04-30 10:10:38 UTC
(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.
Comment 14 Wolfgang Haupt 2018-04-30 10:48:32 UTC
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.
Comment 15 Jani Nikula 2018-04-30 11:07:40 UTC
(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.
Comment 16 Jani Nikula 2018-04-30 11:11:00 UTC
Chris, does just video=DP-1:e work? drm_mode_parse_command_line_for_connector() is painful to read...
Comment 17 Wolfgang Haupt 2018-04-30 19:55:21 UTC
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".
Comment 18 Wolfgang Haupt 2018-04-30 19:59:59 UTC
Created attachment 139235 [details]
dmesg_e.log
Comment 19 Jani Nikula 2018-05-02 07:17:31 UTC
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.
Comment 20 Wolfgang Haupt 2018-05-02 19:09:34 UTC
(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.
Comment 21 Ville Syrjala 2018-05-02 19:32:39 UTC
(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.
Comment 22 Jani Nikula 2018-05-03 08:28:06 UTC
Please attach dmesg with drm.debug=14 for the failing case (drm.edid_firmware=DP-1:edid/edid.bin video=DP-1:D).
Comment 23 Wolfgang Haupt 2018-05-03 16:06:03 UTC
Created attachment 139320 [details]
drm.debug=14
Comment 24 Wolfgang Haupt 2018-05-03 16:43:02 UTC
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.
Comment 25 Ville Syrjala 2018-05-03 17:22:20 UTC
(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.
Comment 26 Ville Syrjala 2018-05-03 17:27:36 UTC
(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.
Comment 27 Jani Nikula 2018-05-17 18:05:19 UTC
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.)
Comment 28 Jani Nikula 2018-05-25 17:20:39 UTC
Remotely related bug 106596. *NOT* a dupe.
Comment 29 Phil67ago 2018-06-19 18:53:18 UTC
Related bug 103347
Comment 30 Jani Nikula 2018-06-20 08:21:06 UTC
Here's a crazy idea I got, please try:

http://patchwork.freedesktop.org/patch/msgid/20180620081105.31868-1-jani.nikula@intel.com
Comment 31 Jani Nikula 2018-09-11 08:02:38 UTC
Priority to low/enhancement. It's pretty safe to say we're not working on this, but will accept patches.
Comment 32 Jani Nikula 2018-09-11 08:07:22 UTC
*** Bug 103347 has been marked as a duplicate of this bug. ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.