Read custom EDID

Hello,
I’ve purchased a 13.3" FHD(1920x1080p) screen display for jetson TX2. I’m able to get it to work with tegra186-quill-p3310-1000-c00-00-auo-10800-edp.dtb. However, the resolution of the display is at a 640x480.
xrandr -q results in DP-0(display) at 640x480. I went ahead and extracted the EDID and parsed it using http://www.edidreader.com/ The EDID is attached below. Clearly, it has missing fields. Is there any way to make the driver read a custom EDID. I’ve been following this thread https://devtalk.nvidia.com/default/topic/1006566/jetson-tx2/how-to-get-monitor-detected-as-1280x800-/1 reply #24 says the only way is to modify the kernel. Is it still the only way? or have there been any updates. If modifying the kernel is the only way what exactly do I have to change to read a custom EDID.

Thanks

00 ff ff ff ff ff ff 00 0d ae 74 13 00 00 00 00
 24 19 01 04 a5 1d 11 78 02 87 85 a4 57 50 9b 27
 0d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
 01 01 01 01 01 01 36 36 80 a0 70 38 20 40 2e 1e
 24 00 25 a5 10 00 00 1a 24 24 80 a0 70 38 20 40
 2e 1e 24 00 25 a5 10 00 00 1a 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02
 00 0c 2b db 11 3c 96 14 0b 1b ab 00 00 00 00 b3

Before you edit any source code see what the driver itself thinks of the modes. Add this to the Section “Device”:

Option    "ModeDebug"

…then reboot and post the “/var/log/Xorg.0.log” with that monitor attached. This should give more information on why 1920x1080 is rejected (rejection may have nothing to do with EDID…a driver has to accept a scan mode before it can be used even if the monitor says it can scan at that rate/setting).

Hi manojbandri,

Sorry for that, I’ve found this is an issue. Update a patch here, hope it could work for you.

From ee88da0efe6fc9c44175f669f61a26d94ea16c0e Mon Sep 17 00:00:00 2001
From: Wayne Wang
Date: Sat, 08 Jul 2017 15:32:26 +0800
Subject: [PATCH] video: tegra: dp: fix eDP fb mode

fb mode is not aligned to dc mode and cause red screen on L4T.
Update fb mode after dp enable.


Change-Id: I0c96e3f81bd6c8e469334f1c957f44d98b91e82c
---

diff --git a/drivers/video/tegra/dc/dp.c b/drivers/video/tegra/dc/dp.c
index 1f80f52..fd18b9e 100644
--- a/drivers/video/tegra/dc/dp.c
+++ b/drivers/video/tegra/dc/dp.c
@@ -3175,6 +3175,18 @@
 		(dc->out->hotplug_state == TEGRA_HPD_STATE_NORMAL))
 		return true;
 
+	if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE)) {
+		if (!tegra_dc_is_ext_panel(dc) &&
+			dc->out->type != TEGRA_DC_OUT_FAKE_DP) {
+			if (dp->hpd_data.mon_spec.modedb_len > 0) {
+				tegra_fb_update_monspecs(dc->fb,
+						&dp->hpd_data.mon_spec, NULL);
+				tegra_fb_update_fix(dc->fb,
+						&dp->hpd_data.mon_spec);
+			}
+		}
+	}
+
 	tegra_dp_pending_hpd(dp);
 
 	return tegra_dc_hpd(dc);

Hi Linuxdev, I’ve attached ‘Xorg.0.log’. FYI the setup right now has a DELL monitor attached to HDMI-0 and another screen attached on J23.

Xorg.0.log (266 KB)

Can you please verify which L4T version you are using? E.g., “head -n 1 /etc/nv_tegra_release”.

Looks like the Dell is listed as DFP-1. I’ll work on the assumption that the other monitor (DFP-0) is the one in question. Do know that having both monitors connected at the same time may cause behavior you would not see if only the one monitor is connected. The information from ModeDebug should still be valid, but it would be useful to know if the mode select behavior you noted above is with just the non-Dell connected, and if it is connected to the same port.

I am also working on the assumption that you want a 1920x1080 mode.

This is the final list of accepted modes for the non-Dell:

[    11.380] (II) NVIDIA(GPU-0): --- Modes in ModePool for CMN (DFP-0) ---
[    11.380] (II) NVIDIA(GPU-0): "nvidia-auto-select" :  640 x  480 @  60.0 Hz  (from: NVIDIA Predefined)
[    11.380] (II) NVIDIA(GPU-0): "640x480"            :  640 x  480 @  60.0 Hz  (from: NVIDIA Predefined)
[    11.380] (II) NVIDIA(GPU-0): "640x480_60"         :  640 x  480 @  60.0 Hz  (from: NVIDIA Predefined)
[    11.380] (II) NVIDIA(GPU-0): "640x480_60_0"       :  640 x  480 @  60.0 Hz  (from: NVIDIA Predefined)
[    11.380] (II) NVIDIA(GPU-0): --- End of ModePool for CMN (DFP-0): ---

