2025-03-10 3:53 AM
Hello,
I was able to make the SDL2 library works with KMSDRM with kernel 5.15 Kirkston but with kernel 6.6 Scarthgap it doesn't work. I also configured the kmsdrm to work in the .bbappend file since I am using Yocto. I can see from the log.configure that the kmsdrm is on but the application which was working with 5.15 is still not able to run with 6.6. However, KMSCube is working means KMSDRM is working from the kernel point of view. The messages that I got when debug are below:
INFO: video driver in use is: (null)
INFO: video driver 0: wayland
INFO: video driver 1: KMSDRM
INFO: video driver 2: (null)
INFO: video driver 3: (null)
INFO: Failed to initialize SDL: No available video device
Even if I specify the driver to be kmdrm I see the following
INFO: video driver in use is: (null)
INFO: video driver 0: wayland
INFO: video driver 1: KMSDRM
INFO: video driver 2: (null)
INFO: video driver 3: (null)
INFO: Failed to initialize SDL: kmsdrm not available
I don't know why it is still unavailable?
from the "log.do_configure" of Yocto I can see this:
-- SDL_KMSDRM (Wanted: ON): ON
-- SDL_KMSDRM_SHARED (Wanted: ON): ON
in the build folder of "libsdl2" I can see also this in the "CMakeCache.txt" file:
//Use KMS DRM video driver
SDL_KMSDRM:BOOL=ON
//Dynamically load KMS DRM support
SDL_KMSDRM_SHARED:BOOL=ON
I edited the bbappend by adding those two lines to switch the offscreen off and to make sure that the KMSDRM is working
EXTRA_OECMAKE += " \
-DSDL_VIVANTE=OFF \
-DSDL_OPENGL=OFF \
-DSDL_KMSDRM=ON \
-DSDL_OFFSCREEN=OFF \
"
What else can I do? any suggestions?
Thanks in advance
Solved! Go to Solution.
2025-03-10 7:20 AM - edited 2025-03-10 7:22 AM
Hello @Khaled-ELGHA ,
That was the kind of logs I was looking for:
2049 openat(AT_FDCWD, "/vendor/lib/libGLESv2.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2049 openat(AT_FDCWD, "/usr/lib/libGLESv2.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
In this situation, we see that libGLESv2 is not found in the first path, but found in the second one (OK).
Not sure this is the case for libgbm:
2051 openat(AT_FDCWD, "/usr/lib/libgbm.so.1.0.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
If libgbm.so is present on your filesystem, you can try to create a symbolic link in /usr/lib/libgbm.so.1.0.0 that points on the original .so dynamic library.
This is just a on the fly test, but if it solves something, you can patch it in a better way in your Yocto image.
This is just hypothesis to open investigations path, I am not sure what is the real root cause here, as I am not a full graphic expert.
EDIT: by looking at my old LVGL yocto layer, it seems to match with what I faced:
ln -s -r ${D}/vendor/lib/libgbm.so.1.0.0 ${D}/usr/lib/libgbm.so.1.0.0
ln -s -r ${D}/vendor/lib/libGAL.so ${D}/usr/lib/libGAL.so
Kind regards,
Erwan.
2025-03-10 4:01 AM
Hello @Khaled-ELGHA ,
As a quick test, could you please try the following thing in your libsdl2_%.bbappend:
# Force gles2 and kmsdrm config for libsdl2
PACKAGECONFIG ??= " \
${PACKAGECONFIG_GL} \
${@bb.utils.filter('DISTRO_FEATURES', 'alsa pipewire pulseaudio vulkan', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland gles2', '', d)} \
${@bb.utils.contains("TUNE_FEATURES", "neon","arm-neon","",d)} \
kmsdrm \
gles2 \
"
Can you try to add manually here kmsdrm and gles2 ?
Kind regards,
Erwan.
2025-03-10 6:46 AM - edited 2025-03-10 6:50 AM
Thank you for your quick reply
I already edited the "libsdl2_2.30.1.bbappend" which located in "/home/drawengine/projects-scarthgap/layers/meta-st/meta-st-openstlinux/recipes-graphics/libsdl2" as a quick test:
Do I need to also add gles2? I will do it anyway and comeback to you, I just wanted to show you the whole bbappend file
Thanks a lot
FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "file://0001-Correction-of-bad-dlopen-for-libEGL.patch"
PACKAGECONFIG_GL = ""
PACKAGECONFIG ??= " \
${PACKAGECONFIG_GL} \
${@bb.utils.filter('DISTRO_FEATURES', 'alsa pipewire pulseaudio vulkan', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayland gles2', '', d)} \
${@bb.utils.contains("TUNE_FEATURES", "neon","arm-neon","",d)} \
kmsdrm \
"
EXTRA_OECMAKE += " \
-DSDL_VIVANTE=OFF \
-DSDL_OPENGL=OFF \
-DSDL_KMSDRM=ON \
-DSDL_OFFSCREEN=OFF \
"
PACKAGECONFIG:class-nativesdk = " \
${PACKAGECONFIG_GL} \
${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} \
kmsdrm \
"
EXTRA_OECMAKE:class-nativesdk: += " \
-DSDL_VIVANTE=OFF \
-DSDL_OPENGL=OFF \
-DSDL_KMSDRM=ON \
-DSDL_OFFSCREEN=OFF \
"
2025-03-10 6:50 AM
Hello @Khaled-ELGHA ,
In the past, I needed to make LVGL graphic framework run thanks to libSDL2 linked to our GPU, and for a reason I needed to put this gles2 to fully activate the different features.
Moreover, if you still face some trouble, do not hesitate to launch the graphic application with strace to check the different libraries access that could potentially fail.
Let me know the results of your different tests.
Kind regards,
Erwan.
2025-03-10 7:11 AM
Hello @Erwan SZYMANSKI
Thanks a lot for the clarification
in the mean time I am preparing the new image with the modifications that you suggested.
I tried with the previous image the strace tool (thanks for the idea!), but I don't know where to look into that file as it is really big and full of numbers or data, I applied this command to get the strace file:
strace -o strace_log.txt -f -s 512 ./my_application
Can you please tell me where can you see the error coming from in the file?
Thanks a lot and I will give the updates as soon as I have the new image working
2025-03-10 7:20 AM - edited 2025-03-10 7:22 AM
Hello @Khaled-ELGHA ,
That was the kind of logs I was looking for:
2049 openat(AT_FDCWD, "/vendor/lib/libGLESv2.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
2049 openat(AT_FDCWD, "/usr/lib/libGLESv2.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
In this situation, we see that libGLESv2 is not found in the first path, but found in the second one (OK).
Not sure this is the case for libgbm:
2051 openat(AT_FDCWD, "/usr/lib/libgbm.so.1.0.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
If libgbm.so is present on your filesystem, you can try to create a symbolic link in /usr/lib/libgbm.so.1.0.0 that points on the original .so dynamic library.
This is just a on the fly test, but if it solves something, you can patch it in a better way in your Yocto image.
This is just hypothesis to open investigations path, I am not sure what is the real root cause here, as I am not a full graphic expert.
EDIT: by looking at my old LVGL yocto layer, it seems to match with what I faced:
ln -s -r ${D}/vendor/lib/libgbm.so.1.0.0 ${D}/usr/lib/libgbm.so.1.0.0
ln -s -r ${D}/vendor/lib/libGAL.so ${D}/usr/lib/libGAL.so
Kind regards,
Erwan.
2025-03-10 8:19 AM
Thank you so much for the hint
I applied the first command and the applications works!
one last question: where do you suggest to put those commands? on which .bbapend?
Thank you again for the fast support I really appreciate!
2025-03-10 8:29 AM
Sounds great ! I am glad that it helped you to solve this !
Hmm, the good place would be in a recipe bbappend that has the recipe creating libgbm in dependency, to be sure that your symbolic link will not fail because of a missing file (in the case you want a correction method).
If a quick fix for your application is enough for you, you can do it in the recipe of your application directly (in the do_install for example), with the correct dependencies added.
Kind regards,
Erwan.