Sorry for the late replies, I had to do some hardware modding on the jetson (GPIO stuff).
the monitor works great even on jetson boot if I power the usb from another computer, so there is definitely something going on with usb. I don’t have the equipment and knowledge to make a “fake” usb cable where data is hooked to the jetson and 5V power to an external source, but I guess this experiment would show whether usb power is the culprit, or if there is some stuff going on with data.
My guess is that the monitor manufacturer made the mistake of powering the i2c for EDID query from USB instead of from HDMI. If you are ok with powering the USB prior to boot reaching a point where EDID query is required, then it should not matter.
Could someone share the latest status of this issue? I mean why do we have USB here? If this monitor is powered by USB, then it should not have issue with I2C to EDID. The only reason that would cause EDID read failure maybe unstable power supply I guess.
USB is related to the touchscreen. This is also apparently used for other power, and needs to be up for EDID to function (which means USB power up prior to HDMI being queried…entirely an issue of the monitor design and unrelated to the Jetson itself).
I guess the only solution would be to hack a USB cable to get the power directly from the 5V rail, but that may be a bit dangerous.
One thing that is still unclear to me, is that later during the boot process (after the initial EDID read fail noticed by @linuxdev ), there is another EDID read that succeeds (see the serial_log.txt in one of my earlier posts), but the display still looks weird. What is the point of (apparently) reading it a second time if no update is occurring at driver level? Or maybe EDID is then queried a third time, which fails again, aka. fail - success - fail?
I cannot completely answer that, but EDID is hot plug, and there are different stages and/or software which might need EDID. Each time EDID is read the HDMI cable should receive power for the i2c query, then the query completes, then the power for EDID is removed to conserve power. Some bootloader stages may want EDID. When you boot to text mode, then this may want EDID. When you finally reach the X11 GUI stage, then EDID is mandatory for graphics. Note that it is this last EDID query which is failing, and thus graphical mode cannot configure.
Instead of the HDMI providing power to your i2c circuits on the monitor it seems that your USB is providing this. If the USB is not powering the i2c circuits, then EDID query is failing. The i2c circuits of the monitor are not a USB device, and so there would be no ability for a “sleeping” USB to wake up from an EDID query (which goes through HDMI, not USB). All theory, but it seems to be what the evidence is showing.
This would just be my 2 cents contribution, but as @linuxdev mentionned, HDMI is hotplug, so I’d try to boot with USB but without HDMI and plug it in only after one minute.
If it works, it would mean that reading the EDID once the I2C powered by USB is ok.
In case this would work out, you may try a software solution, issuing commands for power down/up cycle on tegradc rail at at point in linux boot where you would be sure USB has started, so that the EDID can be reliably read.
I cannot tell for your release/HW what would be the best way to try that, but probably @linuxdev or @WayneWWW would better advise.
I’d try to boot with USB but without HDMI and plug it in only after one minute
It works and has been my main method of getting the display to work.
What if you boot with HDMI, let it boot and from serial console you put it in sleep state for 5 seconds:
sudo rtcwake -m mem -s 5
Does it succeeds in reading the EDID upon wake up ?
If yes, this would be an inelegant workaround, but there might be better ways to do something similar.
[EDIT: Got some time for trying, and I think there are odds it would work if previous test worked out.
You would create a script such as:
sudo su
gedit /usr/local/sbin/sleepFor5secsAndGetFreshEdid.sh
and paste into it:
#!/bin/sh
/usr/sbin/rtcwake -m mem -s 5
Save it and close gedit.
Make it executable (still as root)
chmod u+x /usr/local/sbin/sleepFor5secsAndGetFreshEdid.sh
Then you would check it works:
/usr/local/sbin/sleepFor5secsAndGetFreshEdid.sh
If all ok so far, you would create a systemd service:
gedit /etc/systemd/system/sleepForReadEdid.service
Where you would paste this:
[Unit]
Description=Goes to sleep mode and re-read EDID before graphics
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/sleepFor5secsAndGetFreshEdid.sh
[Install]
WantedBy=display-manager.service
Save and close. You would check it is ok with:
systemctl start sleepForReadEdid.service
If it works fine, you would enable it and reboot for trying:
systemctl enable sleepForReadEdid.service
reboot
]
Hello. Sorry for the late reply, but I had some urgent work.
I tested the rtcwake trick, and EDID seems not to be read again on wakeup (the screen still looks ugly).
EDIT : so far, only a physical disconnection/reconnection of the HDMI cable does the trick. If we could simulate that, maybe…
Is the touch screen woken? If this is using USB for power, and the power to EDID query relies upon that same USB, then the query would fail until this particular USB wakes up again as well. It is hard to say with what is going on, but it certainly sounds like somewhere something is indeed not waking up correctly without hot plug of the monitor. My suspicion is that using the touch screen’s USB as power to EDID query is wrong, but occurring, and that any suspend issue for the touch screen is spilling over into failing EDID query due to sharing power. I could be completely wrong, but it is hard to say without actually measuring power to the monitor’s i2c rails and power state of the USB to the touch screen.
I checked, the touch functionnality is working at all times (meaning : when I don’t unplug and replug HDMI, when I do it, when I don’t and after the rtcwake command)
If power was available at all times, then I’m not sure why it is failing, but it does seem to be related to power/sleep. Someone from NVIDIA may have a way to examine logs and tell if for example a power rail was sleeping when it should not.
Please note I did quick testing on NX and 5s may not be enough. Please try 10s instead and confirm this doesn’t solve this issue.