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.

Thanks

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.

Hi,
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 libEGL_nvidia.so.0 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)