HDMI issue - question for WayneWWW...

Well, I spoke too soon - unfortunaltely, the issue is back … and needs to be resolved. I doubt it’s a hardware, but I will swap TX2 module back to DevKit board and will update.

-albertr

get-edid doesn’t work, even when it’s executed with X11 showing HDMI output on the monitor.

root@tx2:~# get-edid | parse-edid
This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
No EDID on bus 8
1 potential busses found: 7
Bus 7 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Partial Read... Try again
root@tx2:~#

dmesg --follow shows the following:

[  300.228040] tegra-i2c 3160000.i2c: no acknowledge from address 0x50
[  300.235524] tegra-i2c c240000.i2c: no acknowledge from address 0x50
[  300.242781] tegra-i2c 3180000.i2c: no acknowledge from address 0x50
[  302.246664] tegra-i2c 3190000.i2c: pio xfer timed out addr: 0x50
[  302.252826] tegra-i2c 3190000.i2c: --- register dump for debugging ----
[  302.259621] tegra-i2c 3190000.i2c: I2C_CNFG - 0x22c00
[  302.264769] tegra-i2c 3190000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[  302.271578] tegra-i2c 3190000.i2c: I2C_FIFO_CONTROL - 0xe0
[  302.277177] tegra-i2c 3190000.i2c: I2C_FIFO_STATUS - 0x800040
[  302.283029] tegra-i2c 3190000.i2c: I2C_INT_MASK - 0x7d
[  302.288244] tegra-i2c 3190000.i2c: I2C_INT_STATUS - 0x0
[  302.293517] tegra-i2c 3190000.i2c: i2c transfer timed out addr: 0x50
[  302.351081] i2c i2c-4: tegra_bpmp_i2c_req ret -5
[  302.355820] i2c i2c-4: --- message dump for debugging ---
[  302.361464] i2c i2c-4: addr 0x50 flags 0x0 len 1 data:
[  302.366718] i2c i2c-4:  00
[  302.369542] i2c i2c-4: 
[  302.372095] i2c i2c-4: addr 0x50 flags 0x1 len 1 data:
[  302.377310] i2c i2c-4:  e0
[  302.380157] i2c i2c-4: 
[  304.382674] tegra-i2c 31b0000.i2c: pio xfer timed out addr: 0x50
[  304.388731] tegra-i2c 31b0000.i2c: --- register dump for debugging ----
[  304.395509] tegra-i2c 31b0000.i2c: I2C_CNFG - 0x22c00
[  304.400742] tegra-i2c 31b0000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[  304.407464] tegra-i2c 31b0000.i2c: I2C_FIFO_CONTROL - 0xe0
[  304.413002] tegra-i2c 31b0000.i2c: I2C_FIFO_STATUS - 0x800040
[  304.418908] tegra-i2c 31b0000.i2c: I2C_INT_MASK - 0x7d
[  304.424119] tegra-i2c 31b0000.i2c: I2C_INT_STATUS - 0x0
[  304.429398] tegra-i2c 31b0000.i2c: i2c transfer timed out addr: 0x50
[  304.437152] tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
[  304.444761] tegra-i2c 31e0000.i2c: no acknowledge from address 0x50

-albertr

Here’s my current video mode from fb0 device:

root@tx2:~# cat /sys/class/graphics/fb0/mode
U:1920x1080p-59
root@tx2:~# 

root@tx2:~# cat /sys/class/graphics/fb0/modes
D:1920x1080p-59
V:640x480p-60
V:800x600p-60
V:1024x768p-60
U:1152x864p-60
S:1280x800p-60
S:1280x1024p-60
S:1280x720p-60
S:1440x900p-60
S:1680x1050p-60
S:1920x1080p-60
D:720x576p-50
D:1920x1080i-60
D:1920x1080i-50
D:1280x720p-50
D:1920x1080p-59
U:1920x1080p-60
U:720x480p-59
U:1920x1080i-50
U:1920x1080i-60
U:1280x720p-50
U:1280x720p-60
U:720x576p-50
U:1920x1080p-60
U:1280x720p-60

