EGL without X on TK1

Forgive my ignorance, but I’m struggling getting EGL to work on the TK1 while X11 is not running. My test program is

#include <EGL/egl.h>
#include <cstdio>
#include <cstdlib>

int main(int argc, const char* argv[]) {
  EGLBoolean egl_result;
  EGLDisplay display;
  EGLint major, minor;

  display = eglGetDisplay(EGL_DEFAULT_DISPLAY);

  if (display == EGL_NO_DISPLAY) {
    printf("got no EGL dislpay\n");
    exit(-1);
  }

  egl_result = eglInitialize(display, &major, &minor);

if (egl_result) {
    printf("EGL version is %i.%i\n", major, minor);
  } else {
    printf("error initializing EGL: %i\n", egl_result);
  }
}

The eglGetDisplay call succeeds, but the eglInitialize call returns 0 iff X is not running. Doing an “export DISPLAY=:0” is sufficient for the program to report EGL 1.4 support, but I’d really like to get this working without X if possible at all.

I’m compiling with “g++ -lEGL <…>” and running ldd on the binary gives

libEGL.so.1 => /usr/lib/arm-linux-gnueabihf/tegra-egl/libEGL.so.1 (0xb66d7000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb66b5000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb65ce000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb65b3000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb65a5000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6539000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb652d000)
libnvidia-glsi.so.19.3 => /usr/lib/arm-linux-gnueabihf/tegra/libnvidia-glsi.so.19.3 (0xb64cf000)
libnvrm.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvrm.so (0xb64b7000)
libnvrm_graphics.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvrm_graphics.so (0xb64a6000)
libnvos.so => /usr/lib/arm-linux-gnueabihf/tegra/libnvos.so (0xb6490000)
lib/ld-linux-armhf.so.3 (0xb6785000)
libX11.so.6 => /usr/lib/arm-linux-gnueabihf/libX11.so.6 (0xb63a9000)
libXext.so.6 => /usr/lib/arm-linux-gnueabihf/libXext.so.6 (0xb6396000)
libnvidia-rmapi-tegra.so.19.3 => /usr/lib/arm-linux-gnueabihf/tegra/libnvidia-rmapi-tegra.so.19.3 (0xb6387000)
libxcb.so.1 => /usr/lib/arm-linux-gnueabihf/libxcb.so.1 (0xb636d000)
libXau.so.6 => /usr/lib/arm-linux-gnueabihf/libXau.so.6 (0xb6362000)
libXdmcp.so.6 => /usr/lib/arm-linux-gnueabihf/libXdmcp.so.6 (0xb6355000)

Is there a way to get this going?

I think the EGL needs X.Org with the Linux for Tegra. I’m not entirely sure though.

Since EGL is just a subset of OpenGL, you would need a running X display to run EGL just like OpenGL. Are you speaking of compile failing without X running? Or are you talking about an already-compiled application failing to run without X?

EGL is not a subset of OpenGL, but rather a standalone API. Amongst other things it allows to get and OpenGL context and consequently use the OpenGL (or OpenVP, or…) API. It’s not uncommon to have EGL usable without X on embedded platforms, and I assume that’s possible on the TK1, too.

I take availability of Android on the TK1 as a strong indication that it is indeed possible, because Android has colorful pixels and accelerated media processing and OpenGL and all the good stuff, but there’s no X on Android.

It’s just unknown (to me) how to make use of it.

That’s the problem. For example, the same program works on an Raspberry PI even when no X is available. Which is nice. :-)

Also, there’s this:

nvgstplayer-1.0 -i <video file> --svs="nvhdmioverlaysink"

which works without X running (and is relevant to what I’m trying to accomplish).

Edit: After digging through the sources of nvhdmioverlaysink I found that it uses the OMX.Nvidia.render.hdmi.overlay.yuv420 component to get something on the screen. So now I have an additional question:

Are the provided OMX components documented somewhere?

GStreamer is the officially supported video API, so there’s no documentation for the OMX (at least I haven’t seen any) even though the GST plugins currently use OMX for the actual work.

I know of many applications which run without a window manager, but if X is gone, wouldn’t there be a need for some form of graphics mode rendering context?

