SSH -X problems!

Hi! I’m facing a problem that when I connect my jetson NX through my PC, everything looks fine but this error message comes out:

Xlib: extension "NV-GLX" missing on display "localhost:10.0".

Here’s complete message:

robotics@robotics-PC-GN1864YAF:~$ ssh -Y 192.168.11.24
robotics@192.168.11.24's password: 
Permission denied, please try again.
robotics@192.168.11.24's password: 
Welcome to Ubuntu 18.04.5 LTS (GNU/Linux 4.9.140-tegra aarch64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
This system has been minimized by removing packages and content that are
not required on a system that users do not log into.

To restore this content, you can run the 'unminimize' command.

0 packages can be updated.
0 updates are security updates.

Last login: Tue Oct 27 16:38:05 2020 from 192.168.11.10
Xlib:  extension "NV-GLX" missing on display "localhost:10.0".
Xlib:  extension "NV-GLX" missing on display "localhost:10.0".
Xlib:  extension "NV-GLX" missing on display "localhost:10.0".

This caused I can not open any GUI on my PC. In another word: -X became useless. When I open another terminal which is in same session, the terminal came out from my jetson’s screen, not my PC.

I searched a lot and found maybe this problem is from some auto update.
One of the solutions is to reinstall jetson and hold relative packages’ update. But I don’t want to reinstall my whole system, that cost so much time. So does someone have another better solution? Thanks a lot!

Whenever you forward from a Jetson to your host PC the Jetson no longer performs the operations of the GUI driver. The host now performs this work. If the forwarding uses some software feature which the host does not have, then this fails (even if the Jetson itself could perform with that feature since it is no longer the Jetson doing that work). This suggests that your host PC does not have the correct drivers and/or user space libraries. In particular, your host PC lacks “NV-GLX”.

Can you say more about your host PC’s video card and what specific Linux or Ubuntu release it uses? On your host, what do you see from this command’s output (you might need to “sudo apt-get install mesa-utils”):
glxinfo | egrep -i '(version|nvidia)'

Thank you for reply. My PC runs ubuntu 20.04 with no individual graphic card. The output of glxinfo | egrep -i '(version|nvidia)' is

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Version: 20.0.8
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.0.8
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.0.8
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.0.8
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
GL_EXT_shader_implicit_conversions, GL_EXT_shader_integer_mix,

About this error:

The “NV-GLX” is the NVIDIA GLX extension. You are running Mesa, not NVIDIA. It is true that some OpenGL can run on Mesa, but this is a software (in CPU) rendering, not hardware. For CUDA and many of the applications you must use hardware rendering, which is missing on the laptop. The Jetson is not doing the work during a forward (at least not the GPU work), and so there is no possibility of continuing (the hardware and software are missing).

I mentioned in another thread that vino, if used as a virtual desktop, would allow hardware on the Jetson to do all of the work, but display anywhere.

Sorry for the late reply. A strange point is that it worked before with same labtop and same jetson. At least after I connect to jetson by typing ssh -X 192.168.X.X (ip address of jetson) on labtop, I can open another terminal on my labtop by typing gnome-terminal & which is still logged in to jetson. But now the terminal shows up on jetson, not my labtop. I tried vnc before but unfortunately it was too lag that it can not be used it at all. Is there’s anyway just take it back to old time? Like reinstall some packages with old version?

I do not know what vnc would have changed, so I can’t help with that. vnc is its own world (virtually speaking).

Whenever you log in to the Jetson by any means which is not the GUI, then the environment variable “DISPLAY” will not be set. If your user name and DISPLAY match a graphical context, and you run a program using graphics, then that is the reason for the program running there…it is the specified DISPLAY.

An ordinary ssh login (without “-X” or “-Y”) implies there will be no DISPLAY set. If you log in via ssh, but no “-X” or “-Y”, do you see anything from “echo $DISPLAY”?

When you log in via ssh with-X” or “-Y”, the “DISPLAY” should automatically be set to refer to the GUI of the other computer. If you are on the laptop, and log in via one of the “-X” or “-Y” options, what do you see from “echo $DISPLAY”?

If the above is known, then it might be possible to find out where the DISPLAY is being set which you don’t want set.

A little bit busy these days, sorry for the late reply. Hope you still remember this thread :)

