Monitor EDID problems for 1024x600 on AGX Xavier

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Xavier
1

Dear all, I have a 7 inch display with a resolution of 1024x600, which I want to connect to my AGX Xavier’s HDMI. For reference, this screen is a waveshare display with capacitive touch. I have tried really hard to get the display to work at its native resolution and without artifacts, without success so far. 1024x600, also widely used in now-deceased netbooks, is neither a common resolution nor a common aspect ratio, which may explain the issue. However, for 7-and 10-inch screens used in embedded applications, I guess it may be somewhat widespread. On windows 10, I can get the display to work at its native resolution. Please note that I flashed the jetson yesterday, so it is up to date.

Here is what I tried:

  • Ubuntu GUI display properties : the GUI ubuntu display properties don’t allow me to set the native resolution.
  • xrandr : does not list 1024x600 as supported, and adding a new mode using a gcf-generated modeline fails with a “bad match” error.
  • xorg.conf : adding configuration data is not supported according to https://elinux.org/Jetson_TX2/r28_Display_debug

I was able to grab the screen’s EDID data in /sys/kernel/debug/tegradc.0/edid (attached with a .txt extension to this post, but remember it is a binary file). Opening this EDID in AW EDID editor shows that also no standard mode (such as VGA, WXGA, …) is supported, the EDID contains a “preferred timing block” as additional data, which seems valid to me. I remember seeing that on jetson startup, tegradc complains abount “invalid EDID”, but a “dmesg | grep tegradc” does not show such an error message.

My question is, does anyone here have a solution to this issue, or is it a tegra driver bug?

Regards, FMdC

attached EDID (this is a binary file)
ada7_edid_bin.txt (256 Bytes)

2

The driver does not support modes via xorg.conf. Only EDID modes are accepted, and the list of modes available is smaller than that a typical desktop GPU would support. To get an idea of what the driver thinks about specific modes from EDID you’ll want to enable verbose mode debugging. In the “/etc/X11/xorg.conf” there will be a Section "Device". Within this turn on mode debugging by adding:
Option "ModeDebug"

Reboot once, and post the /var/log/Xorg.0.log (assumes DISPLAY “:0:”).

3

I added the debud option. I got two logs, for display 0 and display 1, even though I only ever had one display connected (that could be an issue?). Please see both logs atttached.

Also, I noted something weird. Usually, the monitor is set to an unsupported “1280x720” resolution (it is right now after the reboot with the debug option, so part of the desktop is missing). But I got it once to 1024x600 automatically and I can’t reproduce it. Maybe this has to do with me pluggin in an out the monitor during different phases of the boot process or after (such as on the logging screen).

EDIT : got it to 1024 x 600 by disconnecting and reconnecting HDMI while on the desktop.

Xorg.0.log (413.7 KB)
Xorg.1.log (217.5 KB)

4

For Xorg.0.log I see some valid modes which the driver accepts. Lines such as this:
[ 13.525] (II) NVIDIA(GPU-0): Mode "1280x720_60" is valid.

So not only does EDID work, the driver accepts some of the modes. The final mode pool is this, and all of these modes should work:

