Purpose/state of DirectFB2-gles2 on embedded boards with GLES 2.0 GPU support

[octopus-russell]

Hi, I'm trying to determine if DirectFB2-gles2 can be used as a pure GPU accelerated OpenGL ES 2.0 backend for DirectFB2's functionality. From what I've read in other comments, there is a software Open GL ES implementation but I'm not sure why that would be - surely it should just use the MESA GLES driver?

[caramelli]

Rendering is done with a system module (for example, 2 generic system modules are provided in the DirectFB2 source tree, one based on the legacy framebuffer interface, the other based on the modern DRM/KMS interface).

If a chipset for hardware accelerated graphics operations is available on a platform, a system module can be combined with a GFX driver module to perform graphics operations in hardware.

This is typically the case on boards with a 3D GPU (which nowadays can generally be used with an EGL implementation supporting GBM): the DirectFB2-eglgbm system module combined with the DirectFB2-gles2 GFX driver provides excellent performance with the df_andi and df_dok examples.

What 3D GPU do you have on your board? With which OpenGL ES implementation? Mesa?

Note: be careful not to confuse hardware acceleration with the DirectFB2-gles2 GFX driver described above and rendering OpenGL scenes in a DirectFB surface.

[octopus-russell]

Thanks for the clarification and information. The board in question uses the Rockchip RK3568 soc - which has a OpenGL ES 3.2 compliant GPU supported by mesa drivers I believe.

[matalama80td3l]

If a chipset for hardware accelerated graphics operations is available on a platform, a system module can be combined with a GFX driver module to perform graphics operations in hardware.

I have a qcom mobile device and for some reason I can't get a useable panel driver to run mainline linux. So I can only have some graphics supports through simple framebuffer. In this case, can I get some GPU hardware acceleration if I try directfb2?

[caramelli]

Before trying to run DirectFB2 with GPU support, you need to make sure that you can render graphics correctly on the GPU via EGL and OpenGL ES.

For example, you can try yagears: yagears2 -b egl-drm -e glesv2

Note that I plan to add GPU hardware acceleration with Vulkan and Direct-to-Display (D2D WSI): DirectFB2-vulkan (empty for now)

[xlla]

the DirectFB2-eglgbm system module combined with the DirectFB2-gles2 GFX driver

hi @caramelli , in combine DirectFB2-eglgbm + DirectFB2-gles2 , how to get df_glgears work ?
It want to execute GetGL() to get IDirectFBGL.

[caramelli]

Very interesting question and a subject still rich in development!

Yes, to render OpenGL or OpenGL ES in a DirectFB application, an interface named DirectFBGL can be used and tested with df_glgears

This DirectFBGL support must be provided by a module located in lib/directfb-2.0-0/interfaces/IDirectFBGL, one of the following for now:

• DirectFBGL for PortableGL DirectFBGL-PortableGL, using the single-file OpenGL software implementation from PortableGL,
• DirectFBGL on top of the EGL interface DirectFBGL-EGL and based on an EGL implementation for DirectFB platform, i.e. eglCreateWindowSurface() with a DirectFB surface resource as native window.

Running a DirectFB application based on DirectFB2-eglgbm (system module based on the EGL interface for DRM platform) + DirectFB2-gles2 hardware acceleration, where you want to render OpenGL into a DirectFB surface, makes perfect sense.

To draw a parallel, it's like:

• Weston running with drm-backend.so module which is based on the EGL interface for DRM platform,
• launch a Wayland application with OpenGL rendering via the EGL implementation for the Wayland platform, i.e. eglCreateWindowSurface() with a Wayland wl_surface resource as native window.

or:

• Xorg running with Glamor DDX driver which is based on the EGL interface for DRM platform,
• launch an X11 application with OpenGL rendering via GLX or via the EGL implementation for the X11 platform, i.e. eglCreateWindowSurface() with an X11 Window resource as native window.

As you can see, the key is to be able to use EGL for both the DRM platform and the graphics platform above it (e.g. the Wayland compositor, the Xorg server, or DirectFB).
However, while the Mesa 3D project implementation (likely the EGL/OpenGL implementation running on your system) currently supports EGL for a Wayland wl_surface resource or for an X11 Window resource as native window, this is not the case for a DirectFB surface resource!

