EGLImage created from GBM dmabuf cannot be attached to an OpenGL ES framebuffer on Jetson (GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT)

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1
  1. Hardware: NVIDIA Jetson (tested on Orin / Tegra234)
  2. OS: Linux (L4T-based distribution)
  3. GPU Driver: NVIDIA proprietary Jetson driver (GBM backend)
  4. Window system: Wayland (GBM / KMS)
  5. EGL: NVIDIA EGL
  6. OpenGL ES: 3.1 (also reproducible with ES 2.0)
  7. GBM: libgbm

Summary

On NVIDIA Jetson, an EGLImageKHR created from a GBM buffer via EGL_LINUX_DMA_BUF_EXT cannot be used as a renderable OpenGL ES framebuffer attachment.

Although:

  • GBM buffer allocation succeeds

  • dmabuf FD export succeeds

  • eglCreateImageKHR() succeeds

  • glEGLImageTargetTexture2DOES() succeeds

attaching the resulting texture to an FBO using glFramebufferTexture2D() fails with:

GL_INVALID_OPERATION
GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

This makes it impossible to implement GBM-based Wayland compositors (e.g. KWin) on Jetson, as rendering directly into dmabuf-backed buffers is required.

Expected Behavior

A GBM buffer exported as a dmabuf and imported via eglCreateImageKHR() should be usable as:

  • a GL_TEXTURE_2D, and

  • a valid color attachment of an OpenGL ES framebuffer

This is the behavior on Mesa drivers (Intel, AMD) and is required for modern Wayland compositors using GBM.

Actual Behavior

  • eglCreateImageKHR() returns a valid EGLImageKHR

  • glEGLImageTargetTexture2DOES() succeeds

  • glFramebufferTexture2D() fails with GL_INVALID_OPERATION

  • glCheckFramebufferStatus() returns GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

This happens for:

  • XR24 (XRGB8888)

  • AR24 / AB24 (ARGB8888)

  • implicit modifiers

  • linear and non-linear GBM buffers

Minimal Reproducer

The following standalone program reproduces the issue without any compositor or Wayland code.

Build

egl_gbm_fbo_fail.c.gz (1.2 KB)

gcc egl_gbm_fbo_fail.c -o egl_gbm_fbo_fail \
    -lgbm -lEGL -lGLESv2

Run

./egl_gbm_fbo_fail

Output on Jetson

FBO status: 0x8cd6

0x8cd6 = GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

Impact

This prevents:

  • GBM-based Wayland compositors (KWin, Weston GBM backend)

  • Direct rendering into scanout-capable dmabuf buffers

  • Zero-copy rendering pipelines

As a result, modern Wayland compositors cannot function correctly on Jetson without EGLStreams-specific code paths.

2

*** Please note that this reply is generated by LLM automatically ***

The issue described is related to the NVIDIA Jetson AGX Orin, where a GBM buffer exported as a dmabuf and imported via EGL cannot be used as a renderable OpenGL ES framebuffer attachment. This is a problem because modern Wayland compositors, such as KWin and Weston, rely on GBM-based rendering pipelines.

The expected behavior is that a GBM buffer exported as a dmabuf and imported via EGL should be usable as a valid color attachment of an OpenGL ES framebuffer. This is the behavior observed on Mesa drivers (Intel and AMD).

However, on the NVIDIA Jetson AGX Orin, the actual behavior is that the EGL function eglCreateImageKHR returns a valid image, but the glFramebufferTexture2D function fails with an error. This happens for various pixel formats, including XRGB8888, ARGB8888, and implicit modifiers (linear and nonlinear).

The provided minimal reproducer program demonstrates the issue without any compositor or Wayland code. The program builds and runs on the Jetson, producing an error when attempting to attach the GBM buffer to an FBO.

The impact of this issue is significant, as it prevents GBM-based Wayland compositors from functioning correctly on the Jetson. This includes KWin, Weston, and other compositors that rely on GBM-based rendering pipelines. As a result, modern Wayland compositors cannot function correctly on the Jetson without EGLStream-specific code paths.

In comparison to other platforms, the Mesa drivers (Intel and AMD) do not exhibit this issue. On these platforms, a GBM buffer exported as a dmabuf and imported via EGL can be used as a valid color attachment of an OpenGL ES framebuffer.

To resolve this issue, NVIDIA would need to update their proprietary Jetson driver to support GBM-based rendering pipelines. This would involve modifying the EGL and OpenGL ES implementations to allow GBM buffers to be used as renderable framebuffer attachments.

In summary, the issue is specific to the NVIDIA Jetson AGX Orin and affects the ability to use GBM-based rendering pipelines with modern Wayland compositors. The expected behavior is observed on Mesa drivers, but not on the NVIDIA Jetson AGX Orin. A resolution would require updates to the NVIDIA proprietary Jetson driver.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

