I have Ubuntu 14.04 with Linux version 3.10.40-grinch-21.3.4 running on my Jetson TK1 and I am using this 7" touchscreen monitor: https://www.amazon.com/gp/product/B00XUAIP9K/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 It is connected via HDMI and micro USB to the TK1.
I believe the issue I’m facing is that during system boot, the time between power being applied to the monitor via USB and when the tegra_dc_hdmi_irq is started is not long enough, and the EDID check fails. This is confirmed because if I power the monitor via external power (not the TK1 USB port) and then reboot the TK1, the EDID check is successful.
When powered by the TK1’s USB port…
xrandr -q --verbose
shows “HDMI-0 disconnected primary” and all properties except for EDID are good. When powered externally, the EDID shows up. ’
No reconfiguration through xrandr has any effect.
I figure I have two options:
-
Write a script to run after boot through cron or similar which will activate the hdmi_state_machine_worker to check the EDID again.
-
Modify the boot sequence/configuration such that enough time passes between the USB driver being powered and the first attempt at connecting to the HDMI.
It would be insightful to understand if both are possible, and how I might go about implementing them. The only fix is removing the HDMI cable and plugging it back in but this is not an acceptable solution.
Solving it via the first option involved writing 1 into /sys/kernel/debug/tegra_hdmi/hotplug, but I still wonder if there is a solution by the second option such that the boot sequence is visible on the monitor…
If interested, here is the pin numbering for an HDMI type-A connector:
[url]https://i.stack.imgur.com/k1PeR.gif[/url]
Pin 18 provides 55 mA at 5V (pin 17 is the ground return path), and comes from the video card (host). The DDC line is where EDID comes from via an i2c query/response. i2c cannot query prior to 5V being applied unless the monitor has its own power applied. Applying power does not cause an i2c query, it simply makes it possible (it probably isn’t valid for a monitor to spew out EDID unless asked).
This is just curiosity for me, but I have to wonder about how timing of application of power changes things since applying power does not perform an actual i2c query. It would be valid for there to be an i2c query as early as the boot loader. The Jetson provides 5V as soon as power is applied…prior to the boot loader even running. Certainly when the Linux kernel is loaded and console and boot log begin such a query must succeed if auto configuration is to run. Have you verified when the query begins by i2c protocol analyzer? Is your research related only to time of powering up? Seeing the actual query timing would be of interest…this would require an i2c protocol analyzer.
The hot plug wire would be expected to trigger a new i2c query. I’m not sure which stages of boot send such a query when connected from the start. I wonder if the timing of the cold boot query is timed correctly for this hardware combination…I have not looked at actual order this occurs, but I can’t imagine the first query after the Linux kernel loads for text mode would occur prior to the driver being in a state capable of using the information…most likely it is the driver load itself which triggers the query.
Pardon me for I will not be able to verify the query using an i2c protocol analyzer.
The only hardware solution I was able to come up with, as you mentioned, is using a USB hub which is powered on prior to booting the TK1.
Now a similar issue occurs with the touchscreen response. Although the monitor is connected successfully during boot from being externally powered, the touchscreen response does not work until I unplug the USB cable and plug it back in. I have tried the two software solutions below, but neither work.
-
usbreset program: [url]How do you reset a USB device from the command line? - Ask Ubuntu
-
echoing 0, followed by 1 to the appropriate /sys/bus/usb/devices/{corrrect-bus-port}/authorized
I couldn’t tell you exactly what to do, but you might look at “/var/log/Xorg.0.log”. In this you will see it loading different devices. The Input devices include touch screens and mice. Until the Xorg X server is running and listening there won’t be any touch screen response. If you unplug and re-plug a USB input device while the Xorg server runs the hot plug event will be picked up and whatever rule it has for using that device will kick in.
One possibility is that the driver for the input device is not running such that at start of X the input device would be known (a case where it wouldn’t be possible for X to see the device). TIme stamps of the the driver itself for the device would need something to make sure it loads prior to X starting, e.g., module pre-loading (or unplug/re-plug). If you look at dmesg and see the time stamps for when the input device is loaded or detected you could compare it to the “/var/log/Xorg.0.log” time stamps at the moment when input devices start loading to see which occurs first.
Another possibility is that the input device is started, but initial start of the X server for some reason has a bug which ignores the device until a hot plug event sees it again. You could check the Xorg.0.log after boot when the touch screen does not work, and then again after unplug/re-plug and see if any clues show up. If the device was configured prior to X starting (case 1 not being the situation), then it would be a bug in the X server setup needing hot plug to use a device which was already there. If loading the device at X startup had not been possible, and hot plug triggered the first device availability, then it isn’t an X server issue. Look at any clues as to when the device could be made available, versus when the device is first used (at X startup of Input devices).
![https://i.stack.imgur.com/k1PeR.gif[/url]](https://i.stack.imgur.com/k1PeR.gif%5B/url%5D){kind=link}