So the combination of DirectFB2-eglgbm + DirectFB2-gles2 AND DirectFBGL-EGL simply cannot work until the DirectFB surface resource is supported by your EGL implementation.

However, you have the possibility to test df_glgears with DirectFB2-eglgbm + DirectFB2-gles2 AND DirectFBGL-PortableGL (even though I understand that this is not your desired target).

Out of curiosity, please feel free to share some info or performance benchmarks of df_andi and df_dok working with DirectFB2-eglgbm + DirectFB2-gles2

[xlla]

hi @caramelli , thank you for your explaining, but I am get more confused now.
I'v studied to draw 3D object base on EGL + GBM + DRM, need these steps:

1. create gbm device and gbm surface.
2. got egl display, egl surface, egl content.
3. draw 3D object using glXXX functions.
4. call eglSwapBuffers and drmModePageFlip.

for combination DirectFB2-eglgbm + DirectFB2-gles2 ,
the DirectFB2-eglgbm's system already does step 1 and 2,
the DirectFB2-gles2's gfxdriver already does some job of step 3, like prepare some shader programs,
the DirectFB2-eglgbm's layer already does step 4

so, can we direct draw 3D object on some surface ?
or we can create a DirectFBGL-EGLGBM , and manage got the eglContext prepare by the DirectFB2-eglgbm's system ?
the DirectFB2 is too complicated for me, I don't know how to implement my idea.

As your kind suggestion, I'v manage to get yagears worked : yagears2 -b egl-rpiv3d -e glesv2

