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.
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
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: