We are using a Jetson production board that has an USB-C displayport. The problem is the port (USB-C interface) is not hot-plug able.
Case 1: If the port is connected to a monitor after power-up the board, the screen would be blank.
Case 2: Power-up the board with the port connected to the monitor, EDID (run xrandr on a terminal) would always show “connected” even the monitor is actually disconnected from the port.
Do I need to do something at the kernel level so that I can have this hot-plug able feature?
I have tested on a Jetson Nano development kit. It is working fine when I connect the DP to a portable monitor using a bi-directional DP to USB-C cable.
Can you describe your board design from hardware aspect? I mean which pin is in use.
And any kernel log to share?
kern.log (136.3 KB)
kern.log.1 (1.6 MB)
Please let me know if you need a different one.
The hardware designer will address the hardware aspect.
Can you just share the log that after you hotplug the DP cable?
You shouldn’t give a bunch of logs without any description.
Which log file are you referring to? Is kern.log good? I will capture before and after.
If you think the “hotplug” has the problem, then you need to share a log with below procedure done
-
Boot up the device without any cable connected
-
Hot plug the DP cable
-
Share the dmesg.
That’s all. We don’t need to see your whole day log. Also, there is no error from kern.log. You didn’t hotplug the cable.
Xorg01.0.log (19.7 KB)
Xorg02.0.log (15.9 KB)
I attached 2 different log files to show you my tests.
----------------------- Test 1 ---------------------------
- Turn on the system with USB-C cable connected to the port and the monitor.
- Run command at a terminal: xrandr grep | ‘connected’
- Unplug the USB-C cable.
- Run the xrandr command again (blindly hit UP arrow key and ENTER).
- Plug-in the USB-C cable
Xorg01:
[USB-C cable is connected] see line 285 - 288
[USB-C cable is NOT connected] ]see line 289 - 292
Note that they are always connected.
----------------------- Test 2 ---------------------------
- USB-C cable is NOT connected before power-on.
- turn on power.
- USB-C cable is connected to the port.
Note that the SCREEN is still BLANK. - HDMI cable is connected to do file copy.
Xorg02:
Please see line 120: No enabled display devices found; starting anyway because
HI,
I only need the dmesg at this moment.
1 Like
dmesg.txt (1.5 KB)
kern.log (265.7 KB)
Please see dmesg.txt for ‘disable’. I also attached full kern.log if you want to view extra dmesg.
Hi,
I just want to confirm that do you really know what scenario that I want to check here?
The kern.log still shows that you plug the cable before the system boots up.
- Boot up the device without any cable connected
Wait for 2 mins after your power on the board. - Hot plug the DP cable after system is booting up.
- Share the dmesg.
I did boot up the device without any cable connected. Then I attached cable (Nothing happened on the screen). Then I powered off (unplug the power cord). Next step is that I booted up the device with cable connected for file copy and transfer. Kern.log is what was happening.
Xorg_dp_hdmi.0.log (15.9 KB)
Please see line 120 - 126:
[ 18.152] (–) NVIDIA(0): No enabled display devices found; starting anyway because
[ 18.152] (–) NVIDIA(0): AllowEmptyInitialConfiguration is enabled
[ 18.152] (II) NVIDIA(0): Validated MetaModes:
[ 18.152] (II) NVIDIA(0): “NULL”
[ 18.152] (II) NVIDIA(0): Virtual screen size determined to be 640 x 480
[ 18.152] (WW) NVIDIA(0): Unable to get display device for DPI computation.
[ 18.152] (==) NVIDIA(0): DPI set to (75, 75); computed from built-in default
The test was that an HDMI cable connected after few minutes waiting response from USB-C cable. Note that if I did a normal test (described above), I would not see the listed messages.
It looks like that kernel won’t log the listed message when no display detected on the same power cycle (it would go into a ‘virtual screen’). However, it would log ‘virtual screen’ when detected an actual display on the same power-cycle.
By the way, we are expecting what is coming but the kernel won’t.
Hi,
Just want to know that, do you always need a monitor to dump the dmesg? It sounds like you don’t have method to dump log when monitor is gone.
From your comment
I did boot up the device without any cable connected. Then I attached cable (Nothing happened on the screen). → this is the timing that you should dump dmesg
Then I powered off (unplug the power cord). Next step is that I booted up the device with cable connected for file copy and transfer. Kern.log is what was happening. → this log does not record the thing I want to check. This is just a working fine case.
And can your hardware guy comment here? This maybe just a pure hardware issue if the kernel side is not able to detect the hotplug signal.
Sorry, I don’t know how to dump dmesg when nothing happened on the screen. I have sent the message to the hardware guy. I am not sure he is on vacation.
A simple way is you can ssh to the board through the ethernet… and dump the dmesg.
The only problem here is just the monitor, the ethernet side should be no problem. In case you have ethernet on your carrier board.
Sorry, we don’t have an ethernet port on the board. Is there any other way?
Do you have uart pin out there?
I’ll try this way (but I need to buy the cable). Thanks.
Still have other method. Did you ever install sdk from sdkmanager?