Hi,
The supported use-case is stated in
Weston (Wayland) — NVIDIA Jetson Linux Developer Guide

Please take a look and suggest do implementation by following the guidance.

5

Thank you for the reference.

We have carefully reviewed the Jetson documentation section
“Weston (Wayland) — NVIDIA Jetson Linux Developer Guide”, including the GBM-based setup described there.

Unfortunately, this does not address the core issue reported in this thread.

Clarification of the Problem

The problem is not how to run Weston on Jetson.

The problem is that GBM + dmabuf-backed EGLImages cannot be used as renderable framebuffer attachments on Jetson, which makes it impossible to run any GBM-based Wayland compositor that renders directly into dmabuf buffers.

This is a fundamental requirement for compositors such as:

  • KWin (Plasma Wayland)

  • Sway

  • wlroots-based compositors

  • custom embedded compositors

All of these use the same pipeline:

GBM buffer
 → dmabuf
   → EGLImage
     → GL texture
       → framebuffer attachment (render target)

On Jetson, this pipeline fails with:

GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT

even though:

  • eglCreateImageKHR() succeeds

  • glEGLImageTargetTexture2DOES() succeeds

This is reproducible with a minimal standalone EGL/GBM test (no Wayland involved).

Why Weston Is Not a Viable Solution for Our Use Case

While Weston can run using NVIDIA’s documented setup, it is not sufficient for our product requirements:

  1. No live monitor configuration

    • No runtime UI for enabling/disabling outputs

    • No dynamic resolution / scaling adjustments for end users

  2. Virtual keyboard limitations

    • Styling and theming of the on-screen keyboard is not possible to the extent required

    • Integration with our UI design is not feasible

  3. Feature limitations for embedded products

    • No Plasma-style output management

    • No advanced input or accessibility customization

Therefore, Weston cannot replace a full-featured compositor such as KWin in our scenario.

Core Question

Given that:

  • GBM-based Wayland compositors rely on rendering into dmabuf-backed buffers

  • Jetson’s EGL/GBM stack does not allow dmabuf-backed EGLImages to be used as framebuffer attachments

  • Weston is not functionally sufficient for many embedded or desktop-like products

What is the recommended solution for running a full-featured Wayland compositor (e.g. KWin) on Jetson?

Specifically:

  • Is there an officially supported way to enable renderable dmabuf-backed EGLImages?

  • Is EGLStreams still the expected solution for non-Weston compositors?

  • Are there plans to align Jetson’s GBM/EGL behavior with standard Mesa implementations?

If the limitation is intentional, we would appreciate clear documentation stating that:

dmabuf-backed EGLImages on Jetson are scanout- or sampling-only and cannot be used as render targets.

This would help avoid significant engineering effort spent on unsupported configurations.

Thank you for any clarification on the intended long-term direction for Wayland compositors on Jetson.

6

Hi,

we also would like to use a wlroots based compositor (sway) and are facing the same issue. For us, weston is also not an option because we need support for live screen rotation at runtime. It would be nice if someone from Nvidia could clarify if it should be supported already or if there are any plans to support it in the near future.

@andreas.holzammer If you found a solution, I would appreciate if you could share it with us.

7

Hi,
Are you able to run the two samples in

/usr/lib/aarch64-linux-gnu/nvidia/weston-13.0/weston-simple-dmabuf-egl
/usr/lib/aarch64-linux-gnu/nvidia/weston-13.0/weston-simple-dmabuf-egldevice

Please try and see if the two apps are successfully run.

GNOME desktop Wayland support @ ORIN NX with JetPack 6.2
9

Hi, it took some time to get the results you requested. Unfortunately, weston-simple-dmabuf-egldevice does not seem to be packaged by yocto.

root:~# weston-simple-egl
has EGL_EXT_buffer_age and EGL_KHR_swap_buffers_with_damage
299 frames in 5 seconds: 59.799999 fps
301 frames in 5 seconds: 60.200001 fps
301 frames in 5 seconds: 60.200001 fps
300 frames in 5 seconds: 60.000000 fps
301 frames in 5 seconds: 60.200001 fps
301 frames in 5 seconds: 60.200001 fps
301 frames in 5 seconds: 60.200001 fps

root:~# weston-simple-dmabuf-egl
FBO creation failed

If there is anything else I can provide I am happy to prepare more insights.

10

Hi,

are there any updates to this?

12

weston_egl_info.txt (56.1 KB)

Hi all,

may I ask you to please inspect the egl_info log which I just attached here. I read this log so that weston on Jetson is clearly using EGLStream instead of zwp_linux_dmabuf_v1.
All modifiers for zwp_linux_dmabuf_v1 are discarded so egl-info ends up with using EGLStream.