[    13.925] (II) NVIDIA(GPU-0): --- Modes in ModePool for NVIDIA (DFP-0) ---
[    13.925] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 1280 x  720 @  60.0 Hz  (from: EDID, CEA, Detailed)
[    13.925] (II) NVIDIA(GPU-0): "1280x720"           : 1280 x  720 @  60.0 Hz  (from: EDID, CEA, Detailed)
[    13.925] (II) NVIDIA(GPU-0): "1280x720_60"        : 1280 x  720 @  60.0 Hz  (from: EDID, CEA, Detailed)
[    13.926] (II) NVIDIA(GPU-0): "1280x720_60_0"      : 1280 x  720 @  60.0 Hz  (from: EDID, CEA)
[    13.926] (II) NVIDIA(GPU-0): "1280x720_60_1"      : 1280 x  720 @  59.9 Hz  (from: EDID, CEA)
[    13.926] (II) NVIDIA(GPU-0): "1280x720_50"        : 1280 x  720 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    13.926] (II) NVIDIA(GPU-0): "1280x720_50_0"      : 1280 x  720 @  50.0 Hz  (from: EDID, CEA)
[    13.926] (II) NVIDIA(GPU-0): "720x576"            :  720 x  576 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    13.926] (II) NVIDIA(GPU-0): "720x576_50"         :  720 x  576 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    13.926] (II) NVIDIA(GPU-0): "720x576_50_0"       :  720 x  576 @  50.0 Hz  (from: EDID, CEA)
[    13.926] (II) NVIDIA(GPU-0): "720x480"            :  720 x  480 @  59.9 Hz  (from: EDID, CEA, Detailed)
[    13.926] (II) NVIDIA(GPU-0): "720x480_60"         :  720 x  480 @  59.9 Hz  (from: EDID, CEA, Detailed)
[    13.926] (II) NVIDIA(GPU-0): "720x480_60_0"       :  720 x  480 @  59.9 Hz  (from: EDID, CEA)
[    13.926] (II) NVIDIA(GPU-0): "640x480"            :  640 x  480 @  59.9 Hz  (from: EDID)
[    13.926] (II) NVIDIA(GPU-0): "640x480_60"         :  640 x  480 @  59.9 Hz  (from: EDID)
[    13.926] (II) NVIDIA(GPU-0): --- End of ModePool for NVIDIA (DFP-0): ---

There are also some metamodes.

I also see some input devices have been set up.

I see some later mode information after the mode pool was complete, which makes me wonder if there was a disconnect and reconnect, but there are still modes in the mode pool at the end. The interesting part at the end of the Xorg.0.log:

[    16.845] (--) NVIDIA(GPU-0): ADA (DFP-0): connected
[    16.845] (--) NVIDIA(GPU-0): ADA (DFP-0): External TMDS
[    16.845] (--) NVIDIA(GPU-0): ADA (DFP-0) Name Aliases:
[    16.845] (--) NVIDIA(GPU-0):   DFP
[    16.845] (--) NVIDIA(GPU-0):   DFP-0
[    16.845] (--) NVIDIA(GPU-0):   DPY-0
[    16.845] (--) NVIDIA(GPU-0):   HDMI-0
[    16.845] (--) NVIDIA(GPU-0):   DPY-EDID-40e1d303-9979-fb31-b34f-e8704c088759
[    16.845] (--) NVIDIA(GPU-0):   HDMI-0
[    71.378] (**) Option "fd" "35"
[    71.378] (II) event6  - WaveShare WS170120: device removed
[    71.379] (**) Option "fd" "38"
[    71.379] (II) event7  -   mini keyboard: device removed
[    71.380] (**) Option "fd" "39"
[    71.381] (**) Option "fd" "40"
[    71.381] (II) event5  - gpio-keys: device removed
[    71.382] (**) Option "fd" "41"
[    71.382] (II) event4  - tegra-snd-t19x-mobile-rt565x Headset Jack: device removed
[    71.384] (**) Option "fd" "39"
[    71.384] (II) event8  -   mini keyboard: device removed
[    71.481] (II) systemd-logind: got pause for 13:70
[    71.484] (II) systemd-logind: got pause for 13:71
[    71.485] (II) systemd-logind: got pause for 13:69
[    71.485] (II) systemd-logind: got pause for 13:72
[    71.485] (II) systemd-logind: got pause for 13:68

I don’t know what the cause of disconnect is, but perhaps USB was put in a low power/sleep mode. Then systemd-logind got large pauses…again, I don’t know if this is from screen save or sleep type activity. I cannot be specific, but it is common for devices going into some sort of sleep mode to not correctly wake up.

On the other hand, nowhere do I see “1024x600”. This mode is neither accepted nor rejected, and thus by default is rejected. Are you sure this monitor is capable of native 1024x600?

A typical desktop PC can do some editing to make modes appear to be part of the monitor, but in reality the monitor might be clipping a few pixels. I don’t think this will work with the embedded video driver, and only modes specifically available will work.