Thus the following: I know EGL is actually standalone, I should say instead that OpenGL ES is derived from OpenGL and there is an EGL “glue” layer which is similar to what GLX does for OpenGL. The thing is that regardless of whether it is GLX or EGL (and OpenGL or ES) there needs to be a rendering context. If X is removed, what is installed for rendering context? EGL itself is not a render context…I don’t know what Android uses, but if there is no X, then something else was added following Khronos group standards.

EGL needs something for actually showing the content. I guess it could be the traditional framebuffer or something newer or it could be X.Org. In the case of Jetson, it works only with X.Org.

Hi!

I’m starting working with Jetson. Had planned to work with EGL instead of X11. Is there any good news about EGL on the new Linux4Tegra r21?

Thank you!!!

EGL works yes, but only on top of X11. You can run it in fullscreen and pretend that the X11 isn’t there…

i’m in complete agreement here, if X11 is not needed, don’t require it!
Developing for embedded devices is already hard enough, dependencies need to be kept to a minimum.

iirc Raspberry Pi does not require X11 to run openGLES.

I have also asked about OMX testcase (kulve),

an openGL testcase not requiring X11 would be welcome.

I’m curious what EGL binds to in Raspberry Pi and Android for cases where X is not used. It’s easy to remove a window manager and use just X+EGL, but since EGL needs something to bind to perhaps there is some sort of direct frame buffer glue when both window manager and X have been removed. Unfortunately, my experience is all under X11.

Afaik, Raspberry Pi does “not require X11”, but it also doesn’t work with X11, so no OpenGL ES for X11 applications on RPi.

On Android the EGL uses Android specific buffers/windows. There is a window manager which controls the positions of the windows and SurfaceFlinger takes care of compositing the windows (with e.g. OpenGL ES) and showing them.

A good document of the Android stack:
https://source.android.com/devices/graphics/architecture.html

the significant issue is that running a window manager is hugely resource intensive.

if you are running a sensor, saving data and dont need a WM then dont require one.

iirc RPi do not use X11 because it is so resource intensive.

W3C have struck a similar rock in creating browser standards.

ie embedded sensors dont have to display results in realtime in a browser…

in the first very simple GPU test I tried CUDA not openGL up to 20% faster with lightdm stopped.
bear in mind that no mouse or keyboard connected and nothing being run in window, just a desktop.

X11 != Window Manager and definitely not the heavy Unity. I’m using XFCE because it’s more lightweight than Unity. But you don’t need to run any WM/desktop environment on top of X11, if you don’t need it.

Hi waldheinz,
I would expect that EGL_DEFAULT_DISPLAY defaults to a X11 based device display with the NVIDIA drivers. You may be able to use an alternative, such as Wayland, or MESA GLES but you may have issues with hardware acceleration. EGL_DEFAULT_DISPLAY is basically a device descriptor, that is, there is a device driver which gives you back a handle/structure that enables talking to the hardware. EGL_DEFAULT_DISPLAY tells EGL to ask the device driver for that handle. Because X11 is the default window system for LT4, I think that it makes sense that NVIDIA device driver returns that as the default display environment.

More info on Wayland on the Jetson: Tegra/Mainline SW/Nouveau - eLinux.org

A couple of other things from this thread. First Rasbian is now using Wayland, a modern interpretation of X11. So to say that RPii doesn’t require X11 is both correct, but doesn’t mean very much. Also, the Rasberry Pi has a much simpler graphics architecture (4 GPU cores), so one could imagine writing pretty simple OpenGL/GLES drivers for it.

Of course you can have a full OpenGL/GLES software driver implementation, and machines are now fast enough that the results are decent. Most of the smaller machines now offer some type of hardware assisted video codecs, so if you can figure out how to tap into those particular pipes for all intent and purposes the applications appears to be full blown accelerated.

Remembering that NVIDIA also makes the Shield Android Tablet using the same architecture as the Jetson, it’s not hard to imagine that stack making its way to the Jetson eventually. It’s not clear which implementation the Jedroid release is actually using.

X11 and the like solves a problem, which is multiple windows. It’s pretty easy to see why having a tight integration between the window manager with the driver is an advantage in that situation. The old school term for X11 is window manager, things like Unity were called desktop managers. That got all obfuscated over the years.

If you don’t need multiple windows and all that entails, you could just use a lightweight frame buffer and an appropriate driver for OpenGL/GLES to talk to. It’s just not clear what that might be at this point on the Jetson.

I will try that way kulve,

Thank you very much!