Display driver problem

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi @WayneWWW & NVIDIA,

I’m facing a problem which I need some help to debug - I’m trying to use a HDMI to 3G SDI converter circuit at 1080p60 with the Jetson and I have received multiple valid EDID’s to try with but all of them fails on kernels newer than R24 on TX1 and TX2 doesn’t work either.

On any other Jetson than Tx1 w. R24 I need to force the EDID using the edid.c file in order to get an image.

With any later kernel than R24 on Tx1 or using a TX2 with any kernel the Hot Plug detect between the converter and the Jetson will just continuously fire as the Jetson fails to output the desired format.

(I’m using a devkit to test with but I have also the same hardware implemented on numerous custom boards which exhibits the same exact problem)

When forcing the EDID.c file into the Jetson (instead of using HDMI DDC) I can get the ubuntu desktop to come up just fine and the converter seems to be working - at first glance.

However, depending on the graphics shown on the screen it may crash.
For example, if you take a window and drag around on the desktop then at certain places (top right and center left) the screen will crash as can be seen below if the window is moved into an area of roughly 1x1cm the screen in either of those two locations.

image

The oddity is that this SDI converter circuit works flawlessly with every PC, MAC, Raspberry Pi, Allwinner, RockChip, iMX6 devkit and even a regular DVD and XBOX I have tried it with but for some reason, it doesn’t work with any JetPack above R24 - so something must be broken somewhere in the graphic drivers.

I understand and appreciate that you would say “we don’t support this use case” just to close this ticket and get on with your daily work, but as it’s obvious that something is broken somewhere in Jetpack then please let’s try to fix it together - we are happy to aid in debugging and are happy to even provide hardware for you to replicate the issue.

We have spend more than 1½ years trying to work around this problem and so far have more than 25 Jetson modules between TX1s and TX2s together with 5 revisions of our custom boards done for these platforms.

Our product is 95% ready for launch and mass production but this issue is now gating as our end customer is not happy about using R24 after they realized that the kernel no longer being supported which puts us against the wall to find a solution.

As mentioned no matter what EDID we have tried the outcome is always the same.
(all setting the same pixel format as below)

The desired output format is:
Pixel Clock: 148.5MHz
Horizontal Active: 1920
Horizontal Blanking: 280
Vertical Active: 1080
Vertical Blanking: 45
Horizontal Sync Offset: 88
Horizontal Sync Pulse: 44
Vertical Sync Offset: 4
Vertical Sync Pulse: 5
Horizontal Display Size: 708
Vertical Display Size: 398
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3

  • I have verified that the pixel clock is indeed 148.5000MHz.
  • I have verified HSYNC & VSYNC to have correct frequencies as well.
  • I have tried adding “ForceCompositionPipeline” but this causes the screen to go black entirely and nothing to work at all.

The EDIDs we have been provided with (more than five different ones) all have the same format specifications as above but in different EDID versions.

Analog Devices have generously confirmed that the hardware build around their ADV7611 HDMI to Parallel converter works as intended with the EDIDs provided.

Their FAE suggested me to try and change the Horizontal Display Size from 708 to 1214 & Vertical Display Size from 398 to 683 to see if it made any difference but I’m not sure if this makes any difference at all as the ratio is the same?

I have no clue where to start hunting for the bug which appears to be with the Jetsons graphics driver and hence any advice you can offer in terms of things to try would be much appriciated - I’m even happy to send you hardware that you could try directly between the jetson devkit and any regular hdmi monitor.

Just let me know as we are practically dead in the water.

I started this case on the link below more than a year ago but you requested me to start a new thread as you believed the bug was to be found in the Graphics driver since it happened in full screen mode.

The old case being:

3

Let me check with our display team internally. Will update to you.

4

adding “ForceCompositionPipeline” but this causes the screen to go black entirely and nothing to work at all.

BTW, any log (xorg.0.log) for this ?

5

Thank you so much @WayneWWW we really appreciate it!

  • I will try and get a devkit up and running with latest jetpack on TX2 and try the ForceCompositionPipeline again so that I can provide a log - but I do seem to remember that it didn’t yield any clues

I’m looking forward to hearing from you in the interim.

Yt
Lasse

6

Hi,

