No DP output on R36.3 with 6.8 kernel on Dell U2414H

Monitor is detected by Xorg.

analog@ubuntu:~$ xrandr -q
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DP-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   1920x1080     60.00*+  59.94    50.00  
   1600x1200     60.00  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1280x720      60.00    59.94    50.00  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       59.94  
   640x480       75.00    59.94    59.93  
DP-1 disconnected (normal left inverted right x axis y axis)

Default R36.3 kernel works fine.

Monitor works fine in bootloader and it also shows the boot logs with SIMPLE_FB enabled.
Another Dell monitor also seems to work fine.

Are you talking about a picky monitor issue after you upgrade to k6.8?

Yes. It doesn’t show anything past the boot logs even though it works fine on 5.15.

Please check the patch list in

Bring Your Own Kernel — NVIDIA Jetson Linux Developer Guide 1 documentation

And make sure you have all the commits. And please compare the dmesg with standard Jetpack 6.0GA(K5.15). To see if there is any clue from the log.

Already did, all patches are there, even the next ones. No suspicious output from dmesg compared to 5.15.

You may try 6.0 to see if it occurs from first kernel 6 version. And then 6.1, 6.2, … to clarify which version the issue begins to occur.

Haven’t tried yet, but I have new data.

If I plug in the display after the kernel is done booting, it outputs fine. But if I boot with the display plugged in, it outputs a skewed image with only the first few rows of pixels on 1440p, changing to 1080p fixes the image in that case, or it doesn’t output anything and the display goes into power save mode (in which case changing resolution doesn’t help).

So on K6.8 it fails due to the resolution 1440p. If you use standard 6.0GA(K5.15), can it work with 1440p?

Yes, on 5.15 it works fine. Also, it’s not because 1440p since the display works fine if plugged in after the board is done booting.

Hi cozzmy13

I have a similar problem with AGX Orin reported in 1080 monitor black screen with JP 6 (36.3.0) with Linux kernel 6.8.7 in AGX Orin

I found a hot fix for this. I think that the problem is the simple-framebuffer driver from kernel 6.8.7. When the display is not connected on boot, the UEFI and the simple-framebuffer driver did not start the display. Then, when we connect the display after boot, is the nvdisplay driver who first init successfully the display. This, because the UEFI did not pass the framebuffer configuration to the kernel device tree, in order that the simple-framebuffer driver inits the display.

My hot fix is to assign a dummy driver name to the framebuffer node in the device tree. In this way, the UEFI will not init the display, and then not pass the framebuffer configuration to the simple-framebuffer driver in the kernel.

	chosen {
		framebuffer {
			//compatible = "simple-framebuffer";
            compatible = "nvidia-dummy";
			status = "disabled";

With this hot fix, my 1080p display works when is connected from boot.

The cons is that we lost the Linux boot messages. A permanent fix should be done by analyzing what causes the problem in the simple-framebuffer driver from Nvidia Linux 5.15 to main stream Linux 6.8.

Hi. Thanks for the help. Reverting kernel commit 5727dcfd8486399c40e39d2c08fe36fedab29d99 ("fbdev: Make registered_fb[] private to fbmem.c") and building clean (“make clean”) to ensure conftest is updated fixes it. Issue is in kernel-open/nvidia/nv-platform.c, where nvidia forcefully disables the clocks used by the framebuffer driver. Upstream removed the variable they used to check for (to see if a framebuffer has been registered?) before disabling the clocks.

1 Like

Hi @cozzmy13

Thanks a lot for your fix. It worked in my end too.

@DaneLLL do you know if there is plans to solve this problem in kernel-open/nvidia/nv-platform.c for a future release?

We will check with our kernel teams. From the discussion, for using K6.8+, the commit has to be reverted. Is it correct?

Yes, that commit needs to be reverted. But the fix should be handled properly in the nvdisplay repo.

1 Like

I had similar kind of issue with multiple displays (bootloader showing ok, later no image signal detected). For the source of error I determined my display port 2.0 cable. One older cable works and another out of the bag does not work.