RealDash 2.7.0 installs and runs correctly on an NXP i.MX95 (aarch64, Mali-G310), but only with software rendering, because the vendor’s GPU driver has no X11 support at all. Since RealDash’s Linux build is an X11 client, it cannot use the GPU on this platform.
Software rendering works and the app is otherwise completely functional — it just costs ~557% CPU across the six Cortex-A55 cores at 1920x720, which isn’t viable in a vehicle.
Would you consider a native Wayland build? This isn’t specific to my board:
NXP ship Wayland-only GPU userspace across the entire i.MX8/i.MX9 line, and other ARM SoC vendors are moving the same way.
Platform
| Item | Value |
|---|---|
| SoC | NXP i.MX95 (Cortex-A55 x6), Mali-G310 GPU |
| Board | FRDM-IMX95-PRO |
| OS | Yocto (NXP BSP, “wrynose” release), kernel 6.18.20 |
| Distro backend | fsl-imx-xwayland (Weston compositor + XWayland) |
| Package | realdash-mrd_2.7.0-1_arm64.deb |
What works
The .deb installs cleanly and all libraries resolve (ldd /usr/bin/realdash →
no missing libraries). With software rendering forced:
LIBGL_ALWAYS_SOFTWARE=1 EGL_PLATFORM=x11 DISPLAY=:0 /usr/bin/realdash
RealDash starts, initialises fully and displays correctly — the logs show the
engine coming up normally (ValueInput.cpp ... Enginebit: Cranking / Idle / Overrun / ...). So the application itself is completely happy on this hardware.
The problem
With the vendor’s hardware EGL driver, RealDash segfaults at startup. gdb
backtrace:
Thread 1 "realdash" received signal SIGSEGV, Segmentation fault.
#0 0x0000fffff33db540 in ?? () from /usr/lib/mali-imx/libmali.so
#1 0x0000fffff33db02c in ?? () from /usr/lib/mali-imx/libmali.so
#2 0x0000fffff33cefc0 in ?? () from /usr/lib/mali-imx/libmali.so
#3 0x0000fffff33c9010 in ?? () from /usr/lib/mali-imx/libmali.so
#4 0x0000fffff7c22d84 in eglCreateWindowSurface () from /usr/lib/mali-imx/libEGL.so.1
#5 0x0000aaaaaadb4c10 in ?? () <- RealDash
RealDash passes an X11 Window to eglCreateWindowSurface(), and the driver dereferences it as a wl_surface.
Root cause — the vendor driver contains no X11 code whatsoever
$ ldd /usr/lib/mali-imx/libmali.so | grep -iE "X11|xcb|wayland"
libwayland-client.so.0 => /usr/lib/libwayland-client.so.0
libwayland-server.so.0 => /usr/lib/libwayland-server.so.0
$ strings /usr/lib/mali-imx/libmali.so | grep -c XOpenDisplay 0
$ strings /usr/lib/mali-imx/libmali.so | grep wl_display | head -3
wl_display_get_error
wl_display_dispatch_queue_pending
wl_display_flush
It links only the Wayland client/server libraries, exports Wayland symbols and contains zero X11 symbols. So this isn’t a configuration problem — there is no setting, environment variable or package that will make it render into an X11 window.
Nor is there a distro option that helps. NXP’s BSP offers only:
fsl-imx-fb fsl-imx-wayland fsl-imx-xwayland (+ -minimal variants)
There is no fsl-imx-x11. NXP dropped native X11 support for the i.MX8/i.MX9
generation, so X11 applications can only reach the display through XWayland — and hardware EGL doesn’t work through that path with this driver.
I checked whether the shipped build already supports Wayland — it doesn’t
For completeness, in case a runtime backend switch already exists: the released arm64 binary is X11-only.
$ ldd /usr/bin/realdash | grep -iE "X11|xcb|wayland"
libX11.so.6, libxcb.so.1, libX11-xcb.so.1,
libxcb-randr/xfixes/shm/dri3/present/sync ...
libwayland-client.so.0 <- transitive, via Mesa libEGL
$ strings /usr/bin/realdash | grep -c wl_egl_window
0
libwayland-client is only pulled in indirectly by Mesa’s libEGL. There is no
wl_egl_window symbol, so the binary cannot create a Wayland EGL surface, and there are no platform/backend selection strings. The four Linux packages
(amd64/arm64/armhf/i386) differ by CPU architecture only.
The request
A Wayland-native build of RealDash for Linux ARM64 — i.e. using
EGL_PLATFORM=wayland with wl_egl_window_create() instead of an X11 Window, whether as a separate build or a runtime backend selection.
This would give hardware-accelerated RealDash on:
- the entire NXP i.MX8 / i.MX9 family (i.MX8M Plus, i.MX93, i.MX95 …), which is a very common choice for automotive and instrument-cluster work
- other ARM SoC platforms shipping Wayland-only GPU userspace, which is
increasingly the norm
I appreciate X11 has been the pragmatic choice historically, but on current
embedded ARM BSPs it’s becoming the blocker rather than the safe default.
Offer
I’m happy to test any experimental Wayland build on real i.MX95 hardware and report back with logs, traces and performance figures. I have serial console, SSH and gdb on the target, so I can provide whatever detail is useful.
Thanks for RealDash — it’s genuinely the right fit for this project, and this is the only thing standing between it and full hardware acceleration on this platform.