Hello! So I’ve been trying very hard to remote control a Jetson TX2 from an ubuntu machine. I am very new to this stuff so there are manhy things i do not understand. I just installed Jetpack 3.1 and I really want to run a sample on my jetson and be able to see the graphics on my ubuntu computer without having to attach an extra monitor/keyboard to the jetson itself. Does anyone know how to do this STEP BY STEP to get this working on my ubuntu computer?
Thanks in advance.
use ssh with the flag “-X”. IIRC it does some processing onboard the ubuntu machine to create the displays, but as a simple test it should show results.
Here is a step-by-step tutorial:
let’s assume your Jetson is called “192.168.0.5” and you’re using the “nvidia” login
let’s assume you’re currently running Ubuntu 14.04 or 16.04 on your host computer
Do the following in a Ubuntu terminal window:
ssh -X nvidia@192.168.0.5
This will connect you to a command line shell on the Jetson. This is the only command you run on the host – the other commands below are all for the Jetson itself.
export DISPLAY=:10
This tells whatever program you start to connect to “display 10” of the system, which happens to be the default virtual display that ssh -X creates to forward to your host.
xeyes &
If that doesn’t start, then you might need to first:
sudo apt install x11-apps
Each program you start from the command line on display 10 will be forwarded to your host screen.
If you want a graphical file browser:
sudo apt install pcmanfm
pcmanfm &
Now, there is a snag. Because graphics is forwarded to your host computer, if the program you start asks for OpenGL to do rendering, it will talk to the OpenGL ON YOUR HOST, not to the built-in Jetson GPU. However, tools that use native libraries like cuDNN or whatnot will likely still talk straight to the Jetson GPU.
Beware that using ssh with “-X” or “-Y” gets graphics to the ssh machine from the Jetson via forwarding of X events, not graphics. This implies that doing so transfers part of the GPU function to the desktop PC host and offloads that function away from the Jetson. An example would be that if you have hardware accelerated OpenGL, then the GPU on the Jetson would not be used, and instead you’d unexpectedly get really great performance from your PC host with that 1080Ti video card :). The same is true for all GPU function using CUDA…if the host did not have compatible CUDA, then you’d get an error of not being able to find the library…if the host was compatible, then you’d get really great performance because the Jeton GPU would be ignored and GPU function for CUDA would offload to the 1080Ti on the PC host.
To remote display while using the Jetson GPU you need some sort of remote desktop sharing software (many threads in the forum exist on this topic). This way the Jetson displays to a virtual buffer inside of the Jetson, and a remote system monitors that buffer instead of X events.
Thank you so much all of you! I also have a question for @snarky, I followed your instructions step by step and after i run
pcmanfm &
i get the nvidia home folder to open but in the terminal i get a message that says “x-terminal-emulator has very limited support. consider choose another terminal” is that going to be an issue?
What if you use “lxterm” as your terminal (haven’t tried the software myself, am about to though)?
EDIT: Package name “lxterminal”, e.g., “sudo apt-get install lxterminal”.
it showed the same message, i just tried it :( Also, i tried to run the backend sample but when i set the DISPLAY:=10 i get an error that says “ERROR while initialize EGL display connection” If i switch the DISPLAY:=0 i get the sample running and at the end it says it ran successfully but i am not able to see any of the graphics. is there a way that i will be able to see the graphics maybe setting the display to something different?
Also I noticed that you mentioned using a remote desktop sharing software, i am having trouble finding a forum that explains this for jetson tx2. can you please post some successful links of threads where people have connected their jetson using remote desktop successfully?
thanks in advance!
Remote desktop sharing should be the same on all of the Ubuntu distributions (package availability may differ between architectures, but if the package is available, then setup should be identical). See:
[url][HowTo]Install VirtualGL and TurboVNC to Jetson TK1 - Jetson TK1 - NVIDIA Developer Forums
DISPLAY is an environment variable which matches a running server. Mostly “:0” implies the first local display, “:10” would be a different display. It isn’t mandatory that a server have a particular “:#”, just that to match this is required to display on that server. This is a minimum requirement, there are still issues such as security. For example, using “:0” implies this first server of the local machine, but “192.168.1.2:0” would imply the first server of the remote machine at 192.168.1.2. Security would get in the way unless you went through some setup procedures. Even if you did this, the server still may not connect if TCP remote sharing is required (normally it uses UDP and TCP is disabled). To use a virtual desktop implies matching security, matching DISPLAY, and providing software which uses the correct protocol at each side…a virtual desktop gets around the TCP requirement because it is a substitute for the server itself having that requirement.
Regarding EGL, if you forward X events to the local DISPLAY under “:0”, then it should work if the display has EGL capability and if you are logged in as the same user under something like ssh or local text console as is the X server. When you open a console within X the DISPLAY variable is automatically set, and obviously security allows you to display to your own login. DISPLAY must be manually set if the login and display are not to the same GUI.
Should you set DISPLAY to a server which does not have EGL (and assuming the application requires EGL), then you will get an error. Should you set DISPLAY to a server using a wrong version of EGL, you would also get an error. It seems like “:0” was correct for you, but try testing with programs which are generic in nature and do not have special library requirements. An example would this command: “DISPLAY=:0 xterm”. The “xterm” should open up.
Whenever you talk about opening a graphical program you should state if the user opening the program is logged in to the machine where the program is to be displayed. You should also mention how you are logged in, e.g., a terminal ran the command within the X GUI environment, or a terminal on a non-GUI text console was used after setting DISPLAY, or ssh was used, so on.
Be aware that each server has a different DISPLAY. The native X server would typically be “:0”, probably a virtual server would set something like “:10”. Your user must be logged in to whichever server you want to display to regardless of whether it is real or virtual. When you run a command as a particular user to start an X session (regardless of real or virtual), then that user is the one logged in.