Unable to use openGL X11 forwarding on jetson nano

When logging in via ssh to my jetson nano and attempting to run
glxgears
i get the following error:
libGL error: MESA-LOADER: failed to open swrast (search paths /usr/lib/aarch64-linux-gnu/dri:$${ORIGIN}/dri:/usr/lib/dri)

To reproduce
On jetson nano: Install jetpack 4.4.1 from SD card image

sudo apt update
sudo apt install mesa-utils

On local machine: Connect to nano in terminal via ssh ( with forwardX11 yes)

ssh -X ivan@jetson_nano
glxgears

I tried the same with jetpack 4.3 (development board) and here it works fine, glxgears will bring up the GL window on my ssh client

googling around showed that several others have encountered this problem, one suggested solution is
copy libdrm_amdgpu.so.1.0.0.0 from jetpack 4.3 to 4.41 → this did not work for me
delete all files in the libdrm-amdgpu1 package → this did not work for me

I have tried connecting from several different hosts , real Linux computer and a Linux VM. Both hosts give the same result, it works with jetpack 4.3 but in jetpack 4.4 / 4.4.1 i get the libGL error.

Any advise on how to adress this issue for jetpack 4.4.1 would be greatly apprechiated.

You might want to check this out:
https://forums.developer.nvidia.com/t/running-graphical-cuda-sample-over-ssh-from-within-l4t-docker-container/113027/3

Long story short, you need to have a screen “context”, typically by setting the “DISPLAY” environment variable. No setting is the same as nothing to display to. Setting it to a remote system over ssh (requires the -X or -Y option) implies you have a context, but the context will not use the Jetson’s GPU (thus the host PC itself will have to have that functionality).

This is not a bug, it is just how forwarding and X11 context works.

If you truly want the context to be computed on the Jetson, then you have to either run it locally on the desktop there, or else have a virtual desktop (virtual desktops are a full desktop, but they don’t connect to a monitor…they do connect by remote desktop sharing software, but the program you run won’t know about this and will not care).

@linuxdev thanks for good info on ssh X server

The context is that i´m doing development on machine learning and 3D algorithms and I would like to setup the system so i can connect from my development laptop and run vs code connected to the jetson over ssh. One important part is to be able to visualize various data, and for this I need the X11 forwarding from the jetson to work.

On my laptop i have 3D capability, i can for instance run glxgears etc without issues.

The reason I think this is a bug in Jetpack 4.4.1 is that with the exact same setup using Jetpack 4.3 the X11 display works fine. In a clean jetpack 4.3 system i can log in via ssh and display openGL content, such as glxgears. After changing the sd card in the jetson to a jetpack 4.4.1 image → i get the libGL error.

I use the same laptop, physical jetson and test sequence in both cases, the only thing that changed is the jetpack version on the jetson nano.

So Im thinknig my problem must be related to the drivers/software in jetpack 4.4.1. Something that worked fine in jetpack 4.3 is broken in jetpack 4.4.1 (i also tried jetpack 4.4 with the same result as jetpack 4.4.1).

If you do the above it won’t be the Jetson doing the work. The GPU work itself will offload to the laptop. Running like this will demonstrate (if security allows it) using ssh to run glxgears (my example user and IP are ubuntu and 192.168.55.1):
ssh -Y ubuntu@192.168.55.1 glxgears
(if it works, then the Jetson won’t be running any of the GUI part of this, and all libraries and rendering and GPU content will be from the laptop)

If you want the work to run entirely on the Jetson, then the Jetson’s GPU must be used. If you do not have a monitor and session directly on the Jetson, then you must run virtual desktop software. Most people do this with “vino” (I think it has official support), but I could not give you all of the details.

The nice part about a virtual desktop is that you can also connect to it from other operating systems which don’t have X11.

my workflow is typically run some numerically demanding calculations (neural network or other algorithm) that produce a result. I mainly need the display for debug / development purpose to visualize results and sometimes intermediate steps, so in my case its actually fine if the GPU work related to the display is done on the laptop. Im using the jetson GPU for algorithm calculations, not for the actual display of results.

But i think its an interesting suggestion to use vino, with any luck a remote desktop will not have the same issue as X11 forwarding of openGL in jetson nano, so I´ll check it out.

Hi,
This is not tested/verified in default release. Usually we have TV connected to Jetson platform. For checking display remotely, we set up RTSP server on Jetson platform and do RTSP streaming.

For running deep learning inference, we have DeepStream SDK. You may take a look and give it a try.