Currently, in my LVGL project, I am trying to leverage GPU resources. I was very happy to see that version 9.4.0 already supports EGL/OpenGLES. However, when I updated LVGL, I encountered an issue. The libgbm library in my current SDK build environment is version 1.15, which is quite old, and I noticed that LVGL 9.4.0 uses features from a newer libgbm library. This is very frustrating.
The libgbm library is provided by the PowerVR vendor; I do not have the source code and cannot upgrade it. I tried replacing it with the libgbm from Mesa, but when I run the program, it always reports an EGL initialization failure. I can provide the list of interfaces supported by my current libgbm library.
Is there anyone who can help me figure out how to make LVGL 9.4.0 compatible with an older libgbm library? I would greatly appreciate it.
Hi,
Congratulations on getting the project compiled with Mesa! What errors are you seeing? Can you provide the logs?
Sorry, I couldn’t compile it successfully. My libgbm doesn’t support the gbm_surface feature, which is quite frustrating. I’m currently looking for a way to resolve this.
nm -D libgbm.so
000000000001f110 B bss_end
000000000001f110 B bss_end_
000000000001f108 B __bss_start
000000000001f108 B bss_start
U calloc
U close
w __cxa_finalize
U drmFreeVersion
U drmGetVersion
U drmIoctl
U drmPrimeHandleToFD
U dup
000000000001f108 D _edata
000000000001f110 B _end
000000000001f110 B end
U __errno_location
0000000000005f00 T _fini
U free
0000000000005540 T gbm_bo_create
0000000000004360 T gbm_bo_create_with_modifiers
0000000000003df8 T gbm_bo_destroy
0000000000004180 T gbm_bo_get_bpp
00000000000040e0 T gbm_bo_get_device
0000000000004030 T gbm_bo_get_fd
00000000000041c0 T gbm_bo_get_format
00000000000040d8 T gbm_bo_get_handle
0000000000003eb0 T gbm_bo_get_handle_for_plane
0000000000004268 T gbm_bo_get_height
0000000000003fe8 T gbm_bo_get_modifier
00000000000040e8 T gbm_bo_get_offset
0000000000003f98 T gbm_bo_get_plane_count
0000000000004260 T gbm_bo_get_stride
00000000000041c8 T gbm_bo_get_stride_for_plane
0000000000003e70 T gbm_bo_get_user_data
00000000000042b0 T gbm_bo_get_width
0000000000004320 T gbm_bo_map
0000000000003e48 T gbm_bo_set_user_data
00000000000042f8 T gbm_bo_unmap
00000000000055a0 T gbm_create_device
00000000000058e8 T gbm_device_destroy
0000000000005eb0 T gbm_device_get_backend_name
0000000000005ef8 T gbm_device_get_fd
0000000000005938 T gbm_device_get_format_modifier_plane_count
0000000000005c28 T gbm_device_is_format_supported
0000000000003db8 T gbm_format_get_name
w gmon_start
0000000000003028 T _init
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
U malloc
U memset
U mmap64
U munmap
U poll
U pthread_mutex_destroy
U pthread_mutex_init
U pthread_mutex_lock
U pthread_mutex_unlock
U PVRSRVConnect
U PVRSRVCreateDeviceMemContext
U PVRSRVDebugPrintf
U PVRSRVDisconnect
U PVRSRVDMABufAllocDevMem
U PVRSRVDMABufReleaseDevMem
U PVRSRVFindHeapByName
U PVRSRVGetErrorString
U PVRSRVGetHeapLog2PageSize
U PVRSRVReleaseDeviceMemContext
U realloc
U strcmp
I was asking about what error you encountered here
Since gbm is statically linked you can use mesa’s implementation instead of the libgbm version provided by default by your sdk so I would try to make that work first
I encountered the same issue as you — I’m also using the Mesa version, and it reports the same error.
display = egl_get_display.fn(EGL_DEFAULT_DISPLAY);
I tried initializing it using the method above. It didn’t report an initialization failure, but it did show ‘Invalid format requested’.
I’m sorry. I’m not encountering any issues, I’m wondering what the logs of the application look like when you run with mesa’s libgbm version
I’m sorry, I didn’t keep the logs. I’ve already stopped using Mesa because the libgbm library I have comes from the GPU vendor, who has modified it — as you can tell from the library’s exported symbols, it’s tailored for their GPU. Now I’d like to work directly with the LVGL source code to remove the gbm_surface dependency and rework it following the approach used in kmscube. I managed to compile kmscube successfully and it runs fine on my device, but adapting the LVGL source code this way is quite challenging for me right now, and I don’t have a solid plan yet.
kmscube.c (31.6 KB)
Thank you, I understand now that the problem is that you have modified version of GBM. Unfortunately, we’re not able to modify or adapt the LVGL source code to target a specific GPU or vendor-modified library. LVGL is designed to be hardware-agnostic, and adapting it to a custom GBM or DRM implementation would go against that principle.
The way I see it, trying to modify LVGL’s source code to work with your specific board is not the best approach here, it would make more sense to create a specific driver for your application - outside of LVGL’s source code - so that it works with your own GBM version. If you’re interested in getting dedicated support to do this, please feel free to contact us, we’d be happy to discuss how we could assist
Thank you for your reply. I was wondering — what if I just remove the gbm_surface feature, similar to how it’s implemented in kmscube.c
In that case it would need to be replaced by gbm_bo objects
Do you have any suggestions for how I could modify it? Also, have you encountered this kind of issue before? My project was upgraded from version 9.3.0 to 9.4.0. I use LV_EVENT_DRAW_TASK_ADDED to draw circles in some cells of a table widget, but it causes a segmentation fault. When I roll back to version 9.3.0, it runs normally. I’ve attached the GDB debug output, and after comparing the code between the two versions, it seems that there weren’t any major changes in the area where the issue occurs.
bt
#0 0x0000ffff863ba6b4 in circ_calc_aa4 ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#1 0x0000ffff863b75b0 in lv_draw_sw_mask_radius_init ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#2 0x0000ffff863ae7ac in draw_border_complex ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#3 0x0000ffff863ae6cc in lv_draw_sw_border ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#4 0x0000ffff863ad5d0 in execute_drawing ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#5 0x0000ffff863ad498 in render_thread_cb ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#6 0x0000ffff863f40cc in generic_callback ()
from /home/gu/work/git/BAU_BA62C/masterptg1.4/out/images_d9_ref/build_object/ap1_d9_ref_buildroot/build/lvgl_app-1.0.0/lvgl-v9.4.0/lib/liblvgl.so.9.4.0
#7 0x0000ffff85fa4500 in ?? ()
It’s a different issue so I would suggest opening a new issue about it. Without further information I don’t know what could be the issue but one thing that struck me is that you should be using LV_EVENT_DRAW_MAIN and not LV_EVENT_DRAW_TASK_ADDED
LV_EVENT_DRAW_TASK_ADDED is written the same way in the example code I saw.
I will continue to investigate this issue. Could you guide me on how to use gbm_bo to replace gbm_surface?
I would say the kmscube example you provided should be a pretty good starting point, you would need to update both drm driver to allocate these buffers and the egl code to use eglCreateImageKHR instead of creating a window surface with eglCreateWindowSurface