R32.3.1 tx2-4g running gstreamer from ssh connection gets nvbuf_utils: Could not get EGL display connection

nveglglessink displays from a xterm on the system just fine, using ssh -Y causes my working gstreamer to give the error nvbuf_utils: Could not get EGL display connection

@Honey_Patouceul any suggestions i linked the libs you said before and I still get this problem

I am using a mipi DSI display as my main console, what info do I need to collect to help fix this problem?


Do note that when you use ssh with forwarding, then some of the graphics/GPU content is now offloaded to the host PC and no longer runs on the Jetson. This means if you had all requirements to run a program on the Jetson, and it works, but you get errors like this when forwarding, then it is the host PC itself which lacks this ability. The missing EGL display requirements imply your host PC needs software added to support that EGL display ability. I don’t know what needs to be added to the host PC, but whatever EGL requirements there are, this is your missing software on the host PC side.

Note that some people use a virtual desktop server rather than forwarding. Forwarding mandates your host is not only running an X server, but that the X server needs all of those features. Running a virtual desktop implies there is no offloading to the host PC, and the Jetson would perform those functions…one would be forwarding the result of various events with a virtual desktop, whereas ssh forwarding forwards an event which needs to be turned into an X event result. A virtual desktop works across operating systems and does not require the PC run X, nor would it require (when X is being run) compatible software.

Ok, I understand, what virtual desktop server is supported by nvidia, tightVNC and x11vnc do not work, am willing to try others.

Thanks LinuxDev


I haven’t actually set up a virtual desktop for a Jetson, but I think “vino” is officially supported. I’ve also heard of other vnc working. Someone else will probably need to answer for what is known working, but this URL might be a good place to start for vnc:

Keep in mind that whichever one you use that the “DISPLAY” environment variable will differ between the virtual server (as seen when logged in to the Jetson) and the original native server. The log name will have that “DISPLAY” in its name, e.g., the default log is probably “/var/log/Xorg.0.log”, and if “DISPLAY” is “:10” for the virtual server (which is traditional), then the log would be “/var/log/Xorg.10.log”. Whatever happens you will want to look at or post that log if it isn’t working.

For remote desktop, I haven’t tried vino, but you may read this post. Really suggest you first try to connect to Jetson having local display, mouse and keyboard and Ubuntu GUI user session opened.

About forwarding nveglglessink through ssh, I’m quite sure I’ve had this working after setting this drm link, but I’m currently unable to reproduce that… I think it was R32.5.0 or may be R32.4… I have to say that I had several binary patched libs links that have been changed by upgrades and not sure if I will be able to get it, and even in this case this may not be applicable to your case with R32.3.1 on TX2-4G.
I’ll share here if I find out the gist of this.
Someone more skilled or NVIDIA experts may also better advise about this.

I went into the “Share display” setting screen and enabled it. I then used Remmine in linux and used VNC to see the console remotely. All my qt and video could be seen remotely.

Have not found any other VNC tools that work for other systems, only Linux works for me for now.

It is slow and the quality is poor, I found that I could change the quality setting in my Remmine window, and I used the ethernet for better speed, but I am waiting on Management for feedback if this is good enough for the product.


NoMachine works with Windows as well.

both vnc viewer on Microsoft and android are working, the encryption was a main problem, but found a dconf command to turn off encryption and other viewers are working.

I had to do the dconf command from the “user”. It was almost like dconf stuff was being controlled on a user level instead of the global level.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.