-albertr

It’s interesting to know my monitor works on a TX2 under L4T R28.1, but “get-edid” also returns with an i2c failure in dmesg…despite EDID also working. Perhaps the i2c used for get-edid (and something else) is reading the wrong i2c? One thought: Perhaps this is just a side effect of i2c scanning which is showing up and the error is unrelated…but if this is the case, then why does get-edid not find an EDID on at least one address?

[  238.446474] tegra-i2c 3160000.i2c: no acknowledge from address 0x50
[  238.454388] tegra-i2c c240000.i2c: no acknowledge from address 0x50
[  238.462917] tegra-i2c 3180000.i2c: no acknowledge from address 0x50
[  240.472532] tegra-i2c 3190000.i2c: pio xfer timed out addr: 0x50
[  240.478689] tegra-i2c 3190000.i2c: --- register dump for debugging ----
[  240.485448] tegra-i2c 3190000.i2c: I2C_CNFG - 0x22c00
[  240.490643] tegra-i2c 3190000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[  240.497496] tegra-i2c 3190000.i2c: I2C_FIFO_CONTROL - 0xe0
[  240.503119] tegra-i2c 3190000.i2c: I2C_FIFO_STATUS - 0x800040
[  240.508999] tegra-i2c 3190000.i2c: I2C_INT_MASK - 0x7d
[  240.514276] tegra-i2c 3190000.i2c: I2C_INT_STATUS - 0x0
[  240.519604] tegra-i2c 3190000.i2c: i2c transfer timed out addr: 0x50
[  240.577390] i2c i2c-4: tegra_bpmp_i2c_req ret -5
[  240.582096] i2c i2c-4: --- message dump for debugging ---
[  240.587618] i2c i2c-4: addr 0x50 flags 0x0 len 1 data:
[  240.592977] i2c i2c-4:  00
[  240.595741] i2c i2c-4: 
[  240.598311] i2c i2c-4: addr 0x50 flags 0x1 len 1 data:
[  240.603562] i2c i2c-4:  a0
[  240.606370] i2c i2c-4: 
[  242.608461] tegra-i2c 31b0000.i2c: pio xfer timed out addr: 0x50
[  242.614598] tegra-i2c 31b0000.i2c: --- register dump for debugging ----
[  242.621513] tegra-i2c 31b0000.i2c: I2C_CNFG - 0x22c00
[  242.626728] tegra-i2c 31b0000.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[  242.633451] tegra-i2c 31b0000.i2c: I2C_FIFO_CONTROL - 0xe0
[  242.639074] tegra-i2c 31b0000.i2c: I2C_FIFO_STATUS - 0x800040
[  242.644922] tegra-i2c 31b0000.i2c: I2C_INT_MASK - 0x7d
[  242.650189] tegra-i2c 31b0000.i2c: I2C_INT_STATUS - 0x0
[  242.655480] tegra-i2c 31b0000.i2c: i2c transfer timed out addr: 0x50
[  242.662866] tegra-i2c 31c0000.i2c: no acknowledge from address 0x50
[  242.670283] tegra-i2c 31e0000.i2c: no acknowledge from address 0x50

In my case going to/from console (CTRL-ALT-F1 or ALT-F7) works. During transitions I do not get any i2c error. The get-edid is how I trigger i2c error messages in dmesg. I do not have any patches applied.

I’m not quite sure I ever understand why Nvidia decided to be so strict with EDID compliance… generally speaking, Jetson is not an average consumer product. I would rather prefer having something like Raspberry Pi folks did with hardcoding preferred HDMI mode to config.txt file on a boot partition.

Anyways, I’m planning more tests tonight when I get back home and get my hands on it.

-albertr

The I2C kernel error seems indeed related to get-edid.
I’ve seen it with R24.2.1 on TX1 with a monitor having EDID not properly handled ([url]Black consoles on L4T 64 bits R24 rev 2.1 - Jetson TX1 - NVIDIA Developer Forums) and I still can see it on my TX2 R28.2-DP with a monitor working fine.