5

The USB disconnection/reconnection you mention may be the key here : this monitor is powered by usb. I can guarantee that this is a native 1024x600 screen (from manufacturer documentation, from the fact that on windows it only displays correctly at this resolution and from the EDID which lists 1024x600@60Hz as the only supported mode when viewed with an EDID editor).
This monitor seems to lack an internal scaler, so anything else than 1024x600 causes a lot of artifacts (for lower resolutions) and elements out of the screen surface (for larger resolutions).

I can guarantee that none of the modes listed in the log is actually supported by the monitor (from the actual EDID and from viewing what’s displayed on screen with these modes), so the
“is_valid” flag may only come from the EDID being read wrong, or there being no EDID at all at that point (so, some “default EDID” might be used).

My current take on the subject (after experimenting) is that during the boot process, there are instabilities in the usb connection (maybe power is cut off at some point?), which causes EDID reading to fail. However, if I disconnect and reconnect the monitor after boot, the EDID is read correctly and the right resolution is set. I will try to connect the monitor to an external usb power source to support this theory.
Regards, FMdC

6

This could account for the monitor suddenly disappearing, but would be unrelated to the missing 1024x600@60Hz mode. The mode support on Jetsons is restricted in comparison to desktop PCs, and unless the following hold, the mode will not be supported:

  • Mode is not interlaced.
  • Mode is provided by EDID.
  • Mode is not an extension mode.
  • The EDID mode is within the supported performance range of the driver/GPU.

From what I can see there is no ability to work with 1024x600 in any way. There may be cases where the monitor claims to support a mode which is actually slightly off from the specification, e.g., it may clip a line of pixels or may put black space in for a row of pixels. If xrandr reports this mode is 1024x600@60Hz, then I would be very very surprised since EDID did not include this.

However, I had looked at the Xorg.0.log. I don’t see this in Xorg.1.log either though, so it is the same issue. For reference, here is the Xorg.1.log accepted mode pool:

[    72.063] (II) NVIDIA(GPU-0): --- Modes in ModePool for ADA (DFP-0) ---
[    72.063] (II) NVIDIA(GPU-0): "nvidia-auto-select" : 1280 x  720 @  60.0 Hz  (from: EDID, CEA, Detailed)
[    72.063] (II) NVIDIA(GPU-0): "1280x720"           : 1280 x  720 @  60.0 Hz  (from: EDID, CEA, Detailed)
[    72.063] (II) NVIDIA(GPU-0): "1280x720_60"        : 1280 x  720 @  60.0 Hz  (from: EDID, CEA, Detailed)
[    72.064] (II) NVIDIA(GPU-0): "1280x720_60_0"      : 1280 x  720 @  60.0 Hz  (from: EDID, CEA)
[    72.064] (II) NVIDIA(GPU-0): "1280x720_60_1"      : 1280 x  720 @  59.9 Hz  (from: EDID, CEA)
[    72.064] (II) NVIDIA(GPU-0): "1280x720_50"        : 1280 x  720 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    72.064] (II) NVIDIA(GPU-0): "1280x720_50_0"      : 1280 x  720 @  50.0 Hz  (from: EDID, CEA)
[    72.064] (II) NVIDIA(GPU-0): "720x576"            :  720 x  576 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    72.065] (II) NVIDIA(GPU-0): "720x576_50"         :  720 x  576 @  50.0 Hz  (from: EDID, CEA, Detailed)
[    72.065] (II) NVIDIA(GPU-0): "720x576_50_0"       :  720 x  576 @  50.0 Hz  (from: EDID, CEA)
[    72.065] (II) NVIDIA(GPU-0): "720x480"            :  720 x  480 @  59.9 Hz  (from: EDID, CEA, Detailed)
[    72.065] (II) NVIDIA(GPU-0): "720x480_60"         :  720 x  480 @  59.9 Hz  (from: EDID, CEA, Detailed)
[    72.065] (II) NVIDIA(GPU-0): "720x480_60_0"       :  720 x  480 @  59.9 Hz  (from: EDID, CEA)
[    72.066] (II) NVIDIA(GPU-0): "640x480"            :  640 x  480 @  59.9 Hz  (from: EDID)
[    72.066] (II) NVIDIA(GPU-0): "640x480_60"         :  640 x  480 @  59.9 Hz  (from: EDID)
[    72.066] (II) NVIDIA(GPU-0): --- End of ModePool for ADA (DFP-0): ---