Obviously 1920x1080 isn’t there, so the next step is to see why. There are a large number of modes which are being rejected for this same reason, but specifically for 1920x1080 I see this:

[    11.378] (WW) NVIDIA(GPU-0):   Validating Mode "1920x1080_60":
[    11.378] (WW) NVIDIA(GPU-0):     Mode Source: X Server
[    11.378] (WW) NVIDIA(GPU-0):     1920 x 1080 @ 60 Hz
[    11.378] (WW) NVIDIA(GPU-0):       Pixel Clock      : 138.50 MHz
[    11.378] (WW) NVIDIA(GPU-0):       HRes, HSyncStart : 1920, 1968
[    11.378] (WW) NVIDIA(GPU-0):       HSyncEnd, HTotal : 2000, 2080
[    11.378] (WW) NVIDIA(GPU-0):       VRes, VSyncStart : 1080, 1083
[    11.378] (WW) NVIDIA(GPU-0):       VSyncEnd, VTotal : 1088, 1111
[    11.378] (WW) NVIDIA(GPU-0):    [b]   H/V Polarity     : +/-
[    11.378] (WW) NVIDIA(GPU-0):     Mode is rejected: Only modes from the NVIDIA X driver's
[    11.378] (WW) NVIDIA(GPU-0):     predefined list and modes from the EDID are allowed
[    11.378] (WW) NVIDIA(GPU-0):     Mode "1920x1080_60" is invalid[/b].
...
[    11.379] (WW) NVIDIA(GPU-0):   Validating Mode "1920x1200_60":
[    11.379] (WW) NVIDIA(GPU-0):     Mode Source: X Server
[    11.379] (WW) NVIDIA(GPU-0):     1920 x 1200 @ 60 Hz
[    11.379] (WW) NVIDIA(GPU-0):       Pixel Clock      : 154.00 MHz
[    11.379] (WW) NVIDIA(GPU-0):       HRes, HSyncStart : 1920, 1968
[    11.379] (WW) NVIDIA(GPU-0):       HSyncEnd, HTotal : 2000, 2080
[    11.379] (WW) NVIDIA(GPU-0):       VRes, VSyncStart : 1200, 1203
[    11.379] (WW) NVIDIA(GPU-0):       VSyncEnd, VTotal : 1209, 1235
[    11.379] (WW) NVIDIA(GPU-0):       H/V Polarity     : +/-
[    11.379] (WW) NVIDIA(GPU-0):     [b]Mode is rejected: Only modes from the NVIDIA X driver's
[    11.379] (WW) NVIDIA(GPU-0):     predefined list and modes from the EDID are allowed
[    11.379] (WW) NVIDIA(GPU-0):     Mode "1920x1200_60" is invalid.[/b]

Simply put, the driver doesn’t like your 1920x1080@60 modes. I know 1920x1080@60 is itself well accepted most of the time, so there is a high probability that the pixel clock is an issue.

Can someone from NVIDIA suggest if modifying the mode tables in the kernel source would allow this, or if the modes are simply out of the safe range for the required pixel clocks? Long ago I remember a case where the pixel clock was basically in range, but due to floating point conversion ended up being rejected.

Hi Linuxdev,

yep, you are right with both your assumptions. Here is the log with only the screen attached.

L4T Version:

# R28 (release), REVISION: 1.0, GCID: 9379712, BOARD: t186ref, EABI: aarch64, DATE: Thu Jul 20 07:59:31 UTC 2017

Xorg.0.log (125 KB)

Hi Wayne, I tried the patch you suggested. Doesn’t seem to change the resolution on the screen. It still displays a 640x480 ubuntu desktop. @Linuxdev mentioned was suggesting that it might be a pixel clock issue, how do I go about that?

-Thanks.

Hi manojbandri

Please print out the following value. That patch was used for mistmatch mode between fb0 and tegradc. I believe this issue is still there in rel-28.1.

sudo -s
cat /sys/kernel/debug/tegradc.0/mode
cat /sys/class/graphics/fb0
export DISPLAY=:0
xrandr

Hi Wayne, here is the output of cat /sys/kernel/debug/tegradc.0/mode

pclk: 138792000
h_ref_to_sync: 1
v_ref_to_sync: 1
h_sync_width: 30
v_sync_width: 4
h_back_porch: 84
v_back_porch: 26
h_active: 1920
v_active: 1080
h_front_porch: 46
v_front_porch: 2
flags: 0x1
stereo_mode: 0
avi_m: 0x2
vmode: 0x10200000

the output of cat /sys/class/graphics/fb0/mode

U:640x480p-60

the result of xrandr after exporting display:

Invalid MIT-MAGIC COOKIE-1 KeyCan't open display :0

For xrandr to work the GUI must be logged in to, and the user doing the export+xrandr has to be the same user as is logged in.

Hi Wayne and Linuxdev,

I had to replace “tegra_dc_is_ext_panel” with “tegra_dc_is_ext_dp_panel” in the patch and it worked. I now get a full-screen display.

Thank you for your support.

Hi manojbandri,

Sorry that my patch looks out of date.