(I'v add a new backend, it's similar to egl-drm but have some quirk for raspberry pi's v3d.)

the init code of main() does step 1 & step 2.
the gears_engine_init and gears_engine_draw does step 3.
the tail code of while_loop does step 4.

I'v add another backend egl-directfb-gbm, it's behaviour like backend gl-directfb but does not execute dfb_win->GetGL , dfb_ctx->SwapBuffers. it's behaviour like backend egl-directfb but skip all eglXXX prepare functions.

after launch, it's failure on this statement,

prog_obj = glCreateProgram();
 

I'v build all libs and program in debug mode, so it maybe impact the performance.

benchmark for df_andi,
fps: 27.6, cpu: 98.8%

benchmark for df_dok,

Benchmarking 230x219 on 240x229 RGB16 (16bit)...
Anti-aliased Text                              3.021 secs (* 521.946 KChars/sec) [120.8%]
Anti-aliased Text (blend)                      3.022 secs (* 727.862 KChars/sec) [127.4%]
Fill Rectangle                                 3.162 secs (*1443.239 MPixel/sec) [130.0%]
Fill Rectangle (blend)                         3.155 secs (*1660.374 MPixel/sec) [134.9%]
Fill Rectangles [10]                           3.727 secs (*1878.569 MPixel/sec) [104.0%]
Fill Rectangles [10] (blend)                   4.053 secs (*2100.303 MPixel/sec) [104.4%]
Fill Triangles                                 3.027 secs (*1184.784 MPixel/sec) [149.3%]
Fill Triangles (blend)                         3.031 secs (*1172.419 MPixel/sec) [146.5%]
Draw Rectangle                                 3.038 secs (*  45.819 KRects/sec) [146.5%]
Draw Rectangle (blend)                         3.210 secs (*  43.862 KRects/sec) [143.3%]
Draw Lines [10]                                4.246 secs (*  39.566 KLines/sec) [100.2%]
Draw Lines [10] (blend)                        4.465 secs (*  43.225 KLines/sec) [100.6%]
Fill Spans                                     8.428 secs (*   6.574 MPixel/sec) [ 99.6%]
Fill Spans (blend)                             9.426 secs (*   6.946 MPixel/sec) [ 99.5%]
Fill Trapezoids [10]                           5.888 secs ( 1308.867 MPixel/sec) [102.7%]
Blit                                           3.029 secs (*2183.420 MPixel/sec) [145.3%]
Blit 180                                       3.027 secs (*2171.551 MPixel/sec) [145.0%]
Blit colorkeyed                                3.384 secs (*1808.497 MPixel/sec) [138.4%]
Blit with format conversion                    3.033 secs (*2165.594 MPixel/sec) [145.5%]
Blit with colorizing                           3.031 secs (*1778.155 MPixel/sec) [138.2%]
Blit from 32bit (blend)                        3.417 secs (*1643.621 MPixel/sec) [133.7%]
Blit from 32bit (blend) with colorizing        3.035 secs (*1794.068 MPixel/sec) [138.9%]
Blit SrcOver (premultiplied source)            3.399 secs (*1659.735 MPixel/sec) [134.8%]
Blit SrcOver (premultiply source)              3.415 secs (*1703.582 MPixel/sec) [136.3%]
Stretch Blit                                   3.361 secs (* 574.132 MPixel/sec) [137.7%]
Stretch Blit colorkeyed                        3.469 secs (* 523.324 MPixel/sec) [135.5%]

[xlla]

the absolute value of benchmark is meaningless, so here is the benchmark of system drmkms:

benchmark for df_andi,
fps: 19.8, cpu: 74.4%

benchmark for df_dok,

Benchmarking 230x219 on 240x229 RGB16 (16bit)...
Anti-aliased Text                              3.009 secs (  366.101 KChars/sec) [100.0%]
Anti-aliased Text (blend)                      3.006 secs (  292.215 KChars/sec) [100.3%]
Fill Rectangle                                 3.008 secs (  371.746 MPixel/sec) [100.0%]
Fill Rectangle (blend)                         3.102 secs (   11.366 MPixel/sec) [100.0%]
Fill Rectangles [10]                           3.060 secs (  378.598 MPixel/sec) [ 99.6%]
Fill Rectangles [10] (blend)                   4.428 secs (   11.375 MPixel/sec) [100.0%]
Fill Triangles                                 3.007 secs (  332.505 MPixel/sec) [100.0%]
Fill Triangles (blend)                         3.115 secs (   11.319 MPixel/sec) [100.3%]
Draw Rectangle                                 3.000 secs (   78.300 KRects/sec) [100.0%]
Draw Rectangle (blend)                         3.009 secs (    6.580 KRects/sec) [100.3%]
Draw Lines [10]                                3.001 secs (  329.223 KLines/sec) [100.0%]
Draw Lines [10] (blend)                        3.020 secs (   32.450 KLines/sec) [100.0%]
Fill Spans                                     3.013 secs (  377.816 MPixel/sec) [100.0%]
Fill Spans (blend)                             3.132 secs (   11.257 MPixel/sec) [100.0%]
Fill Trapezoids [10]                           3.000 secs ( 19828.990 MPixel/sec) [100.0%]
Blit                                           3.009 secs (  138.940 MPixel/sec) [100.3%]
Blit 180                                       3.073 secs (   37.699 MPixel/sec) [100.3%]
Blit colorkeyed                                3.187 secs (    9.482 MPixel/sec) [100.0%]
Blit with format conversion                    3.029 secs (   26.606 MPixel/sec) [100.3%]
Blit with colorizing                           3.340 secs (   12.064 MPixel/sec) [100.0%]
Blit from 32bit (blend)                        3.631 secs (    5.548 MPixel/sec) [100.0%]
Blit from 32bit (blend) with colorizing        3.453 secs (    7.293 MPixel/sec) [100.2%]
Blit SrcOver (premultiplied source)            3.268 secs (    7.706 MPixel/sec) [100.3%]
Blit SrcOver (premultiply source)              3.396 secs (    7.416 MPixel/sec) [100.0%]
Stretch Blit                                   3.000 secs (   36.002 MPixel/sec) [100.0%]
Stretch Blit colorkeyed                        3.006 secs (    7.010 MPixel/sec) [100.3%]

and here is the benchmark of system fbdev:

benchmark for df_andi,
fps: 548.6, cpu: 74.2%

benchmark for df_dok,

Benchmarking 230x219 on 240x229 RGB16 (16bit)...
Anti-aliased Text                              3.002 secs ( 1293.937 KChars/sec) [ 97.0%]
Anti-aliased Text (blend)                      3.002 secs (  486.875 KChars/sec) [ 96.6%]
Fill Rectangle                                 3.002 secs ( 1125.858 MPixel/sec) [ 97.0%]
Fill Rectangle (blend)                         3.039 secs (   44.751 MPixel/sec) [ 97.0%]
Fill Rectangles [10]                           3.015 secs ( 1236.278 MPixel/sec) [ 97.0%]
Fill Rectangles [10] (blend)                   3.355 secs (   45.040 MPixel/sec) [ 97.0%]
Fill Triangles                                 3.001 secs (  635.289 MPixel/sec) [ 96.6%]
Fill Triangles (blend)                         3.040 secs (   42.251 MPixel/sec) [ 96.7%]
Draw Rectangle                                 3.000 secs (   88.200 KRects/sec) [ 96.6%]
Draw Rectangle (blend)                         3.004 secs (   13.715 KRects/sec) [ 96.3%]
Draw Lines [10]                                3.001 secs (  308.897 KLines/sec) [ 96.3%]
Draw Lines [10] (blend)                        3.003 secs (   56.277 KLines/sec) [ 96.6%]
Fill Spans                                     3.000 secs (  591.008 MPixel/sec) [ 96.3%]
Fill Spans (blend)                             3.002 secs (   41.947 MPixel/sec) [ 96.6%]
Fill Trapezoids [10]                           3.000 secs ( 19694.670 MPixel/sec) [100.0%]
Blit                                           3.000 secs ( 1126.609 MPixel/sec) [ 96.6%]
Blit 180                                       3.001 secs (  592.489 MPixel/sec) [ 97.0%]
Blit colorkeyed                                3.002 secs (  453.027 MPixel/sec) [ 96.6%]
Blit with format conversion                    3.010 secs (  286.155 MPixel/sec) [ 96.6%]
Blit with colorizing                           3.001 secs (   58.745 MPixel/sec) [ 96.3%]
Blit from 32bit (blend)                        3.025 secs (  108.233 MPixel/sec) [ 96.6%]
Blit from 32bit (blend) with colorizing        3.184 secs (   25.311 MPixel/sec) [ 96.8%]
Blit SrcOver (premultiplied source)            3.052 secs (   31.357 MPixel/sec) [ 96.7%]
Blit SrcOver (premultiply source)              3.152 secs (   27.166 MPixel/sec) [ 96.8%]
Stretch Blit                                   3.000 secs (  415.543 MPixel/sec) [ 96.6%]
Stretch Blit colorkeyed                        3.000 secs (  289.923 MPixel/sec) [ 96.6%]

[caramelli]

"for combination DirectFB2-eglgbm + DirectFB2-gles2
the DirectFB2-eglgbm's system already does step 1 and 2,
the DirectFB2-gles2's gfxdriver already does some job of step 3, like prepare some shader programs,
the DirectFB2-eglgbm's layer already does step 4"

Exactly, you understood perfectly!

But it is important to keep in mind that DirectFB is designed to be used in combination with a 2D accelerator (usually a blitter for block image transfer) to perform low-level graphics operations in hardware such as: StretchBlit (with possible rotation, flip or color keying), FillRectangle, DrawLine, ...

So when you use the DirectFB2-gles2 GFX driver, you are using the 3D GPU to perform accelerated 2D rendering! (note the pos.z=0.0 in gles2_shaders.h)

As you can see, the purpose of the df_andi benchmark is to evaluate the performance of the 2D accelerated operations used by DirectFB for its low-level rendering compared to software rendering (via the drmkms or fbdev system modules).

Thanks for sharing these benchmark results, they are very interesting. In particular, notable performance improvements are achieved in Blit() operations with the GPU via the OpenGL ES 2.0 GFX driver.

Regarding 3D rendering, as I tried to explain, this must be done in your application inside a DirectFB surface (especially because we want to benefit from all the compositing possibilities of DirectFB).

This means that, similarly to eglCreateWindowSurface() with a Wayland wl_surface as native window, or eglCreateWindowSurface() with an X11 Window as native window, support for calling eglCreateWindowSurface() with a DirectFB IDirectFBSurface is required by the EGL/OpenGL implementation provided on the platform.

This support was for example available in the proprietary EGL/OpenGL implementation running on some embedded SoC/GPU vendors such as Intel CE chipsets with PowerVR GPU, ST ARM chipsets with Mali GPU, and some Broadcom ARM or MIPS chipsets with VideoCore GPU.

SwiftShaderGL-DirectFB is a CPU-based implementation that provides such EGL/OpenGL support (i.e., 3D rendering inside a DirectFB surface by calling eglCreateWindowSurface() with the targeted DirectFB surface as native window), but this is CPU-based only!

To check if an EGL/OpenGL implementation supports EGL with a DirectFB surface as native window:

yagears2 -b egl-directfb -e glesv2

Unfortunately, this is not currently the case with the EGL/OpenGL implementation of Mesa 3D that you are probably using on the Raspberry Pi platform.

Therefore, for a DirectFB application doing 3D object drawing, even if:

• DirectFB2-eglgbm system module (EGL/OpenGL from Mesa 3D with gbm_surface) + DirectFB2-gles2 accelerator
• EGL/OpenGL from Mesa 3D (by adding code to Mesa in order to enable EGL with IDirectFBSurface)

would be the most efficient in terms of composition and rendering, the easiest working solution to use is for now:

• fbdev system module
• EGL/OpenGL from SwiftShaderGL-DirectFB

This offers possibility to test df_glgears via DirectFBGL-EGL

[xlla]

I'v built SwiftShaderGL-DirectFB now, but I don't know how to integrate it with DirectFB2 to get df_glgears running via DirectFBGL-EGL .

If I force use SwiftShaderGL-DirectFB's software libGLESv2.so and libEGL.so to launch df_glgears,

for system fbdev and drmkms, they are declare the feature CSCAPS_ACCELERATION but missing step 2, so the DirectFB2-gles2's gfxdriver will failure to execute init_program() and complain the glContext not be initialized.

for system eglgbm, the software libEGL will lead Segmentation fault , it seems a recursion call DirectFBCreate() inside eglInitialize(). while export EGL_PLATFORM=surfaceless can skip this recursion, but it will failure on eglCreateWindowSurface() again.

for yagears2 using backend egl-directfb with the software libEGL/GLESv2,
yagears2 -b egl-directfb -e glesv2

will cause Segmentation fault too due to the same recursion issue.

[caramelli]

Let's take this step by step, because you may be falling into an atypical combination leading to conflicts that are not being managed.

The first step is to get it working:

yagears2 -b egl-directfb -e glesv2

when using:

• fbdev system module
• EGL/OpenGL from SwiftShaderGL-DirectFB

So, to easily focus on this use case only, I suggest you:

• clean the lib/directfb-2.0-0/systems to only keep libdirectfb_fbdev.so
• remove lib/directfb-2.0-0/gfxdrivers directory
• remove lib/directfb-2.0-0/interfaces/IDirectFBGL directory
• launch yagears2 and make sure that the EGL/OpenGL libraries from SwiftShaderGL-DirectFB are used at runtime (and not those from Mesa)

[xlla]

Ok, I have been following your instruction:

DYLD_LIBRATY_PATH=/usr/local/swift-shader-gl/lib DFBARGS="system=fbdev" TEXTURE=/home/pi/git/yagears/logo-80x66.png ./build/yagears2 -b egl-directfb -e glesv2

• remove lib/directfb-2.0-0-debug/gfxdrivers/libdirectfb_gles2.so
• remove lib/directfb-2.0-0-debug/interfaces/IDirectFBGL/libidirectfbgl_egl.so
• launch yagears2 use above command

it pass the initialization stage, and it would stuck on the first call gears->glDrawArrays() at glesv2_gears.c ,
the cpu load is 100% , after a while, about 1 minute, it prints many logs , and continue loop call gears->glDrawArrays() , the following call will execute instant , until k==15 or k==16 , it will stuck again, then throw exception and exit.

(*) DirectFB/Core: Single Application Core. (2025-05-17 13:13) [ DEBUG ]
(*) FBDev/System: Using device /dev/fb0 (default)
(*) DirectFB/Graphics: data no driver_funcs , Genefx, Software Rasterizer, 0.7, (Software Driver - DirectFB)
(*) FBDev/Screen: Default mode is 240x240 (1 modes in total)
(*) FBDev/Mode: Switched to 240x240 (virtual 240x240) at 16 bits (RGB16), pitch 480

rr> rr::getCallerBacktrace(unsigned int) [/lib/arm-linux-gnueabihf/libGLESv2.so.2:0]
rr> rr::getCallerBacktrace(unsigned int) [/lib/arm-linux-gnueabihf/libGLESv2.so.2:0]
rr> rr::getCallerBacktrace(unsigned int) [/lib/arm-linux-gnueabihf/libGLESv2.so.2:0]

...

rr> rr::getCallerBacktrace(unsigned int) [/lib/arm-linux-gnueabihf/libGLESv2.so.2:0]
rr> rr::getCallerBacktrace(unsigned int) [/lib/arm-linux-gnueabihf/libGLESv2.so.2:0]
Segmentation fault

[xlla]

This means that, similarly to eglCreateWindowSurface() with a Wayland wl_surface as native window, or eglCreateWindowSurface() with an X11 Window as native window, support for calling eglCreateWindowSurface() with a DirectFB IDirectFBSurface is required by the EGL/OpenGL implementation provided on the platform.

We can call eglCreateWindowSurface() with a GBM_surface as native window for the EGL/OpenGL implementation.

Can we create a new IDirectFBGL interface for EGLGBM , and pass GBM_surface to it, then it can do some eglContext prepare job. it can call gbm_surface_lock_front_buffer() and drmModeAddFB() to create more draw buffers.

I'v build SDL2 with kmsdrm, the testgles2 example runs fine, it draws a colorful rotating cube in screen.

[caramelli]

I experiment SwiftShaderGL-DirectFB on x86 platform, but get it working on Raspberry Pi would be nice. Thanks for testing it, hopefully we can fix the issue.

FYI, I only run SwiftShaderGL-DirectFB with LLVM-10.0.1 which is now a bit old.

You are absolutely right to mention SDL2 and its kmsdrm backend: if you only need a single window to do full-screen 3D drawing, possibly with sound and handling some input events, SDL2 based on kmsdrm is perfect for doing OpenGL ES without Wayland or X11, and with higher-level interfaces than DRM and GBM.

But for multi-application use cases, or for moving/resizing a window, compositing, rendering in a GUI (like WebGL in a web browser), the ability to pass an IDirectFBSurface to eglCreateWindowSurface() as a parameter is essential.
The SDL and DirectFB projects have similarities, but also differences and their own specificities.

Yes, it makes sense to ask whether the IDirectFBGL interface could be used to abstract access to DRM and GBM. You can take a look at:

• https://github.com/directfb2/DirectFB2/blob/directfb-1.8/systems/drmkms/DRMEGLImpl.cpp
• https://github.com/directfb2/DirectFB2/blob/directfb-1.8/tests/dfbtest_gl2.c

[xlla]

I'd like to experiment SwiftShaderGL-DirectF on Raspberry Pi and fix the issue, but I don't know how to investigate this "Segmentation fault" error, it does not provide any clue about what's wrong and where is it occur.

I'v compile SwiftShaderGL-DirectFB with LLVM-11, and my Raspberry Pi os has installed LLVM-9, LLVM-11, and LLVM-13.

I also get confused with SDL and DirectFB, because while build SDL2, it can use DirectFB as video driver, while build DirectFB, it can use SDL as backend.

I'v experimented DirectFB 1.8 before I found DirectFB2, but never succeed on system drmkms. The architecture is more complex than DirectFB2, it has a copy of egl header files, (egl.h , eglext.h etc) , it will deploy egl lib too.

        ├── lib
        │   ├── dfb-egl
        │   │   ├── libEGL.la
        │   │   ├── libEGL.so -> libEGL.so.1.0.0
        │   │   ├── libEGL.so.1 -> libEGL.so.1.0.0
        │   │   └── libEGL.so.1.0.0

at runtime, it is always complains can't libdirectfb_mesa_system.so

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.8.0 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2012-2015  DirectFB integrated media GmbH
        (c) 2001-2015  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2025-05-25 18:38) [ DEBUG ][ TRACE ]
