I’m trying to start using the Jetson Nano 2GB but my monitors do not have HDMI, so I’m using an HDMI to VGA adapter (no EDID).
I’ve been digging about how to convince the Nano to enable display though, so far, no luck. HDMI shows disconnected.
Is there a known way to force HDMI configuration ?
I have read a couple of articles recently that stated that the Nano 4GB will not work with HDMI to VGA adapters and it is probably the same with the 2GB. HDMI monitors are pretty cheap now and very few SBCs have VGA outputs unless they are very old.
I’ve already a pair of displays that support both DVID and DP but not HDMI, and I’m not adding more displays just for this…
I’ve seen many articles that say how to fiddle with EDID data, bnd managed to build the kernel from sources, so unless the hardware does not allow it, I’m looking forward to use my VGA converter :)
I have not personally done this, but you might be able to change the default fallback mode, and if lucky, then the VGA monitor would work with that mode:
What it comes down to is that the driver will only accept modes via EDID, and there are some restrictions on that as well (such as no interlaced modes and no extension modes). If a suitable EDID is not found, then it will use a fallback mode, and you can possibly edit the kernel to use a fallback mode which is convenient to you.
I’m lost here: the thread you linked too seems to be related to a resolution selection process, from the resolutions posted by the EDID data. But in my case, there is no such data.
If there is a fallback mode, then anything might work but the HDMI port stays in “disconnected”. The monitor I have is reasonably flexible as to resolutions and timings, but I have not been able to kick the port “on” so to say.
There is a predefined list of modes in the kernel code, and if EDID fails, then one of those modes is picked to run “blind”. You would be editing the fallback mode used when no EDID is found. The trick is that you’d need to have it pick a fallback mode which works with your monitor and is simultaneously available as one of the predefined “acceptable” modes.
Alright then, I’ll search for that code. Happen to know where is it ? :)
Within the kernel source “
drivers/video/tegra/dc/”. Possible files you might be interested in:
Since I have not actually changed the fallback mode used when EDID is missing I couldn’t say what the exact file is to edit (someone else here probably does know). Some functions to check:
check_...hardware specific name...mode_timings
I managed to enable fallback mode, but the board still sees hdmi as disconnected (and reports NO EDID).
Using default (as provided) 720p EDID, hoped it would pass the filter of “acceptable” modes, but either it does not, or I’m missing something else.
I’m open to advise :) Thanks.
If there is no EDID, then the i2c query on the HDMI cable failed. VGA adapters tend to not even have that wire (the DDC wire), and so there is no possibility of recognizing such an adapter unless it is active and inserts an EDID which you have manually programmed.
Well, I’m still looking for a software solution, since I’m using the same hdmi -> VGA adapter with other systems and it has no issues. If the software is in control of the hardware, that is.
In trying to understand the control flow of the discovery, I run into another issue: an assertion failure at initial boot :( This after puting a new “kernel” in the SD card to debug “invalid edid” messages. Now I’m stuck :(
Most video drivers accept EDID to auto configure, but also accept manually configured values. The Jetson video driver only accepts EDID. EDID itself has a checksum, and if the EDID is not passing the checksum, then this is the same as not having an EDID. Fallback modes are what you’ll have to use, but if you have some sort of passing of an EDID, then it must have a valid checksum.
Did your VGA to HDMI adapter have a step to program the EDID?
I don’t think my cable replies with any EDID. No, I have not programmed it.
But I did program fallback mode and it’s not being used either. I hoped that on any error, the fallback would be applie. That seems not to be the case.
If you’ve edited to use a default fallback mode through kernel edits, then the fallback would itself need a valid checksum. In the case of editing kernel code for a different fallback there might be something you missed if checksum is not working correctly.
I’ve just enabled fallback, the kernel code has a default 720 EDID in place which I assume has a valid checksum! As I said before, I also assume it is valid for the list of supported “filtered” EDIDs.