I checked “ echo $DISPLAY ” in both ssh without -X and with -X, and the results are as follows:
without -X:nothing as you said
with -X:localhost:10.0

I followed this and did some export DISPLAY=:
but nothing works only error occurred.
However, when I gave up and return it to original situation by typing

export DISPLAY=:localhost:10.0,

I found I can open terminal on my labtop now
even these’s still errors like
# Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-C7LYzO2CY5: Connection refused
after execution but at least something works. This really confused me. As a result I didn’t change anything but something changed. What happened inside it?

You must refer to the X session to use via the DISPLAY environment variable. If this is set, and if security allows it, then this picks where the graphics actually goes to. Most of the local DISPLAY will be of the format “:0”. If a network location is involved, e.g., localhost, then it implies network protocols are being used, such as forwarding to an X server on a different computer. The extra protocols involve more support when using a network.

No DISPLAY implies guaranteed failure. An incorrect DISPLAY (e.g., different user) also guarantees failure. You need to find the DISPLAY of the monitor you wish to use, but ssh is a special case since just specifying the address of the remote host will normally fail from security…the special “-X” or “-Y” ssh options use automatic setup to avoid some of the complications.

However, any program running using X requires the X server of context to support anything the application requires, e.g., perhaps CUDA or OpenGL.

In my case (jetson nano B01) with the last sd card image, the issue appears when installing jetson-stats and disappears if it is uninstalled.
xRDP on LXDE or with putty -X.

Xlib:  extension "NV-GLX" missing on display "localhost:10.0".
Xlib:  extension "NV-GLX" missing on display "localhost:10.0".
Xlib:  extension "NV-GLX" missing on display "localhost:10.0".
2 Likes

Key to knowing what is going on is understanding the difference between forwarding an “X event”, versus forwarding the result of an X event. See:

What you are seeing is that your host PC does not support “NV-GLX”, and this is unrelated to what the Jetson itself supports. If the Jetson has NV-GLX and the NVIDIA GPU which uses this, but the host PC does not, then you’ll either need to add NV-GLX and a compatible NVIDIA GPU to the host PC, or else use events forwarded from the Jetson which does not use this.

Stated another way: The Jetson’s GPU is not used since you’ve forwarded events which the GPU would render…the PC to which you’ve forward now uses its GPU instead.

Really not sure for this case, but you might also try this. It allows forwarding some GL from Jetson over ssh -X.

I understand you explanation about SSH -X.
But why I got the same result when I open LXterminal on a RDP session using LXDE desktop environment LXDE? Is it due to default display manager (gdm, lightdm)?
RDP should “send an actual compressed desktop image” as you wrote.

If the host which is viewing the remote ssh does not support “NV-GLX”, then you get an error if there is an attempt to use it. It won’t matter if the Jetson’s video display supports “NV-GLX” or not since it isn’t the Jetson’s display hardware or software doing the work.

I don’t know about a remote desktop, but I would think that in theory that if the video buffer on the Jetson has an attempt to use a feature not supported in the remote desktop’s buffer at the Jetson side, then you’d also get such an error.

This is entirely contrived as an example, but if a virtual X server running on the Jetson has a configuration required prior to being able to use “NV-GLX”, then you would need to enable that feature for it to work. It won’t matter if it is a virtual display or a remote display when a feature is to be used, but the display does not support the feature.

I wouldn’t advise to use SSH -X for GL operations
It is tricky
However, what proved to work consistently is VNC.
It only requires an actual display to be connected to Jetson, also not hybernated/ power saving mode, but autologin and always on mode.
In the latter case it will be possible to run GL things natively on Jetson through VNC, but get them at laptop/ Host PC reflected at VNC client

1 Like