I don’t think there is anything “strict” regarding EDID compliance per se. In the case of an i2c failure i2c just happens to be the kind of pipe for sending EDID. It does lead me to wonder (in R28.1) about i2c3 (i2c@3190000) and if this is truly the DDC wire…if it is, then I’d wonder why i2c sometimes fails and sometimes works…if perhaps there is software incorrectly using i2c (or at least using it when it isn’t set up).

Well, under “strict” I meant the nvidia video drivers. They seem to be very touchy about video mode selection and EDID processing… I think that get-edid failures and accompanying i2c error messages might be unrelated, at least I don’t see any i2c errors in kernel log when X11 fails to switch video mode.

[  2873.082] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select"
[  2873.119] (EE) NVIDIA(0): Failed to set the display configuration.
[  2873.144] (II) NVIDIA(0): Setting mode "NULL"

-albertr

I think one of the issues in the past has been one of floating point rounding, which in turn was not actually being strict in the usual sense. Clocks involved actually run at a lower frequency, and the higher frequencies are obtained with a multiplier…and multipliers by nature are some integer value…you can’t hit certain frequencies even if the output range covers that frequency should there be a need for floating point and not an integer multiple. For a monitor with a timing which looks “normal” need some clock the multiplier can’t hit, then the mode would be rejected. I don’t know if this is the case for one of your modes, but having the monitor work in a mode, then switching back and forth to/from console/X11 breaking for a mode is a different issue…it isn’t the driver rejecting a mode, it is a mode not being triggered.

If you want a truly detailed list of what the driver thinks of all EDID modes add this to the Section “Device”, then look at “/var/log/Xorg.0.log”:

Option    "ModeDebug"

With that option in place the driver itself will comment about what it thinks of every single EDID mode. You won’t have to guess.

linuxdev, thanks. I added Option “ModeDebug”, please see attached Xorg.0.log.

I’m puzzled why it’s setting mode to “NULL”, looking at the Xorg.0.log file I can see plenty of supported video modes and unless I’m missing something there’s no obvious errors. Do you have any ideas?

Ado, there’s no errors logged by the kernel either, here’s dmesg:

[ 2769.331011] PD DISP1 index3 UP
[ 2769.334323] PD DISP2 index4 UP
[ 2769.337911] PD DISP2 index4 DOWN
[ 2769.341463] hid-generic 0003:046D:C52F.000C: input,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-3530000.xhci-2.4/input1
[ 2769.353808] PD DISP1 index3 DOWN
[ 2769.357236] PD DISP0 index2 DOWN
[ 2769.374652] PD DISP0 index2 UP
[ 2769.379438] PD DISP1 index3 UP
[ 2769.383531] PD DISP2 index4 UP
[ 2769.387052] PD DISP2 index4 DOWN
[ 2769.390652] PD DISP1 index3 DOWN
[ 2769.394013] PD DISP0 index2 DOWN
[ 2769.412997] tegradc 15210000.nvdisplay: hdmi: plugged
[ 2782.316666] PD DISP0 index2 UP
[ 2782.317830] PD DISP1 index3 UP
[ 2782.317954] PD DISP2 index4 UP
[ 2782.320524] Parent Clock set for DC plld2
[ 2782.324019] tegradc 15210000.nvdisplay: hdmi: pclk:138652K, set prod-setting:prod_c_150M
[ 2801.351042] PD DISP2 index4 DOWN
[ 2801.351216] PD DISP1 index3 DOWN
[ 2801.351297] PD DISP0 index2 DOWN
[ 2812.031031] PD DISP0 index2 UP
[ 2812.032344] PD DISP1 index3 UP
[ 2812.032464] PD DISP2 index4 UP
[ 2812.034755] Parent Clock set for DC plld2
[ 2812.038050] tegradc 15210000.nvdisplay: hdmi: pclk:138652K, set prod-setting:prod_c_150M

