I want to make sure i’m not about to screw something up here …
I’ve currently got a monitor hooked up to my TX2 but am also logged in to my board via a VNC session from another computer.
I can control my TX2 remotely, that’s working fine.
However, I’d like to run a program that I’ve compiled for my board that opens up a viewing window showing the output from a webcam (this MATLAB example, actually.)
I’m not seeing the webcam window pop up and know that I can change the DISPLAY environment variable … but don’t want to screw things up terribly.
Currently, if I echo $DISPLAY, I get a return of :1
Order is not enforced, but typically as more X servers are run, they start at “:0” and then “:1” and up (that’s only tradition). Most of the time I’ve seen virtual servers start at “:10” (this too is just a tradition, and very often won’t be true). What it comes down to is that at the time the X server starts there must be a DISPLAY associated with it. All of those above formats are X servers (regardless of being virtual or not) which are local to the system.
The syntax changes somewhat, and due to security gets much more complicated, if you wish to name an X server on a different computer. Programs which forward X events (such as “ssh” when run with either the “-X” or “-Y” option) handle all of the security issues for you. If you were to manually perform a lot of configuration, then the DISPLAY would change to a format such as “192.168.55.100:0”…which would be telling the Jetson to forward events to the machine at “192.168.55.100”, using it’s “DISPLAY=:0”. Virtual servers do not do this.
Virtual servers run everything in the Jetson’s local X server, and instead of forwarding X events, they forward the results of X events. In a case where you forward events, then the host PC would have to provide all GPU hardware and software itself. In the case of a virtual server running on the Jetson, then the results being forwarded don’t care what the host PC runs so long as it has a client. Virtual servers can easily forward to other operating systems which don’t have an X server.
If you try to display to a DISPLAY which doesn’t exist, then the application will just fail to start. If you try to display to a DISPLAY which your user is not logged in to, then security will block you unless you’ve manually made sure security settings allow it.
Typically the log files in “/var/log/” also get named after the DISPLAY. If the DISPLAY is “:0”, then it is log name “Xorg.0.log’”. If the DISPLAY runs as “:1”, then the log will show up as “Xorg.1.log”. Looking at the timestamp of the log in “/var/log” is a nice way to verify if the server was just started up or if it is a DISPLAY which is not used (or wasn’t used recently).
This is just an environment variable. You could set this and keep it exported (until next boot) via: export DISPLAY=:0
…and if this is wrong, then any application trying to launch a GUI app would fail until reboot.
To launch a single application (I’ll use “xterm” just as a contrived example), which would disappear upon exiting that application (no reboot required), you’d add this in the command line: DISPLAY=:0 xterm
(note that if you were already in that going you’d just use “xterm”)
All terminals which are in a text console mode need to be told which GUI to use if the command being launched requires a GUI (CUDA quite often fits this requirement).
Any failure of the application should be harmless (or at most require a reboot unless you’ve edited init files in some unusual way).