Hi,
I am working on software to interface with a camera over USB and have noticed that when there is no HDMI connection, USB comms to the camera fail. I am using L4T R32.1.
Could someone advise please, the best way to resolve this? I was thinking that the power management could be disabled, however it would be even better to remove the link between the USB ports and HDMI.
Thanks
I’m going to guess that it isn’t that the USB port doesn’t work so much as it is things which run or get assigned with a GUI login changes how the port is accessed (some software depends on a DISPLAY being set). What do you see for “lsusb -t” both with and without the GUI? What is the specific condition which occurs which makes you think USB doesn’t work?
Hi,
Thanks for your response.
Your suggestions have been very useful.
When I execute lsusb -t with and without the display I get the same response.
nvidia@george:~/projects/FujitsuWarp$ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/3p, 5000M
|__ Port 1: Dev 2, If 0, Class=Video, Driver=uvcvideo, 5000M
|__ Port 1: Dev 2, If 1, Class=Video, Driver=uvcvideo, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
The failure manifests itself when reading live data from the camera, using USB3.0. When I either run my own program or the vender’s software to stream the data, disconnecting the display causes streaming to halt. Similarly if I attempt to run either program with the display disconnected, no data is read, then when I connect the display, streaming runs successfully.
Streaming works successfully when using USB2.0, regardless of the display being connected.
So the “root_hub” (and devices connected to the HUB) with “5000M” on the end of the tree list are the USB3 devices. Looks like you have two USB3 USB Video Class devices (UVC, perhaps stereo?). So we know that USB sees the devices, and that the hot plug system correctly announces the devices and the UVC driver loads. It is very very likely that there are “/dev/video#” devices (with numbers, probably “/dev/video0” and “/dev/video1”, although udev might change that). USB itself is unrelated to the issue and functioning as expected.
Note that many video and CUDA programs require access to the GPU, or at least a software version of a video buffer. The particular buffer is determined by the DISPLAY environment variable. Assuming the display works, and that the DISPLAY environment variable points at it, then it should work. Removing the HDMI implies you cannot have a physical display (nor can the DISPLAY be associated with it).
Most likely this software/hardware combination must have an associated DISPLAY. The software won’t care if the software is working with a real monitor, versus working with a virtual buffer never touching a real display. So there are essentially two choices: Plug in a real monitor, or else add a virtual X server which runs without a physical monitor.
NOTE: Lacking permission for access also causes this. Users running this software should be a member of group “video”. “grep video /etc/group”.
I do not have any recommendations for virtual displays, but there are several options. Remote desktop software is designed to work with a virtual display on the Jetson, but a remote client on another computer. This same virtual X server works fine for your purposes. Some URLs to look at (some may be out of date):
[url]http://ubuntuhandbook.org/index.php/2016/07/remote-access-ubuntu-16-04/[/url]
[url]https://devtalk.nvidia.com/default/topic/1001017/jetson-tx2/remote-desktoping-into-jetson-tx2-from-windows-10/post/5123184/#5123184[/url]
[url]https://www.nomachine.com/download/linux&id=30&s=ARM[/url]
[url]https://devtalk.nvidia.com/default/topic/1055054/jetson-nano/x11-xopendisplay-returns-null-/post/5349035/#5349035[/url]
Hopefully others will comment on recommendations for virtual X server choices.
Thanks very much for your help. Sorry for the late response. I got dragged onto another project.
I’ve since made a little progress. I’ve installed a vnc server on the TX2 and can successfully remote desktop to it. This doesn’t fix the problem, however there is still some indication that the issue is closer to being resolved.
With the vnc server running and display disconnected, the application does not run, i.e. attempts to read frames across USB3 fail. When I connect the hdmi display, streaming starts to work. Then when I remove the display, streaming continues to work. Previously streaming would fail immediately when the display was disconnected. Subsequently if I restart the program with the display still connected, streaming fails.
So this indicates that the vnc server is doing something to allow the program to keep running.
I checked the DISPLAY variable and this was not set.
I also tried manually setting the DISPLAY variable to match the vnc server prior to running the application, i.e. export DISPLAY=“:1”, export DISPLAY=1 etc, but this made no difference.
Perhaps this is not a TX2 related question and instead a more general UBUNTU/Linux question, but any ideas you have are appreciated.
Something to check first is what “DISPLAY” the application is inheriting. When you have both a physical display and a virtual display, then likely there are two different DISPLAY environment variables. The application would not care which is used, so long as it exists.
If you are at a command line, and run “echo $DISPLAY”, then it will tell you which is about to be used should a dependent program be run. If the variable is empty, then no display is bound. In “/var/log/” you may see log files with a name format of “Xorg..log” (there are some “.old” versions, those are rotated out past logs). Each “number” corresponds to the DISPLAY, e.g., if “cat $DISPLAY” gives “:0”, then it is Xorg.0.log, and if it is “:10”, then it is “Xorg.10.log”. Your attempt to set DISPLAY was valid and correct. You can manually set DISPLAY from command line, or from a script like rc.local prior to running a command which depends on a DISPLAY, e.g.,
export DISPLAY=":10"
...run some program...
Sometimes a virtual display won’t work correctly if someone is logged in to it locally. Sort of the reverse that a regular display won’t work if nobody is logged in to it. The person who logs in must be the same between the command line running and the person logged in if there is a login. If the server itself is run as a particular user, e.g., as user “ubuntu”, then only user “ubuntu” can display to that server. For an interactive GUI there is a login manager which runs as root, and after authentication X is spawned running suid as the user who was authenticated.
Also note that the home directory of the user running a GUI will log to “~/.xsession-errors”. Prior to starting a session or running X or logging in to any GUI you might mv that file to an alternate name, reboot, and then do whatever commands. After the error see what is in “~/.xsession-errors”.
Also, see what is in the appropriate “/var/log/Xorg..log”. You can hover your mouse over the quote icon in the upper right of one of your existing posts and more icons will pop up. The paper clip icon would allow attaching X logs if renamed to a “.txt” suffix (or maybe a “.log” can be attached directly, but I know “.txt” always works).
I have a similar issue. We’re using a CUDA app with a USB Camera and the V4L2 framwork. The app stops working if the monitor goes to sleep, or no monitor is plugged in.
I traced the problem to the VIDIOC_DQBUF ioctl call never returning. Interestingly enough upping the CPU clock speed resolves the issue. You can up the clock speed by running the command “jetson_clocks”.
I communicated my issue to the TX2 team. They are currently testing a fix.
Apologies to Linuxdev, but I have not had a chance recently to follow up investigations on this as I have been working on another project.
However, I just successfully tested your solution jberling. We are also using an app which uses the V4L2 framework and the same VIDIOC_DQBUF call fails when no HDMI is connected. Running jetson_clocks resolved the issue.
Thanks very much for you post. We can now cancel our large order of dummy HDMI dongles.