(!) Direct/Modules: Unable to dlopen `/usr/local/lib/directfb-1.8-0/systems/libdirectfb_mesa_system.so'!
    --> /usr/local/lib/directfb-1.8-0/systems/libdirectfb_mesa_system.so: undefined symbol: eglDestroyImageKHR
(-) [ 2472: -STACK- 'dfbinfo']
  #0  0xb6b5a190 in open_module () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #1  0xb6b58a74 in direct_modules_explore_directory () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #2  0xb6e14458 in dfb_system_lookup () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #3  0xb6d76e90 in dfb_core_create () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #4  0xb6c8890c in IDirectFB_Construct () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #5  0xb6c8ab84 in DirectFBCreate () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #6  0x00011f70 in ?? () from /usr/local/bin/dfbinfo [0x10000]

and I can't pass custom settings "drmkms-device" via args,

    dfbinfo --dfb:system=drmkms,drmkms-device=2

it was parsed and saved in static map config_options at DirectFBInit(), but while libdirectfb_drmkms_system.so got load, the static map config_options was cleaned or re-initialized, then it will open "/dev/dri/card0" instead of card2.

(*) Direct/Thread: Started 'SigHandler' (3044) [CRITICAL - OTHER/0] <8388608>...

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 1.8.0 |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2012-2015  DirectFB integrated media GmbH
        (c) 2001-2015  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2025-05-25 18:38) [ DEBUG ][ TRACE ]
(!) Direct/Modules: Unable to dlopen `/usr/local/lib/directfb-1.8-0/systems/libdirectfb_mesa_system.so'!
    --> /usr/local/lib/directfb-1.8-0/systems/libdirectfb_mesa_system.so: undefined symbol: eglDestroyImageKHR