Even though I managed to revert some commits in KWIN and got the wayland server to connect to create the EGLContext, any wayland client connecting to this KWIN server fails to create the EGLContext as “EGL is not available”.
As EGLStream was dropped by KWIN and is not supported in SWAY as well were are currently bound to using weston. From my understanding this is a bug in libEGL at least.

Could someone please confirm our investigation and at least give an update about a timeline if this is going to be supported in near future?

13

Hi,
We would suggest check this sample:
Making sure you're not a bot!

If your use-case is similar to it, you may refer to it for further development. If your use-case is different from the samples, it is not supported.

14

On NVIDIA’s ubuntu I followed the documentation to install and run weston :

$ mkdir /tmp/xdg
$ chmod 700 /tmp/xdg

$ sudo modprobe nvidia_drm modeset=1
$ export WESTON_TTY=1
$ sudo XDG_RUNTIME_DIR=/tmp/xdg weston --tty=“$WESTON_TTY” --idle-time=0 &

$ sudo XDG_RUNTIME_DIR=/tmp/xdg weston-simple-dmabuf-egl
Failed to initialize EGLDisplay

$ apt-cache show nvidia-jetpack | grep Version
Version: 6.2.1+b38
Version: 6.2+b77
Version: 6.1+b123

The error “Failed to initialize EGLDisplay” clearly states that this dmabuf-egl path is broken.

As posted above when running this test based on meta-tegra I get this error
”FBO creation failed”

15

Hi,
Please try weston-simple-dmabuf-egldevice and see if it works:
Weston (Wayland) — NVIDIA Jetson Linux Developer Guide

17

Hi DaneLLL,
it seems like weston-simple-dmabuf-egldevice is not deployed on Jetsons. As I cannot find this test in weston’s git repository I expect it to be closed source.
Could you please give me instructions on how to build from source or to install on Jetson running ubuntu?
After searching the internet I only found a hint to DriveOS but no installation instructions.

18

Hi,
On default system the binaries are in

/usr/lib/aarch64-linux-gnu/nvidia/weston-13.0/weston-simple-dmabuf-egldevice
/usr/bin/weston-simple-dmabuf-egldevice

Please try the binary and see if it can launched successfully.

19

Hi,

here are the results running on a Jetson AGX orin devkit.
The weston-simple-dmabuf-egldevice actually was there and can be launched and shows some cube on the screen. Still the weston-simple-dmabug-egl test fails on this devkit.

The tests I did before we running on our custom carrier board. Maybe that is why the tests were not available.

Here are the logs from the devkit:

