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.