I ran a few experiments with LVGL on Linux and documented here:
Looks promising!
3 Likes
Hi,
It’s great, thanks for sharing!
If I understood correctly your only issue was that it wasn’t obvious how to get started, right?
Correct. I come from a Linux background where we are used to command line flows, so was curious if I could build LVGL on Linux without an IDE. This is important when integrating into build systems like Yocto. Glad to see it is fairly easy to do. Not sure if it makes sense to add docs on this? I should probably try an IDE simulator flow to get a sense for how that works.
1 Like
Actually we have some related docs, like:
and you could see the we have some ready to use project but we should point the users more directly to the right direction, to easily see something using LVGL.
1 Like
I tried the fb port on a i.MX8 system, and am getting the following:
Any ideas why the image does not look scaled properly?
I think the LCD is 800x480:
root@imx8qxp-var-som:~# fbset
mode "800x480-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 800 480 800 480 16
timings 0 0 0 0 0 0 0
accel true
rgba 5/11,6/5,5/0,0/0
endmode
I believe the app is configured for 800x480 by default:
/*Initialize and register a display driver*/
static lv_disp_drv_t disp_drv;
lv_disp_drv_init(&disp_drv);
disp_drv.draw_buf = &disp_buf;
disp_drv.flush_cb = fbdev_flush;
disp_drv.hor_res = 800;
disp_drv.ver_res = 480;
lv_disp_drv_register(&disp_drv);
Great job on your build setup – it compiled without a lot of trouble under Yocto:
Looks like a color format mismatch. Probably LVGL is configured to 32 bit (LV_COLOR_DEPTH 32 in lv_conf.h) but display has 16 bit color depth.
Yes, right on, the following change fixes it:
[cbrake@ceres git]$ git diff
diff --git a/lv_conf.h b/lv_conf.h
index 6bfe50f..e83dc55 100644
--- a/lv_conf.h
+++ b/lv_conf.h
@@ -24,7 +24,7 @@
*====================*/
/*Color depth: 1 (1 byte per pixel), 8 (RGB332), 16 (RGB565), 32 (ARGB8888)*/
-#define LV_COLOR_DEPTH 32
+#define LV_COLOR_DEPTH 16
/*Swap the 2 bytes of RGB565 color. Useful if the display has an 8-bit interface (e.g. SPI)*/
#define LV_COLOR_16_SWAP 0
Working on touchscreen next …
I did try the lvgl pc version on this device (the same code that runs on my Linux workstation just fine) running Weston/Wayland, and the app started up with no errors, but nothing displayed on the screen.
I suggest enabling Logging — LVGL documentation to see what might have happened.
Hi @kisvegabor /@cbrake ,
Thanks for the post on build setup. It helped me lot in using LVGL with my board.
I am using a sama5d3xek board which has a LCD resolution of 480X272.
root@sama5d3xek:/usr/bin# fbset
mode “480x272-0”
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 480 272 480 272 24
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode
Now i have issue on color format. I tried to configure to 32bit and 16bit(LV_COLOR_DEPTH 32 and LV_COLOR_DEPTH 16 in lv_conf.h) but looks like the display has something different than these two values.
From the above fbset command results, it shows 24
geometry 480 272 480 272 24
Is this the colour depth to be set?
If Yes, then the configuration file lv_conf.h doesn’t support this value.
Please help us to know how can we figure out this issue.
Below is the snap shot of display how it looks when configured to 32 bit
And when configured to 16 bit, I see 2 such displays
And when configured to 8 bit, I see 3 such displays
Please help us on how to fix this issue. Or is there something I am missing out?
Hello, see the datasheet for that sama5d3xek board:
Section 6.1.3 says the following:
Graphics and text can be displayed on the dot matrix panel with up to 16 million colors by supplying 24-bit data signals
(8bit x RGB by default) or 16-bit data signals (5+6+5bit x RGB in option). This allows the user to develop graphical user
interfaces for a wide variety of applications.
The display has 3x8 pins for the colors connected, but you can choose to use 16 bits color.
It seems to me like the problem here above has more to do with timing of your display than the setting with LVGL. For 24-bits color, you need to use 32 bit color depth. The last 8 bits of 32bit color are used for alpha, which this screen will not use.
Hi @kisvegabor,
I see that our display has 24 bit color depth from the fbset command
root@sama5d3xek:/usr/bin# fbset
mode “480x272-0”
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 480 272 480 272 24
timings 0 0 0 0 0 0 0
accel true
rgba 8/16,8/8,8/0,0/0
endmode
Also from the docs, i see that supported display types are
Can you help us to know if the display we are using is supported or not?
If it supports, help us to know if we are missing out something.
Thanks.
Hi,
LVGL v8 can render in 16 bit (RGB565) and 32 bit (ARGB8888) format, so 24 bit (RGB888) is not directly supported. The docs is really misleading in this regard. I’ve just updated it.
What you can do is rendering in 32 bit LV_COLOR_DEPTH 32 and convert it to 24 bit by dropping the 3rd byte from each pixel in the flush_cb.
I also know that it’s not ideal, but in v9 (will be released this year Q4) RGB888 rendering will be supported.
Hi,
I am trying to build the lv_port_linux_frame_buffer example in my yocto project. And in this example its mentioned that “LVGL configured to work with /dev/fb0 on Linux”. But when i run the binary from image, it shows the below output.
Looks like it is using DRM.
Also in bitbake file, it is converting to drm instead of fbdev.
lvgl-demo-fb_8.3.0-bb.txt (2.6 KB)
But when i try to cross compile the same example for my controller by enabling “USE_DRM” macro in lv_drv_conf.h file and converting fbdev functions to drm functions in main.c, i end up in getting lots of errors.
Kindly let us know if we can use DRM [“/dev/dri/card0”] instead of fbdev.
I am asking this because, we are able to build the yocto image and see the display as expected.
We want the same to work when the example code is cross compiled.
I don’t know much about Yocto, but I can tell that the colors look odd because the value of LV_COLOR_16_SWAP needs to be toggled in lv_conf.h
Hi,
Will toggle the LV_COLOR_16_SWAP macro and check for the color.
But my concern is to use DRM instead of FBDEV.
Can i get help on this? I have enabled the USE_DRM macro in lv_drv_conf.h file
Also changed the fbdev functions to drm functions.
main.c (2.5 KB)
Cross compiler used: arm-poky-linux-gnueabi-gcc
When cross compiled the lv_port_linux_frame_buffer example with above main.c file, getting errors on drm calls.
Please help in resolving these errors.
It is also mentioned in the below post. But no response in the forum for this query.
- Will i be able to use DRM instead of FBDEV?
- If yes, why are we getting errors when USE_DRM is enabled?
Thanks.
Why have you commented out #include "lv_drivers/display/drm.h" in main.c? It’s required to “see” drm_flush.
Hi,
But when i uncomment “lv_driver/display/drm.h” i get lot of undefined reference errors as below:
The below text file has complete error log.
undefined_ref_err.txt (9.0 KB)
Thanks.
It seems the drm library is not linked. Have you added the -Ldrm linker flag (or an equivalent)?
Hi,
Yes, after linking the drm library, got rid of errors and generated binary file.
But now touch is not working, which was working before.
Currently following macros are enabled in my lv_drv_conf.h file.
USE_DRM
USE_WAYLAND
USE_EVEDEV
EVDEV_CALIBRATE
And following macros in my lv_conf.h file.
LV_COLOR_DEPTH 32
LV_USE_DEMO_WIDGETS 1
[Note: Rest of the macros are as default]
I am not able to see touch functionality with above macros enabled.
What are the macros to be enabled in lv_drv_conf.h file for touch to work?
Is there any configuration to be done apart from enabling the macros?
Thanks.
Great news!
Do you set the EVDEV_NAME “/dev/input/event0” correctly in lv_drv_conf.h?