(-) [ 2472: -STACK- 'dfbinfo']
  #0  0xb6b5a190 in open_module () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #1  0xb6b58a74 in direct_modules_explore_directory () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #2  0xb6e14458 in dfb_system_lookup () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #3  0xb6d76e90 in dfb_core_create () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #4  0xb6c8890c in IDirectFB_Construct () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #5  0xb6c8ab84 in DirectFBCreate () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #6  0x00011f70 in ?? () from /usr/local/bin/dfbinfo [0x10000]

(!) [dfbinfo         7896.224] ( 2472) *** Assumption [(fb)->magic != D_MAGIC("DirectLog")] failed *** [log.c:63 in __D_log_init()]
(-) [ 2472: -STACK- 'dfbinfo']
  #0  0xb6b51370 in __D_log_init () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #1  0xb6b4e204 in __D_init_all () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #2  0xb6b5a190 in open_module () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #3  0xb6b58a74 in direct_modules_explore_directory () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #4  0xb6e14458 in dfb_system_lookup () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #5  0xb6d76e90 in dfb_core_create () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #6  0xb6c8890c in IDirectFB_Construct () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #7  0xb6c8ab84 in DirectFBCreate () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #8  0x00011f70 in ?? () from /usr/local/bin/dfbinfo [0x10000]