If the monitor does have working modes, but USB goes into a low power mode, then even those modes which work might have issues with waking back up. I don’t know much about USB-C monitors, and the NVIDIA driver may have restrictions…I’ve only looked at EDID via the HDMI connector. Someone else may want to add comments on what is expected with USB-C monitors.

7

I am sorry, my description was not clear enough. This is an HDMI monitor, with a USB connection (type A for that matters) for power and touch support.

I did two experiments yesterday :

  1. having the usb of the monitor plugged into my laptop while the HDMI was plugged into the jetson. The monitor displayed perfectly at its native 1024x600 resolution on the jetson. On the ubuntu display configuration screen, only 1024x600 was shown as supported, which was the expected behaviour from the EDID.
  2. connecting both USB and HDMI to the jetson, and disconnecting and reconnecting (by unplugging and plugging again) HDMI at the ubuntu logging screen. Again, perfect 1024x600 resolution, no issues, and Ubuntu display tab shows only 1024x600 supported.

To me, this confirms that EDID reading fails when done during the boot process for whatever reason (maybe usb power).

8

Yes, it is possible for a later hot plug to correctly read EDID, but fail at certain earlier moments in boot. What we need to find out is if EDID was correctly read in the case where the monitor is connected at the start, but fails to display. After boot is done, when the monitor is failed, and when the connector has not been reconnected (we want the failure condition), do you see EDID from this?

sudo -s
egrep -H '.*' `find /sys -name edid`
exit

If i2c is powered on the Jetson, then EDID should be queried. Failing to display with available EDID would be a different issue than failing to display without EDID. If hot plug is needed (unplug and replug) in order to get a functioning EDID query, then boot logs will probably provide info about the moment of failure.

If the EDID does not contain 1024x600, or if the Xorg log indicates the mode was rejected, then later hot plug working is simply a case of a default being triggered, and the monitor being able to work with the default (a case of good luck rather than design). Checking actual EDID without a hot plug will probably tell us which case this is.

9

At boot, there is a message that says something like : tegradc 15200000.nvdisplay : hdmi : failed to read EDID.

When running your command without reconnecting on login screen (so, the image looks weird and its somewhat hard to see what’s going on), I get for tegradc0 8 lines of 16 bytes, which correspond to the first half of the EDID seen on windows (the rest on windows is just 0s).
When reconnecting HDMI at logging screen and then running your command, I get the same result. So the EDID is definitely there even when the resolution is wrong.

I think the process is that on boot, when EDID read fails, the driver considers default modes (640x480, 1280x720, …) as valid even though they are not. It sets one of these modes. Then, usb is powered off/on and the EDID is read again (successfully this time), but the mode set by the driver is not updated.

Then, when unplugging/replugging at login screen, the driver realizes that it should update its mode. It realizes that not only thes standard modes are not supported, but 1024x600 is, and sets the resolution correctly this time.

I think that the 1024x600 is no good luck, because AFAIK the driver has no way of figuring out this non-standard resolution other than the EDID. Also, remember that it then refuses to set anything else than 1024x600, and especially none of the standard resolutions.

10

I would avoid using EDID from Windows simply because I do not know what edits Windows might perform, although it is useful to know an EDID is seen on a different system. Very likely NULL bytes are just filling in unused space for a fixed size buffer, but I couldn’t say for sure. In a case where EDID read fails on the Xavier this will prevent correct video display, but each specific EDID is considered present only if the checksum is correct.

