Imx8 XOpenDisplay(NULL) weston-vivante

This one baffles me. With a little bit of tweaking to put source all in one directory, this works fine

The app runs in an ugly terminal window instead of taking over the screen, but it runs.

The main.c file has this exact line at startup for both this working one and the x11 opengl example.

xw.dpy = XOpenDisplay(NULL);

Run the x11 this way.

docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=fred \
             --net=host --cap-add CAP_SYS_TTY_CONFIG \
             -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
             --device-cgroup-rule='c 4:* rmw' \
             --device-cgroup-rule='c 13:* rmw' \
             --device-cgroup-rule='c 199:* rmw' \
             --device-cgroup-rule='c 226:* rmw' \
             seasonedgeek/nuklear-x11-demo --developer weston-launch \
             --tty=/dev/tty7 --user=torizon

docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=ethyl --user=torizon \
             -v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore \
             -v /tmp:/tmp \
             --device-cgroup-rule='c 199:* rmw' \
             --device-cgroup-rule='c 226:* rmw' \
             seasonedgeek/nuklear-x11-demo launch-x11-demo

x11 opengl demo from here. Slightly tweaked so it would look for all source in same directory.

Built and run same way.

docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=fred \
             --net=host --cap-add CAP_SYS_TTY_CONFIG \
             -v /dev:/dev -v /tmp:/tmp -v /run/udev/:/run/udev/ \
             --device-cgroup-rule='c 4:* rmw' \
             --device-cgroup-rule='c 13:* rmw' \
             --device-cgroup-rule='c 199:* rmw' \
             --device-cgroup-rule='c 226:* rmw' \
             seasonedgeek/nuklear-x11-opengl-demo --developer weston-launch \
             --tty=/dev/tty7 --user=torizon			

docker run -e ACCEPT_FSL_EULA=1 -d --rm --name=ethyl --user=torizon \
             -v /dev/dri:/dev/dri -v /dev/galcore:/dev/galcore \
             -v /tmp:/tmp \
             --device-cgroup-rule='c 199:* rmw' \
             --device-cgroup-rule='c 226:* rmw' \
             seasonedgeek/nuklear-x11-opengl-demo launch-x11-opengl-demo

Fails to open display.

    win.dpy = XOpenDisplay(NULL);
    if (!win.dpy) die("Failed to open X display\n");
        /* check glx version */
        int glx_major, glx_minor;
        if (!glXQueryVersion(win.dpy, &glx_major, &glx_minor))
            die("[X11]: Error: Failed to query OpenGL version\n");
        if ((glx_major == 1 && glx_minor < 3) || (glx_major < 1))
            die("[X11]: Error: Invalid GLX version!\n");

It doesn’t even get to the checks below that. I’m building within the same VM where I build the working one.

Everything is looking for aarch64 as it should be.

root@verdin-imx8mp-06848973:/home/torizon# ldd demo (0x0000ffff93af1000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff93911000) => /lib/aarch64-linux-gnu/ (0x0000ffff93866000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff937ca000) => /lib/aarch64-linux-gnu/ (0x0000ffff93654000)
	/lib/ (0x0000ffff93ac1000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff9361c000) => /lib/aarch64-linux-gnu/ (0x0000ffff93608000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff93445000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff93432000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff9341c000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff933f8000) => /lib/aarch64-linux-gnu/ (0x0000ffff933c7000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff933a4000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff93390000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff9337a000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff93355000) => /usr/lib/aarch64-linux-gnu/ (0x0000ffff93339000)

Does the Weston vivante container just not like version 2 of OpenGL eventhough it loads libraries for it?

Greetings @seasoned_geek,

According to NXP documentation the Vivante GPU and driver for the i.MX8M Plus supports the following: OpenGL ES 1.1/2.0/3.0/3.1

They only seem to claim support for specifically OpenGL ES, while standard OpenGL support is a bit more of an open question.

All I can say is that while OpenGL ES is labeled as a subset of OpenGL this isn’t the whole truth. If I recall correctly ES 1.X isn’t a proper subset of any OpenGL version. ES 2.X has some similarities/shared features with OpenGL 2.1 but still isn’t a “proper” subset.

Anyways this is to say that even though NXP says the GPU supports ES 2.0 this doesn’t necessarily translate to proper OpenGL 2.0 support.

In the repo where you are getting these demos I see various other OpenGL versions as well as a single opengles example. Have you tried any of these other references?

Best Regards,


Not yet. Trying a lot of different packages looking for “path of least pain” both for development and for FDA approval.

Will try some others soon.

Let me know how your tests work out, it’s always good info to hear what UI technologies work and what don’t, for future reference.

Sorry to take so long.

You can get X11 to run on target despite all attempts to lock it down.
Helps if one edits this
sudo cat /var/sota/storage/docker-compose/docker-compose.yml

so it looks like this

    container_name: App_weston
    - c 4:0 rmw
    - c 4:7 rmw
    - c 13:* rmw
    - c 199:* rmw
    - c 226:* rmw
      ACCEPT_FSL_EULA: '1'
    image: torizon/weston-vivante@sha256:b39bd723e554a95522bd6774796d6af7cac7cf4960e1c142b9a6f45e62691f45
    network_mode: host
    - source: /tmp
      target: /tmp
      type: bind
    - source: /dev
      target: /dev
      type: bind
    - source: /run/udev
      target: /run/udev
      type: bind
version: '2.4'

Then cold boot first.

docker pull seasonedgeek/xclock-demo

docker run --rm -d -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev/galcore:/dev/galcore --device-cgroup-rule='c 199:* rmw' seasonedgeek/xclock-demo

There is also this demo container for NanoGUI

docker pull seasonedgeek/base_build_container
docker run --rm -it -v /tmp:/tmp -v /var/run/dbus:/var/run/dbus -v /dev/galcore:/dev/galcore --device-cgroup-rule='c 199:* rmw' seasonedgeek/base_build_container /bin/sh

su torizon

export DISPLAY=:0

export XDG_RUNTIME_DIR=/tmp/1000-runtime-dir


Sorry, image too big to upload

These are quite interesting results. Thank you for sharing them, this should be helpful to others as well.

Best Regards,