-albertr
Xorg.0.log.gz (33 KB)

I see X11 have your EDID. What test case is for the latest Xorg log? Is it a working one(non-hotplug)?

[    22.323] (II) NVIDIA(GPU-0):   Validating Mode "1920x1080_60":
[    22.323] (II) NVIDIA(GPU-0):     Mode Sources: NVIDIA Predefined, EDID, Detailed
[    22.323] (II) NVIDIA(GPU-0):     1920 x 1080 @ 60 Hz
[    22.323] (II) NVIDIA(GPU-0):       Pixel Clock      : 138.01 MHz
[    22.323] (II) NVIDIA(GPU-0):       HRes, HSyncStart : 1920, 1968
[    22.323] (II) NVIDIA(GPU-0):       HSyncEnd, HTotal : 2000, 2080
[    22.323] (II) NVIDIA(GPU-0):       VRes, VSyncStart : 1080, 1082
[    22.323] (II) NVIDIA(GPU-0):       VSyncEnd, VTotal : 1087, 1111
[    22.323] (II) NVIDIA(GPU-0):       H/V Polarity     : +/+
[    22.323] (II) NVIDIA(GPU-0):     Mode "1920x1080_60" is valid.

You are correct, there are many valid modes, and at the point it sets to NULL it should have picked one of those values. I think it goes back to where that hot plug detect showed it saw a connect, but nothing ever loaded. I think the technical term is “the lights are on, but nobody is home” :P

Basically, it seems to like the monitor, but it doesn’t always know it is there. Perhaps someone else can comment on why HPD might show up in dmesg, yet fail to propagate into the X server.

Additionally, you will probably want to show your “/etc/X11/xorg.conf”…if this is off then it might account for ignoring the monitor.

Also note that the first mode is a detailed mode, which is dangerous, because tegra has chances doesn’t support detailed mode.

[    22.323] (II) NVIDIA(GPU-0):     Mode Sources: NVIDIA Predefined, EDID, Detailed

Detailed mode was the cause for some monitors not working. However, for that kind of error, I never saw i2c r/w error but only system crashed. (This is fixed in rel-28.2 DP)

That is why suggesting to change another monitor to test as well.

Is it possible the i2c communications has some sort of idea of when to stop reading which is incorrect when the mode is detailed? I’m just speculating on the possibility that an i2c error on the DDC wire could be related to the data instead of the electrical wiring and logic.

Is it also possible that detailed descriptors might fail to trigger X setup during HPD?

Let’s wait for albertr to clarify. This case is rare…

albertr,

Please also cat the edid sysfs in “tegradc.0” to confirm that driver indeed not has edid.

If driver does not have edid, it is impossible for X to get edid.
Remember to clean up before test. I mean do not connect HDMI when boot up. By doing so, tegradc.0 should be empty. Later, hotplug HDMI cable and check again.

Hi,

Thank you guys, your help is much appreciated!

Let me try to clarify the problem first: If I boot up TX2 (either cold or warm boot) with monitor connected, then everything work fine. I can switch between any terminals on framebuffer device and vt7(X11) back and forth as long as I want. The monitor is always getting signal from TX2 in 1080@60Hz mode.

The problem starts when I unplug the monitor (either power-cycle it or unplug/replug HDMI cable).
Now every time I switch to vt7 (X11) monitor says “No HDMI signal” and shows blanc screen. But… if I switch to any other terminal on framebuffer device, the monitor gets perfect signal again in 1080@60Hz mode. This behavior is always repeatable, and I cannot get X11 to display anything once it starts doing it. I think it looks like X11 detects monitor hotplug event, but somehow doesn’t like it and sets video mode to “NULL”… framebuffer device doesn’t seem to have this problem.

Here’s a quick test if I do hotplug (disconnect/reconnect monitor) while I’m on vt7 (X11):

  1. Unplug event:

kernel says:

[11117.113047] tegradc 15210000.nvdisplay: hdmi: unplugged

X says:

[ 11117.003] (II) NVIDIA(0): Setting mode "NULL"
  1. Plug event:

kernel says:

[11166.601692] PD DISP0 index2 UP
[11166.606419] PD DISP1 index3 UP
[11166.609705] PD DISP2 index4 UP
[11166.613203] PD DISP2 index4 DOWN
[11166.616970] PD DISP1 index3 DOWN
[11166.620366] PD DISP0 index2 DOWN
[11166.640709] PD DISP0 index2 UP
[11166.644514] PD DISP1 index3 UP
[11166.647722] PD DISP2 index4 UP
[11166.651100] PD DISP2 index4 DOWN
[11166.654509] PD DISP1 index3 DOWN
[11166.657826] PD DISP0 index2 DOWN
[11166.676771] tegradc 15210000.nvdisplay: hdmi: plugged

X says:

(sorry, it doesn’t fit to a single post, please see attached).

Here’s the EDID right at this time:

root@tx2:~# cat `find /sys -name edid`
 00 ff ff ff ff ff ff 00 1c a3 14 00 88 88 00 00
 00 19 01 03 80 1e 11 78 ee cd 70 a3 57 4e 9d 26
 11 50 54 21 08 00 71 40 81 00 81 80 81 c0 01 c1
 95 00 b3 00 d1 c0 e8 35 80 a0 70 38 1f 40 30 20
 25 00 25 a5 10 00 00 1a 00 00 00 ff 00 38 38 38
 38 0a 20 20 20 20 20 20 20 20 00 00 00 fc 00 4f
 6e 6c 61 70 31 33 30 33 0a 20 20 20 00 00 00 fd
 00 38 4c 1e 53 17 00 0a 20 20 20 20 20 20 01 2b
 02 03 1a 71 47 10 03 14 05 13 84 12 23 09 07 07
 83 01 00 00 65 03 0c 00 10 00 8c 0a d0 90 20 40
 31 20 0c 40 55 00 36 d4 31 00 00 18 01 1d 80 18
 71 1c 16 20 58 2c 25 00 36 d4 31 00 00 9e 01 1d
 80 d0 72 1c 16 20 10 2c 25 80 36 d4 31 00 00 9e
 01 1d 00 bc 52 d0 1e 20 b8 28 55 40 36 d4 31 00
 00 1e f3 39 80 18 71 38 2d 40 58 2c 45 00 c4 8e
 21 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 54
root@tx2:~#

and here’s the fb0 mode:

root@tx2:~# cat /sys/class/graphics/fb0/mode
D:1920x1080p-59
root@tx2:~#

So, the mode seems to confirm suspicion that it’s something to do with detailed modes.

If I switch from vt7 (X11) to any other terminal on framebuffer device, the mode gets changed to non-detailed:

root@tx2:~# cat /sys/class/graphics/fb0/mode
U:1920x1080p-59
root@tx2:~#

So, the question is - is there any way to skip detailed modes in X11? Why framebuffer device selects non-detailed mode, but X11 selected detailed one?

Here’s my xorg.conf:

root@tx2:/etc/X11# cat xorg.conf
# Copyright (c) 2011-2013 NVIDIA CORPORATION.  All Rights Reserved.

#
# This is the minimal configuration necessary to use the Tegra driver.
# Please refer to the xorg.conf man page for more configuration
# options provided by the X server, including display-related options
# provided by RandR 1.2 and higher.

# Disable extensions not useful on Tegra.
Section "Module"
    Disable     "dri"
    SubSection  "extmod"
        Option  "omit xfree86-dga"
    EndSubSection
EndSection

Section "Device"
    Identifier  "Tegra0"
    Driver      "nvidia"
    Option      "ModeDebug"
# Allow X server to be started even if no display devices are connected.
    Option      "AllowEmptyInitialConfiguration" "true"
EndSection

root@tx2:/etc/X11# cat /etc/X11/xorg.conf
# Copyright (c) 2011-2013 NVIDIA CORPORATION.  All Rights Reserved.

