# Request: native Wayland support for the Linux build (NXP i.MX8/i.MX9 GPU stacks are Wayland-only)

**URL:** <https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239>\
**Category:** Custom Hardware / Electronics\
**Created:** [September 17, 2026, 3:39am UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239 "2026-09-17T03:39:31Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sholland](https://forum.realdash.net/letter_avatar_proxy/v4/letter/s/b5a626/32.png) [@sholland](https://forum.realdash.net/u/sholland)\
**Post date:** [September 17, 2026, 3:39am UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239/1 "2026-09-17T03:39:31Z")

</div>

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:

```auto
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:

```auto
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

```auto
$ 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:

```auto
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.

```auto
$ 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.

---

<div class="post-metadata">

**Author:** ![realdashdev](https://forum.realdash.net/user_avatar/forum.realdash.net/realdashdev/32/6_2.png) [@realdashdev](https://forum.realdash.net/u/realdashdev)\
**Post date:** [September 17, 2026, 5:21am UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239/2 "2026-09-17T05:21:00Z")

</div>

Thank you for the detailed report. We will put this into the feature queue.

---

<div class="post-metadata">

**Author:** ![realdashdev](https://forum.realdash.net/user_avatar/forum.realdash.net/realdashdev/32/6_2.png) [@realdashdev](https://forum.realdash.net/u/realdashdev)\
**Post date:** [September 17, 2026, 7:37am UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239/3 "2026-09-17T07:37:58Z")

</div>

realdash-mrd-wayland\_2.7.1-pr2\_arm64.deb in My RealDash downloads for testing.

---

<div class="post-metadata">

**Author:** ![sholland](https://forum.realdash.net/letter_avatar_proxy/v4/letter/s/b5a626/32.png) [@sholland](https://forum.realdash.net/u/sholland)\
**Post date:** [September 18, 2026, 6:08am UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239/4 "2026-09-18T06:08:18Z")

</div>

Thank you — that was a fast turnaround. I’ve tested the Wayland build on the  
hardware from my original report and it works correctly, including the parts I  
was least sure would carry over.

## Platform

| Item | Value |

|—|—|

| SoC | NXP i.MX95 (Cortex-A55 x6), Mali-G310 |

| Board | FRDM-IMX95-PRO |

| OS | Yocto, NXP BSP “wrynose”, kernel 6.18.20 |

| Compositor | Weston 15.0.1 |

| GPU stack | **Mesa / panthor** (open-source), not NXP’s Mali DDK |

| Launched as | `XDG_RUNTIME_DIR=/run/user/0 WAYLAND_DISPLAY=wayland-0` |

## It is genuinely Wayland-native

Confirming from the binary, since my original report’s central evidence was that  
the X11 build had no Wayland surface support at all:

```auto

wl_egl_window symbols : wayland build = 3 x11 build = 0

libX11 / libxcb refs : wayland build = 0 x11 build = 1

xdg-shell symbols : xdg_wm_base, xdg_surface, wl_compositor, wl_display_connect

```

## What works

- **Renders correctly** at 1920x720, no scaling or artifacts.
- **Touch input works.** This was my main worry, since input moves to the  
Wayland/xkbcommon path. Capacitive touch panel over USB HID, no changes needed.
- **Serial and network connections work** — including a custom RealDash CAN connection over TCP, and a `/dev/ttyACM` serial link driving the display’s  
backlight.
- **GPU-accelerated** : the process holds both DRM render nodes  
(`renderD128` + `renderD129`) on Mesa/panthor.
- **All libraries resolve** (`ldd` clean) against a stock Yocto image — the only  
additions needed beyond the X11 build’s dependencies were the wayland client libraries and `libxkbcommon`, both already present.

## The EGL crash from my report is gone

The X11 build segfaulted inside `eglCreateWindowSurface()` unless  
`EGL_PLATFORM=x11` was forced, on both the Mali blob and Mesa. **The Wayland build needs no `EGL_PLATFORM` override at all** and starts cleanly.

## Performance: essentially unchanged, and that’s fine

Measured with `top` over a real sampling interval (not `ps`, whose `%CPU` is a  
lifetime average and misleading when comparing a long-running process against a freshly started one):

| | X11 build via XWayland | Wayland build |

|—|—|—|

| realdash | 52.9% | 53.0% |

| weston | 8.4% | 6.9% |

| **total** | **61.3%** | **59.9%** |

So RealDash itself is identical and the compositor saves a little by not driving  
XWayland. I want to be straightforward about this: **the Wayland build is not a  
performance win on this platform** — I had wondered if it would be, and it isn’t.  
**The value is architectural** , and on this platform it is substantial. To get  
the X11 build hardware-accelerated I had to rebuild XWayland with `glamor`  
re-enabled, because NXP deliberately strip it from their BSP  
(`OPENGL_PKGCONFIGS_REMOVE_IMXGPU = "glamor glx"`) — their Mali driver has no X11 support, so from their side it is dead weight. Without glamor, XWayland cannot offer DRI3 and every X11 client falls back to software rendering (~534% CPU here, unusable). The Wayland build **deletes that entire workaround** , along with the `EGL_PLATFORM=x11` requirement and the X11 dependency itself, on a vendor stack that is Wayland-only across the whole i.MX8/i.MX9 line. That matters for maintenance more than for frame rate: my display path no longer depends on patching the BSP against its own intent, and BSP updates stop being a risk to it.

## Two small things

1. **Version strings disagree.** The filename says `2.7.1-pr2`, but the control  
file inside says `Version: 2.7.0-2`. Harmless, but it makes the package hard  
to identify once installed, and a package manager would see it as older than  
it is.
2. **Dependency names are Debian’s** , e.g. `libbluetooth3`, `libopenal1`,  
`libvlc5`, `libwayland-client0`. On Yocto/OpenEmbedded these are named

differently (`bluez5`, `openal-soft`, `libvlc`, `wayland`), so `dpkg` refuses  
the install on dependency metadata even though every `.so` is present and  
`ldd` is clean. Not a bug — just noting that embedded distributions need  
`--force-depends`, or to repackage it as I do.

## Offer

Happy to keep testing this build, or later ones, and report back. I have serial  
console, SSH and gdb on the target, and can provide traces or figures for  
anything useful.

Thanks again for turning this around so quickly — it is the difference between  
RealDash needing a patched compositor on this hardware and simply working.

---

<div class="post-metadata">

**Author:** ![realdashdev](https://forum.realdash.net/user_avatar/forum.realdash.net/realdashdev/32/6_2.png) [@realdashdev](https://forum.realdash.net/u/realdashdev)\
**Post date:** [September 18, 2026, 11:14am UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239/5 "2026-09-18T11:14:40Z")

</div>

Alright, that was just a quick prototype with Wayland. Some issues that I’m aware of are:

- Clipboard (copy-paste) is restricted to app only
- Only keyboard/mouse/touch inputs, Wayland IME is not implemented
- Some custom window decorations probably will not work
- Window/screen size is not retained after resize

But from now on, I think we will provide x11 and Wayland versions for 64bit architectures.

---

<div class="post-metadata">

**Author:** ![sholland](https://forum.realdash.net/letter_avatar_proxy/v4/letter/s/b5a626/32.png) [@sholland](https://forum.realdash.net/u/sholland)\
**Post date:** [September 18, 2026, 1:19pm UTC](https://forum.realdash.net/t/request-native-wayland-support-for-the-linux-build-nxp-i-mx8-i-mx9-gpu-stacks-are-wayland-only/11239/6 "2026-09-18T13:19:12Z")

</div>

The Wayland prototype is already viable for my automotive/cluster use, and the one thing that might matter to other embedded users is touch-only text entry. Thanks again!