Nvarguscamerasrc jetpack-4.3, No cameras available, nvbuf_utils: Could not get EGL display connection, requirements

To be more correct, we don’t know it is nvgpu error in the beginning. That is why we asked you to check nvdisplay first.
Turns out nvdisplay is not the cause. So you can ignore the nvdisplay now.

And your assumption of argues first checks nvgpu is not 100% correct. These two driver are not directly related.

There are a lot of libraries in this gstreamer pipeline to make it work.

Actually, this part is argus log.

(Argus) Error EndOfFile: Unexpected error in reading socket (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 266)
(Argus) Error EndOfFile: Receive worker failure, notifying 1 waiting threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 340)
(Argus) Error InvalidState: Argus client is exiting with 1 outstanding client threads (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadCore(), line 357)
(Argus) Error EndOfFile: Receiving thread terminated with error (in src/rpc/socket/client/ClientSocketManager.cpp, function recvThreadWrapper(), line 368)
(Argus) Error EndOfFile: Client thread received an error from socket (in src/rpc/socket/client/ClientSocketManager.cpp, function send(), line 145)
(Argus) Error EndOfFile: (propagating from src/rpc/socket/client/SocketClientDispatch.cpp, function dispatch(), line 87)

But below are not. These are from other libraries.

nvbuf_utils: Could not get EGL display connection
nvbuf_utils: ERROR getting proc addr of eglCreateImageKHR
nvbuf_utils: ERROR getting proc addr of eglDestroyImageKHR
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
Error generated. /dvs/git/dirty/git-master_linux/multimedia/nvgstreamer/gst-nvarguscamera/gstnvarguscamerasrc.cpp, execute:532 No cameras available
Got EOS from element “pipeline0”.
Execution ended after 0:00:00.026902735
Setting pipeline to PAUSED …
Setting pipeline to READY …
Setting pipeline to NULL …
Freeing pipeline …

And why we can find out the root cause is nvgpu is based on this log you provided.

X.Org X Server 1.19.6
Release Date: 2017-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-148-generic aarch64 Ubuntu
Current Operating System: Linux cam5-jp43 4.9.140-topdir-g6b7ebe9-dirty #483 SMP PREEMPT Mon Apr 6 22:27:53 CEST 2020 aarch64
Kernel command line: root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 quiet
Build Date: 03 June 2019 08:11:53AM
xorg-server 2:1.19.6-1ubuntu4.3 (For technical support please see Enterprise open source support | Ubuntu)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/var/log/Xorg.0.log”, Time: Tue Apr 7 09:47:04 2020
(==) Using config file: “/etc/X11/xorg.conf”
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
(EE)
Fatal server error:
(EE) no screens found(EE)
(EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
(EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
(EE)
(EE) Server terminated with error (1). Closing log file.
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: server error

Thus, It means it is not good to add any reason in argus side to tell you something like it is nvgpu error. Argus only knows it is EGL error. And EGL only knows it fails to allocate egldisplay but the actual cause is xorg is not able to get nvgpu driver.

What if next time xorg also fails because of lacking other driver? I would say it is possible and we need another debug in that time.