Jetson Nano DisplayPort Force - Bypass EDID

Autonomous Machines Jetson & Embedded Systems Jetson Nano
#1

Hello Team,

I am revisiting this previous topic again which was never fully resolved: Jetson Nano Fallback EDID

Basically I’m still trying to figure out how to bypass EDID detection and hard code an EDID or even just a single display timing into the kernel for Jetson Nano. I was able to bypass EDID protection and implement the fallback EDID properly for HDMI using the fallbackEDID in edid.c, but for DP it looks like all modes outside of 640x480 are getting filtered out by the DP driver per that previous thread and I don’t know how to fix this. Any guidance on how to implement this would be appreciated and this is for debugging purposes so I understand the risk of programming a display timing which is potentially not supported by either sink or source.

Best Regards,
Casey

#3

Hi,

Maybe you could check why the mode is getting filtered by reading the dp driver code.
The mode filter function may tell you the reason.

#5

Hello Wayne,

Per your last instruction on the previous thread I added the printk to the kernel log where you noted in fb.c. The result is this is printed in the kernel log after plugging the DP sink:

[ 121.445180] hpd: state 2 (Check EDID), hpd 1, pending_hpd_evt 0
[ 121.446607] xres 1280 yres 720
[ 121.446614] xres 1280 yres 720
[ 121.446618] xres 640 yres 480
[ 121.446623] xres 1920 yres 1080
[ 121.446628] xres 1920 yres 1080
[ 121.446632] xres 720 yres 480
[ 121.446637] xres 720 yres 576
[ 121.446641] xres 1280 yres 720
[ 121.446645] xres 1280 yres 720
[ 121.446649] xres 1920 yres 1080
[ 121.446652] xres 1920 yres 1080
[ 121.446656] xres 720 yres 480
[ 121.446660] xres 720 yres 576
[ 121.446663] xres 1280 yres 720

So it does look like multiple modes are getting recognized from the fallback EDID but somehow they are filtered out. Can you please help with what is the next step to figure out exactly why?

Best Regards,
Casey

#6

Hey Wayne,

Any feedback here?

Best Regards,
Casey

#8

Hi,

Actually the steps to check this are

First, dump the modes in Xorg and see if modes are there

#Add below option in /etc/X11/xorg.conf, ‘Section “Device”’. Verbose mode logging will be shown in /var/log/Xorg.0.log
Section “Device”
…
Option “ModeDebug”
…
EndSection

Second, if you don’t see mode in (1), then you need to check the mode filter in dp.c.

#10

Hello Wayne,

I finally found the issue and got everything working. I’m posting the solution here for any others which may want to do this. Basically the issue is that there are two checks for EDID performed that can block this from working. The first check is in the edid.c function where I originally told the device to use a fallback EDID which is already an option that just needs to be flipped to “true”. The details of that are in our previous thread.

However there is a second check in the DP.c function which is independent from the one in EDID.c Here is the code segment:

if (dc->edid->errors) {
	return (mode->xres == 640 && mode->yres == 480)
		 ? true : false;
}

Even though the fallback EDID does not have errors, this error flag is getting thrown by the edid.c function because the sink did not return an EDID during the link process (because we have selected fallback = true, it does not even perform this check during the plug event. So all you need to do is comment out this section of code.

After those changes, I am able to get things working with DP as well as HDMI. When a display is plugged into either source, it will use the fallback EDID which is loaded into the top of the edid.c function instead of the EDID from the monitor. It seems to be working well with all the resolutions I have tried so far. So you can force a custom resolution this way based on the EDID which is loaded in the edid.c code.

Best Regards,
Casey

1 Like
#11

I appreciate your update, I’m currently struggling with a similar issue. I’m trying to get a eDP display working that doesn’t currently have an EDID, and the resolution is a little unusual (1200x1920).

The odd thing is trying to start X with ModeDebug on, it looks like it finds an EDID and picks a mode based on it, and I’m almost certain it’s actually the framebuffer parameters (nvidia,fbcon-default-mode) I set in the device tree since the refresh rate changes as I change device tree settings. Unfortunately, X never starts fully, and what I really want is the framebuffer support anyway.

So, would making those changes to dp.c and edid.c likely to affect the framebuffer support? Should I hard code the monitor settings in the kernel rather than the device tree, or do I need both?

Also, should I worry about a portrait mode resolution like 1200x1920 in the nvidia display drivers?

#12

Hi andrew.pease,

Please help to open a new topic if it still an issue. Thanks