There is more than one display controller, one for the HDMI, and another for the eDP, and possibly a third. Regarding this boot error:

…0x15200000 is the base address of that controller. This is likely the HDMI port controller since it is trying to read EDID (and says “hdmi”). Can you provide a serial console boot log? This would provide the information around that i2c failure, and this probably is the reason why configuration fails on initial boot.

Incidentally, a truncated EDID should be ignored since the checksum would fail, but I’ve never seen the internals of the driver and so I couldn’t say for sure. A corrupt/truncated EDID should be treated the same as no EDID (a record of the EDID might still be present regardless of being corrupt or not, but the driver should not attempt to use an EDID with a bad checksum).

One possible reason for a failed EDID is lack of power to the i2c bus. The error is not necessarily specific to the data path, and thus more reason to see the full serial console boot log.

11

I grabbed the systemd boot log using journalctl -b
bootlog.txt (289.0 KB)
I am not sure whether this qualifies as “serial console boot log” though.

12

For serial console, you may have a look to this post.
Use gtk-term on host. Once Xavier has booted you should be able to copy all messages into a text file.

13

This does indicate failed EDID (the protocol used is i2c, address 0x50 on that particular i2c controller):

juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
juin 12 09:45:37 jetson1 kernel: tegradc 15200000.nvdisplay: hdmi: edid read failed
juin 12 09:45:37 jetson1 kernel: tegradc 15200000.nvdisplay: hdmi: using fallback edid
juin 12 09:45:37 jetson1 kernel: tegradc 15200000.nvdisplay: blank - powerdown

Note that there may be default values, but unless EDID was present at the time of trying to use EDID, then failure would be expected unless you get lucky with a default.

Check the post from @Honey_Patouceul for serial console information, as there may be indications prior to the Linux kernel loading as to why i2c failed, e.g., perhaps failure to set up a particular power rail. Regardless, we know EDID is failing, but what we don’t know know is why. Someone else may know i2c setup better and be able to comment on why EDID is failing, but they’ll need the boot logs. “dmesg” works well if you don’t care about what went on to set up the environment prior to the Linux kernel taking over, but in this case it would be nice to see what was going on earlier in boot.

14

I am connected to the serial console (from putty on windows, because on linux I don’t see ttyUSB devices). However, I don’t see any debug messages from the boot process. What I see resembles what I get when logging using SSH (including a list of packets that can be updated).
Do I have to enable debugging somewhere to see these messages? (Note : I removed the “ModeDebug” from xorg.conf, but this should not change anything).

15

If you are in Linux and monitor “dmesg --follow”, then what do you see as you connect the micro-B USB cable of the Xavier to the host PC? It should mention some FTDI serial devices attaching to some ttyUSB# files.

Btw, the number of the ttyUSB# may depend on whether other similar devices are connected. This can offset or shift the expected number. Basically I see four devices from the above, and if you had no other USB serial UARTs, then they would be “/dev/ttyUSB0” through “/dev/ttyUSB3”, and it would be the “/dev/ttyUSB3” which is used for serial console. In dmesg the correct device is the last of the four ttyUSB#.

You might try gtkterm (“sudo apt-get install gtkterm”) from Linux. If dmesg shows the last of the four devices is “/dev/ttyUSB3”, then:
sudo gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB3

Note the “sudo” is only needed if your user is not a member of whichever group is assigned to ttyUSB3. You can see which group this file is from “ls -l /dev/ttyUSB3”. You can experiment with what works while running normally, and leave the serial console running as you shut down. Use the menu to “clear screen”, then enable logging, followed by powering up the Jetson to get the log.

You are correct that “ModeDebug” shouldn’t change anything, but it is also harmless to leave it in during testing.

16

After a lot of “how does it not work?”, I ended up with a simple solution : I was not using the right USB port to get the serial console (was using the usb-C port and not tue micro-b one). Guess I should have read @Honey_Patoucel’s post more carefully (only looked at the picture and did not realize there where two usb ports on this side of the jetson). Here comes the log:serial_log.txt (27.5 KB)

17