[14:46:15.263] weston 13.0.0
[14:46:15.263] Command line: weston --idle-time=0 --debug
[14:46:15.263] OS: Linux, 5.15.148-tegra, #1 SMP PREEMPT Mon Jun 16 08:24:48 PDT 2025, aarch64
[14:46:15.263] Flight recorder: enabled
[14:46:15.263] Using config file ‘/etc/xdg/weston/weston.ini’
WARNING: debug protocol has been enabled. This is a potential denial-of-service attack vector and information leak.
[14:46:15.263] Output repaint window is 8 ms maximum.
[14:46:15.263] Loading module ‘/usr/lib/aarch64-linux-gnu/weston//drm-backend.so’
[14:46:15.265] initializing drm backend
[14:46:15.265] Trying libseat launcher…
[14:46:15.266] [libseat/libseat.c:73] Seat opened with backend ‘seatd’
[14:46:15.266] [libseat/backend/seatd.c:228] Enabling seat
[14:46:15.266] libseat: session control granted
[14:46:15.268] using /dev/dri/card1
[14:46:15.268] DRM: supports atomic modesetting
[14:46:15.268] DRM: supports GBM modifiers
[14:46:15.268] DRM: does not support async page flipping
[14:46:15.268] DRM: supports picture aspect ratio
[14:46:15.269] Loading module ‘/usr/lib/aarch64-linux-gnu/weston//gl-renderer.so’
[14:46:15.399] Using rendering device: /dev/dri/renderD129
[14:46:15.399] EGL version: 1.5
[14:46:15.399] EGL vendor: NVIDIA
[14:46:15.399] EGL client APIs: OpenGL_ES OpenGL
[14:46:15.399] EGL features:
EGL Wayland extension: yes
context priority: yes
buffer age: yes
partial update: yes
swap buffers with damage: yes
configless context: yes
surfaceless context: yes
dmabuf support: modifiers
[14:46:15.423] GL version: OpenGL ES 3.2 NVIDIA 540.4.0
[14:46:15.423] GLSL version: OpenGL ES GLSL ES 3.20
[14:46:15.423] GL vendor: NVIDIA Corporation
[14:46:15.423] GL renderer: NVIDIA Tegra Orin (nvgpu)/integrated
[14:46:15.425] GL ES 3.2 - renderer features:
read-back format: ARGB8888
glReadPixels supports y-flip: no
wl_shm 10 bpc formats: yes
wl_shm 16 bpc formats: yes
wl_shm half-float formats: no
internal R and RG formats: yes
OES_EGL_image_external: yes
[14:46:15.425] Using GL renderer
[14:46:15.435] event1 - NVIDIA Jetson AGX Orin HDA HDMI/DP,pcm=3: is tagged by udev as: Switch
[14:46:15.465] event1 - not using input device ‘/dev/input/event1’
[14:46:15.468] event2 - NVIDIA Jetson AGX Orin HDA HDMI/DP,pcm=7: is tagged by udev as: Switch
[14:46:15.497] event2 - not using input device ‘/dev/input/event2’
[14:46:15.500] event3 - NVIDIA Jetson AGX Orin HDA HDMI/DP,pcm=8: is tagged by udev as: Switch
[14:46:15.537] event3 - not using input device ‘/dev/input/event3’
[14:46:15.540] event4 - NVIDIA Jetson AGX Orin HDA HDMI/DP,pcm=9: is tagged by udev as: Switch
[14:46:15.569] event4 - not using input device ‘/dev/input/event4’
[14:46:15.571] event0 - gpio-keys: is tagged by udev as: Keyboard
[14:46:15.571] event0 - gpio-keys: device is a keyboard
[14:46:15.574] event5 - NVIDIA Jetson AGX Orin APE Headset Jack: is tagged by udev as: Keyboard Switch
[14:46:15.574] event5 - NVIDIA Jetson AGX Orin APE Headset Jack: device is a keyboard
[14:46:15.587] libinput: configuring device “gpio-keys”.
[14:46:15.587] libinput: configuring device “NVIDIA Jetson AGX Orin APE Headset Jack”.
[14:46:15.611] DRM: head ‘DP-1’ found, connector 63 is connected, EDID make ‘HPN’, model ‘HP E243i’, serial ‘6CM942078P’
Supported EOTF modes: SDR
[14:46:15.612] Registered plugin API ‘weston_drm_output_api_v1’ of size 40
[14:46:15.612] Color manager: no-op
[14:46:15.612] Output ‘DP-1’ attempts EOTF mode: SDR
[14:46:15.613] Output ‘DP-1’ using color profile: stock sRGB color profile
[14:46:15.613] Chosen EGL config details: id: 20 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 0-0 type: win|pbf vis_id: XRGB8888 (0x34325258)
[14:46:15.613] Chosen EGL config details: id: 20 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 0-0 type: win|pbf vis_id: XRGB8888 (0x34325258)
[14:46:15.614] Output DP-1 (crtc 43) video modes:
1920x1200@60.0, preferred, current, 154.0 MHz
1920x1080@60.0, 148.5 MHz
1600x1200@60.0, 162.0 MHz
1680x1050@60.0, 146.2 MHz
1600x900@60.0, 108.0 MHz
1280x1024@60.0, 108.0 MHz
1440x900@59.9, 106.5 MHz
1280x800@59.8, 83.5 MHz
1280x720@60.0, 74.2 MHz
1024x768@60.0, 65.0 MHz
800x600@60.3, 40.0 MHz
640x480@59.9, 25.2 MHz
[14:46:15.614] associating input device event0 with output DP-1 (none by udev)
[14:46:15.614] associating input device event5 with output DP-1 (none by udev)
[14:46:15.614] Output ‘DP-1’ enabled with head(s) DP-1
[14:46:15.614] Compositor capabilities:
arbitrary surface rotation: yes
screen capture uses y-flip: yes
cursor planes: yes
arbitrary resolutions: no
view mask clipping: yes
explicit sync: yes
color operations: no
presentation clock: CLOCK_MONOTONIC, id 1
presentation clock resolution: 0.000000001 s
[14:46:15.615] Loading module ‘/usr/lib/aarch64-linux-gnu/weston//desktop-shell.so’
[14:46:15.615] launching ‘/usr/lib/weston/weston-keyboard’
[14:46:15.618] launching ‘/usr/lib/weston/weston-desktop-shell’

$ sudo XDG_RUNTIME_DIR=/tmp/xdg WAYLAND_DISPLAY=wayland-0 /usr/bin/weston-simple-dmabuf-egl
Failed to initialize EGLDisplay

$ sudo XDG_RUNTIME_DIR=/tmp/xdg WAYLAND_DISPLAY=wayland-0 /usr/bin/weston-simple-dmabuf-egldevice
NVMAP_IOC_PARAMETERS failed: No such device
NVMAP_IOC_PARAMETERS failed: No such device
NVMAP_IOC_PARAMETERS failed: No such device
NVMAP_IOC_PARAMETERS failed: No such device
NVMAP_IOC_PARAMETERS failed: No such device
NVMAP_IOC_PARAMETERS failed: No such device