Do you believe that an HDMI display that works on RPi will work on jetson TK1? if yes can I know the steps of turning the display ON? ways other than kernel perhaps?
I guess but I’m not sure that my TK1 is not reading the EDID info. of the display, how to fix this problem?
while searching about the problem i read that I have to connect it to another PC with linux base to get the EDID information and then copy it to the xorg file.
I did that and the display works with the PC but I’m not able to get the EDID info., i’m getting the following:
nhh@nhh-VPCEB26FA:~$ sudo get-edid | parse-edid
This is read-edid version 3.0.1. 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 5
No EDID on bus 6
No EDID on bus 7
1 potential busses found: 4
Bus 4 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
Attempting to use the classical VBE interface
Performing real mode VBE call
Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
Function supported
Call successful
VBE version 300
VBE string at 0xc01f4 "ATI ATOMBIOS"
VBE/DDC service about to be called
Report DDC capabilities
Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
Function supported
Call successful
Monitor and video card combination does not support DDC1 transfers
Monitor and video card combination supports DDC2 transfers
0 seconds per 128 byte EDID block transfer
Screen is not blanked during DDC transfer
Reading next EDID block
VBE/DDC service about to be called
Read EDID
Performing real mode VBE call
Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
Function supported
Call failed
The EDID data should not be trusted as the VBE call failed
Error: output block unchanged
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
how to get the EDID info then and make the display work with TK1?
Sometimes a cable can cause EDID read to fail (and adpaters which don’t have that wire present will always fail, e.g., 15-pin VGA). The information from EDID is mandatory if configuration is to be automatic. Setup can be put in manually, but seeing EDID from somewhere else means you don’t need to look up that information via research…if there is no way to get the EDID you have to research what settings to use. It used to be that no EDID existed, and displays always came with timing information in a manual for people to read and manually translate…this is difficult and often no longer even exists.
There are different standards on different cables. The minimum requirements for earlier standards are less stringent than newer standards. A cable of an earlier standard might work on newer/faster signals, it just isn’t guaranteed. It’s nearly impossible to tell what standard a given cable was designed for just by looking at it, but the cables do indeed have a standard version which might matter.
Even if the cable should be good, there are times when a cable gets kinked or crushed and the damage is not visible. Stepping on the cable for example could change RF characteristics even when DC characteristics do not change. Pins could become oxidized over time if not gold plated, so on.
okay so i have tried different HDMI cables, it worked with some and not with the others.
I have relied on the HDMI cable that worked with the display.
and now i have problems:
one is that when the display works I noticed that the background is zoomed in, a part of the background is shown only, how to fix this? if it’s by changing the resolution please let me know how to do that?
and another thing is that when I connect the display to jetson and turn the jetson on, the display does not work. the only condition that makes the display works is to let the jetson TK1 enter the sleep mode and then gets out of it. at that time only I can see the desktop on the display.
One problem is that some display do or do not have internal “scaling”. Scaling would imply the ability to fill the screen exactly with a mode the EDID reports as available although that mode would not normally fit that screen. Scaling could distort the ratio of the width-to-height, or simply enlarge/reduce. If a standard mode is to be displayed, then a monitor without scaling could still support the mode if it is allowable to have part of the screen clipped or part of the screen unused (and RPi screen does not support scaling). This may be part of the issue on that monitor.
The other thing is that typically software to read and configure graphics mode occurs at more than one stage during boot. There could be a text-mode console buffer and/or direct access console, both of which could read EDID before reaching graphical mode, and both of which could succeed or fail (typically the frame buffer display is non-hardware accelerated and very useful because it allows almost any text mode setting without needing a hardware-specific driver). Then the graphical mode hits under X11, and EDID is read again. So whatever reads and uses EDID can succeed or fail at different stages of boot.
In part I am going to guess that either disconnecting/reconnecting a display or going into/out of sleep mode causes EDID to be read again, which could result in success even when it did not work before. Without something like a protocol analyzer or very detailed knowledge of where EDID is read and used it isn’t possible really know what is going on with the one particular monitor.
I have already asked the display company regarding this issue, I’ll quote there answer
"
The resolution will be correct. It’s going to be a problem with overscan, I think. On the R Pi, you have to set the configuration to account for overscan. Is there some sort of configuration file on your jetson?
"
so is there a configuration file in the jetson that I can adjust?
as mentioned above, this problem is called “overscan”, so does the jetson has any program to solve this?
This is most likely a reference to the “modeline” in “/etc/X11/xorg.conf”. That file is mostly empty because those details which used to be written there manually are now dynamically generated via software using EDID. If you can figure out a modeline and manually put in the correct “Section” entry, this would probably do the job.
I’ve never used it, but here’s an interesting URL with a modeline calculator (notice that it has an “overscan” that can be adjusted):
[url]http://arachnoid.com/modelines/[/url]
This solution would be strictly for X11, and would not help in console mode if it is text console with the issue.
That’s what I mean when I say the file “/etc/X11/xorg.conf” is mostly empty. You have to write those sections (EDID would normally write that information dynamically as a monitor is detected). Because EDID is failing you, this is the alternative for you to create it by manual edit.