Why do you need devkit to dump log? Why not directly share the log from your current device?

7

Hi Wayne

My current custom device is running TX1 and R24 where everything is working fine.

I have to reflash a newer Jetpack to make the problem appear and hence I might as well try it on a devkit with a TX2 in case you decide to try it in your end.

Yt
Lasse

8

So this adapter is connected through the devkit but not a custom board?

9

Hi Wayne

Yes the setup is:

  • Devkit TX2
  • HDMI to SDI converter
  • SDI to HDMI converter
  • Monitor

Interestingly I tried Jetpack 4.5 today for the first time and I have been unable to provoke the bug so far with that but it appears immediately on:

4.2.2
4.3
4.4
4.4.1

Did you change any display related issues between 4.4.1 and 4.5?

I don’t find anything in the release notes that suggests it?

Yt
Lasse

10

  1. What is the purpose to do hdmi-> sdi → hdmi? Why you have to convert it twice and back it to hdmi signal again?

  2. I am not sure. Will you see this error with other application or only the desktop icon bar?
    Other application means openGL/MMAPI sample/deepstream/gstreamer…

11

Hi Wayne

  1. Our end product (using a custom board) has SDI as it’s only video output with a hardware circuit implemented similar to that of the converter.

The bug we are seeing with the garbled screen occurs on both our custom hardware and on your dev kit using the converter.

We have native SDI field monitors which also shows the problem but to see it on a regular standard monitor I have to convert SDI to HDMI.

My idea of using the devkit and the double conversion was purely in case you wanted to replicate it then I could ship you two converters to try with.

  1. Yes the problem occurs both in the ubuntu desktop but it also happens in our full screen Qt application.

The screen “works” normally until some (unknown) thing provokes the bug to happen.

For example the problem can be provoked instantly and reliably by opening the chromium web browser and going to the Wikipedia website - as soon as the page loads the screen will garble and continue to stay garbled until one reboots the Jetson.

(Other websites and applications running on the Jetson including the ubuntu desktop itself can also make this problem happen)

Yt
Lasse

12

Hi,

Here are some feedback from our team. Please help take a look. If something is wrong, please help point out.

There seems to be two issues here:
i. HDMI hotplug is not stable with HDMI to SDI converter.
ii. With Forced EDID, there’s graphical corruption at specific locations on the screen.

You been trying to resolve this issue for a long time. Could you give brief comment to summarize what you’ve done so far?

For (i), I am ignoring all the basic things like cable quality, checking with multiple monitors or SDI converters, etc. assuming that these things would be the obvious ones, and customer might have already tried.

I would suggest checking the voltage levels of the VDD 5v regulator on Jetson board (at the HDMI port). If there are slight variations in voltage, it might be causing the converter to toggle hpd?

For (ii), it’s surprising that the issue happens only at specific spots on the screen. Probably composition issue. Is those garbled location random one or only to fixed location?

Also, can you try with a lower resolution (may be 720p) to see if the behavior is different?

13

Also, what will be your target release jetpack version?

14

Please also share full dmesg and xorg.0.log.

15

Hi Wayne,

I will come back to you early next week on your questions above next week after debating with our team if we can by any means go for Jetpack 4.5 or would have to stay on 32.2.1 trying to fix the issue with the garbled screen.

I think everyone here would rather opt for 4.5 as we have struggled for so long but our problem is that we are using a leopard imaging IMX185 camera with their ISP override settings and drivers and they do not have a Jetpack 4.5 version so we would most likely have to port it from 32.2.1 onto the latest JP4.5.

Could the ispoverrides file and DTS portion for the IMX185 be used “as-is” for example between 32.2.1 and the latest JP4.5 or would it require a lot of adaptation?

Yours truly
Lasse

19

Hello,

Any feedback for Display driver problem - #12 by WayneWWW?

20

Hello,

Any feedback or at least tell us you are still following this topic?

21

Hi @WayneWWW

Sorry for the delay in getting back as I was out sick but I’m back again.
In the meantime we have started porting to the latest Jetpack and so far we are not seeing the bug.

More testing remains on our side to make totally sure the bug has been resolved but as of today it seems so!

I hope to get back within the next week or two after we have ported more of our system onto the latest jetpack.

Yt
Lasse