(!) [dfbinfo         7896.226] ( 2472) *** Assumption [(hash)->magic != D_MAGIC("DirectHash")] failed *** [hash.c:170 in direct_hash_init()]
(-) [ 2472: -STACK- 'dfbinfo']
  #0  0xb6b4cf14 in direct_hash_init () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #1  0xb6b5a670 in __D_perf_init () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #2  0xb6b4e204 in __D_init_all () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #3  0xb6b5a190 in open_module () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #4  0xb6b58a74 in direct_modules_explore_directory () from /usr/local/lib/libdirect-1.8.so.0 [0xb6af7000]
  #5  0xb6e14458 in dfb_system_lookup () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #6  0xb6d76e90 in dfb_core_create () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #7  0xb6c8890c in IDirectFB_Construct () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #8  0xb6c8ab84 in DirectFBCreate () from /usr/local/lib/libdirectfb-1.8.so.0 [0xb6bd9000]
  #9  0x00011f70 in ?? () from /usr/local/bin/dfbinfo [0x10000]

(*) Direct/Memcpy: Using libc memcpy()
(*) Direct/Thread: Started 'Fusion Dispatch' (3241) [MESSAGING - OTHER/0] <8388608>...
(*) Direct/Thread: Started 'VT Switcher' (3242) [CRITICAL - OTHER/0] <8388608>...
(*) Direct/Thread: Started 'VT Flusher' (3243) [DEFAULT - OTHER/0] <8388608>...
(*) DRMKMS/Init: using device /dev/dri/card0 (default)