#
# This is the minimal configuration necessary to use the Tegra driver.
# Please refer to the xorg.conf man page for more configuration
# options provided by the X server, including display-related options
# provided by RandR 1.2 and higher.

# Disable extensions not useful on Tegra.
Section "Module"
    Disable     "dri"
    SubSection  "extmod"
        Option  "omit xfree86-dga"
    EndSubSection
EndSection

Section "Device"
    Identifier  "Tegra0"
    Driver      "nvidia"
    Option      "ModeDebug"
# Allow X server to be started even if no display devices are connected.
    Option      "AllowEmptyInitialConfiguration" "true"
EndSection

-albertr
Xorg.0.log.gz (10.5 KB)

albertr,

Could you also share full dmesg in attachment?

Ok, I’ve just booted up TX2 without the monitor connected.

Obviously, there’s no EDID:

albertr@tx2:~$ sudo bash
root@tx2:~# cat `find /sys -name edid`
No EDID
root@tx2:~#

and video mode is set to some “generic” value:

root@tx2:~# cat /sys/class/graphics/fb0/mode
U:640x480p-60
root@tx2:~#

Plugged in the monitor while was in vt7 (X11) and got the following:

root@tx2:~# cat /sys/class/graphics/fb0/mode
U:1920x1080p-59
root@tx2:~#

Interestingly, the mode is “U” (Unknown) now, not detailed…

kernel says:

[  560.835601] PD DISP0 index2 UP
[  560.840036] PD DISP1 index3 UP
[  560.843598] PD DISP2 index4 UP
[  560.847410] PD DISP2 index4 DOWN
[  560.850834] PD DISP1 index3 DOWN
[  560.854267] PD DISP0 index2 DOWN
[  560.871831] PD DISP0 index2 UP
[  560.875732] PD DISP1 index3 UP
[  560.878968] PD DISP2 index4 UP
[  560.882384] PD DISP2 index4 DOWN
[  560.885839] PD DISP1 index3 DOWN
[  560.889255] PD DISP0 index2 DOWN
[  560.911147] tegradc 15210000.nvdisplay: hdmi: plugged

Now EDID is available:

root@tx2:~# cat `find /sys -name edid`
 00 ff ff ff ff ff ff 00 1c a3 14 00 88 88 00 00
 00 19 01 03 80 1e 11 78 ee cd 70 a3 57 4e 9d 26
 11 50 54 21 08 00 71 40 81 00 81 80 81 c0 01 c1
 95 00 b3 00 d1 c0 e8 35 80 a0 70 38 1f 40 30 20
 25 00 25 a5 10 00 00 1a 00 00 00 ff 00 38 38 38
 38 0a 20 20 20 20 20 20 20 20 00 00 00 fc 00 4f
 6e 6c 61 70 31 33 30 33 0a 20 20 20 00 00 00 fd
 00 38 4c 1e 53 17 00 0a 20 20 20 20 20 20 01 2b
 02 03 1a 71 47 10 03 14 05 13 84 12 23 09 07 07
 83 01 00 00 65 03 0c 00 10 00 8c 0a d0 90 20 40
 31 20 0c 40 55 00 36 d4 31 00 00 18 01 1d 80 18
 71 1c 16 20 58 2c 25 00 36 d4 31 00 00 9e 01 1d
 80 d0 72 1c 16 20 10 2c 25 80 36 d4 31 00 00 9e
 01 1d 00 bc 52 d0 1e 20 b8 28 55 40 36 d4 31 00
 00 1e f3 39 80 18 71 38 2d 40 58 2c 45 00 c4 8e
 21 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 54
root@tx2:~#

Xorg.0.log is attached… please let me know what do you think.

Thanks!
-albertr

Xorg.0.log.gz (10.1 KB)

Attached is the kernel log from the last boot (without the monitor attached). Let me know if you need anything else.

Thanks!

-albertr
dmesg.gz (17.9 KB)

Is there any way to enable more verbose logging in X11 server to see why it sets mode to “NULL”?

-albertr