I see this in the logs, which is good:

[0002.171] I> enabling 'vdd-hdmi-5v0' regulator
[0002.176] I> regulator 'vdd-hdmi-5v0' already enabled
[0002.176] I> hdmi cable connected

Later on in logs I see this, which is bad:

[    1.963484] tegradc 15200000.nvdisplay: hdmi: edid read failed

We know the system has detected the HDMI cable, and yet EDID fails. The i2c controller at 0x31c0000 tried to query EDID, and failed. Power for this EDID is from the Xavier, but arrives on your monitor via the HDMI cable. If the cable has an issue, then EDID would fail. If the monitor itself has an i2c query quirck, then you would also fail the EDID read even if HDMI provides power to i2c. I simply don’t know what to check to determine where the fault is.

About all I can suggest is to try another monitor which is more “average” and something typical of a 1920x1080 desktop. If this works, then there is probably something specific to the other monitor which someone from NVIDIA can help figure out; if that other monitor does not work, then it may be a hardware failure of the Jetson or the cable (or it could be a device tree error preventing the Jetson hardware from doing its job).

18

Here are some reflections on your analysis:

Power for this EDID is from the Xavier, but arrives on your monitor via the HDMI cable

but this monitor may need an external source of power to get that working. That is, there could be something funny with its i2c controller that requires an external source of power, which happens to be usb for this monitor. The reason I am 98% convinced that that’s the issue is that whenever I plug the monitor’s usb cable into something else than the jetson, the jetson reads the EDID fine during boot and displays correctly.

try another monitor which is more “average” and something typical of a 1920x1080 desktop

did that. Works great on my 27 inch 1920x1080 monitor.

it may be a hardware failure of the Jetson or the cable (or it could be a device tree error preventing the Jetson hardware from doing its job)

Definitely. The cable is OK, though (top quality braided cable for harsh environments, I tested it in multiple situations), so the problem comes from one of its ends.

I am going to let this thread open for a few weeks, in case someone comes by with a solution, but I think I already know the (suboptimal) solution, which is to get another monitor that is not powered through usb. Thank you for the time spent investigating.

19

The i2c circuits inside of a monitor are not powered by the monitor; those are powered by the HDMI cable. Unless you have something non-standard, a monitor which is not powered will still show up since the monitor power is not needed for this i2c. It isn’t unlike USB where the device is normally powered by the host (though there are some which are not when power requirements have some custom requirement…perhaps power to the DDC is not passed through for your case since it is an unusual monitor). Normally only the main monitor power is from the monitor. It is easy enough to test though, see if EDID succeeds when the monitor is powered up prior to the Jetson. If this does not make a difference, then the monitor is “standard” and not custom in terms of the i2c power.

Note that some power rails for i2c internal to the Jetson also power the DDC (EDID) of the monitor.

The above says the hardware is functioning as expected. I suspect the lack of initial EDID on the other monitor is unrelated to the Jetson’s i2c query. Note that if another monitor works, then it implies there is no device tree issue since the other monitor uses power from the HDMI cable as well (for the EDID query). Cables can be an issue from bad signal, but it is likely power is being provided (unless the monitor has a custom/non-standard power solution to the monitor’s i2c/DDC/EDID). Often if there is a signal issue, then the checksum will fail, but the EDID won’t be completely missing.

The actual USB power is probably only for the non-i2c/non-EDID/non-DDC part of the monitor. You can try powering this before you start the Jetson and see if the EDID query failure goes away, but I suspect the issue has nothing to do with the USB power for the main part of the monitor (and touchscreen).

20

Hi,

Sorry for late reply. Actually this display framework is simple. When some modes not listed in xrandr, there are two possibilities.

  1. The kernel driver filters it out because it does mot pass the mode check calculation.

  2. The userspace xorg driver filters it out.

If your xorg.0.log does not list this mode after your add “ModeDebug” in xorg.conf, it means the first case happens.

Xorg driver only receives anything from kernel and do its work. If xorg log does not have it, then this mode must be deleted in kernel.