EGL: eglGetDisplay failing on TX2 (Jetpack 4.2.2)

We’re not managing to use EGL on a TX2 module.

Machine details:

driveu@gen156-461t:/opt/driveu/streamer$ uname -a
Linux gen156-461t 4.9.140-4.9.306.0 #1 SMP PREEMPT Wed May 19 15:44:31 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

driveu@gen156-461t:/opt/driveu/streamer$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

driveu@gen156-461t:/opt/driveu/streamer$ head -1 /etc/nv_tegra_release
# R32 (release), REVISION: 2.1, GCID: 16294929, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug 13 04:45:36 UTC 2019

According to jtop the Jetpack version is Jetpack 4.2.2 [L4T 32.2.1].

list of cuda / egl apt packages on the machine:
cuda_packages (1.6 KB)
egl_packages (675 Bytes)

Description of the symptoms:

We’re seeing the following error messages:

nvbuf_utils: Could not get EGL display connection
nvbuf_utils: ERROR getting proc addr of eglCreateImageKHR
nvbuf_utils: ERROR getting proc addr of eglDestroyImageKHR

Our application tries to run the function eglGetDisplay( EGL_DEFAULT_DISPLAY ), and it returns the error value EGL_NO_DISPLAY.

We found an independent application that attempts to create an EGL + OpenGL context using glad, and it also fails on your TX2. :

driveu@gen156-461t:~/egl_example-master$ ./egl_example
failed to EGL with glad.

Some extra details:

  • The machine wasn’t set-up by us, so I’m currently not sure what the installation process of the Jetpack / OS was.
  • I am connected to the TX2 machine via SSH
  • X11 doesn’t seem to be running
  • Our exact same software does work on an Advantech TX2 (MIC-720AI) which we flashed with Jetpack 4.2.3 using the Nvidia SDKM. (I’ll emphasize that the problematic TX2 isn’t necessarily an Advantech module, I don’t currently know what the exact make of the problematic TX2 is).
  • There is no DISPLAY env var defined. Setting it to :0 doesn’t work as well.

I’ll appreciate any help.
Let me know if any additional info is needed.


1 Like

No graphical display will be possible unless one of these exist:

  • An X11 GUI on the machine being run on, with the correct export of “DISPLAY”;
  • X11 is forwarded to another computer with the required GUI components (basically a remote “DISPLAY”);
  • A virtual X server is running and exported (like a real X server so far as the software is concerned, but a virtual desktop can be forwarded to any other system which has the right virtual desktop client).

One such way to forward X11 to another Linux computer with the correct X server on that other system is through “ssh -Y” or “ssh -X”, but you mentioned ssh is not running. Basically the X events have to reach a server, and the server must support the required EGL services. This is the structure of an X application and is not related specifically to a Jetson.

Do note that the Jetson’s GPU is not used if you forward…this then becomes the role of the desktop PC being forwarded to. A virtual desktop implies the software does run on the Jetson’s GPU, and rather than forwarding events for another system to interpret there will instead be a forwarding of results of events.

X is more than graphics software: X is a buffer with a defined interface which just happens (most of the time) to get a buffer which a monitor can attach to. The GPU driver tends to be a plugin module to the X server, and some non-GUI software can use this as well. Thus the “$DISPLAYmust be defined if EGL is used.

Perhaps the board has a virtual desktop installed? Without ssh forwarding I’d think it needs either a regular X server or else a virtual X server.

1 Like

Do yo consider to upgrade to later Jetpack? The latest one is JP4.5.1. Since you have tried JP4.2.3, maybe it should not need much effort to upgrade from JP4.2.2 to JP4.2.3?

Thanks @linuxdev, @DaneLLL for your suggestions.

Eventually I found the root of the problem.

In the directory /usr/share/glvnd/egl_vendor.d/, there was only one file called 50_mesa.json, which defined an empty string for the library_path.
Once I added the file 10_nvidia.json, which defines as the library_path, things started working.

I’m guessing that the 10_nvidia.json file was missing because our client did a non-standard installation of Jetpack.

I’ll mark this reply as a solution in case it helps anyone in the future.

10_nvidia.json (107 Bytes)
50_mesa.json (89 Bytes)

1 Like