Open kisvegabor opened 8 months ago
cc @tore-espressif @espzav, @MouriNaruto
@cristian-stoica
Problem to solve
Continue #5624 As it was shown in #5614 and #5391 adding vendor/Platform specific default configs can be useful.
Success criteria
- The solution should be backward compatible.
- The same
lv_conf.h
should work on PC and an embedded device too.- Kconfig needs to be supported.
Solution outline
Keep
lv_conf.h
but move the followings tolv_platform_conf.h
:
if there is Kconfig there is no lv_conf.h
This assumption is causing the issue as I mentioned here
LV_CONF_SKIP
in Kconfig: I think we can set it toy
unconditionally as we can assume that if there is Kconfig there is nolv_conf.h
I think the solution should be slightly different.
CONFIG_LV_CONFIG=LV_CONFIG_DEFAULT
CONFIG_LV_CONFIG=LV_CONFIG_CUSTOM
CONFIG_LV_CONFIG=LV_CONFIG_WINDOWS
@sukesh-ak I think it's a different issue, but we can handle with this one.
In your suggestion people still need to go to menuconfig
to set CONFIG_LV_CONFIG
, right?
@sukesh-ak I think it's a different issue, but we can handle with this one.
In your suggestion people still need to go to
menuconfig
to setCONFIG_LV_CONFIG
, right?
Nope, we don't need to goto menuconfig
since we can set in the sdkconfig.default
https://github.com/sukesh-ak/BSP-IDF5-ESP_LCD-LVGL9/blob/main/sdkconfig.defaults
Oh, I see. If it's ok to edit sdkconfig.default
by hand, it's ok for me too. :slightly_smiling_face:
I've just realized that my comment from yesterday wasn't sent... :cry:
So, I believe there are 3 different configs:
#define LV_USE_STDLIB_MALLOC LV_STDLIB_BUILTIN
#define LV_USE_STDLIB_STRING LV_STDLIB_BUILTIN
#define LV_USE_STDLIB_SPRINTF LV_STDLIB_BUILTIN
#define LV_STDINT_INCLUDE <stdint.h>
#define LV_STDDEF_INCLUDE <stddef.h>
#define LV_STDBOOL_INCLUDE <stdbool.h>
#define LV_INTTYPES_INCLUDE <inttypes.h>
#define LV_LIMITS_INCLUDE <limits.h>
#define LV_STDARG_INCLUDE <stdarg.h>
#define LV_BIG_ENDIAN_SYSTEM 0
#define LV_ATTRIBUTE_TICK_INC
#define LV_ATTRIBUTE_TIMER_HANDLER
#define LV_ATTRIBUTE_FLUSH_READY
#define LV_ATTRIBUTE_MEM_ALIGN_SIZE 1
#define LV_ATTRIBUTE_MEM_ALIGN
#define LV_ATTRIBUTE_LARGE_CONST
#define LV_ATTRIBUTE_LARGE_RAM_ARRAY
#define LV_ATTRIBUTE_FAST_MEM
#define LV_EXPORT_CONST_INT(int_value) struct _silence_gcc_warning /**< The default value just prevents GCC warning */
#define LV_ATTRIBUTE_EXTERN_DATA
LV_DRAW_BUF_STRIDE_ALIGN
based on the selected GPU#define LV_DRAW_<GPU/ASM/etc>
#define LV_USE_<SDL/ILI9341/etc>
In light of that, we can have an lv_env_conf.h
file where "1. Framework config" can be adjusted and the normal lv_conf.h
could have:
#include "lv_env_conf_internal.h"
And in lv_env_conf_internal.h
we can have
#ifdef ESP
#include "lv_env_conf_esp.h"
#endif
#ifdef MICROPYTHON
#include "lv_env_conf_mp.h"
#endif
#ifdef UEFI
#include "lv_env_conf_uefi.h"
#endif
#ifdef ZEPHYR
#include "lv_env_conf_zephyr.h"
#endif
#ifdef LV_ENV_CONF_CUSTOM_PATH
#include LV_ENV_CONF_CUSTOM_PATH
#endif
What do yu think? @tore-espressif @espzav @faxe1008
cc @MouriNaruto
@kisvegabor Historically, our SDK team used to (and do) add a line #include "display_support.h" at the top of lv_conf.h.
That header lets the user choose a display and sets macros for LVGL that are otherwise irrelevant for an application writer: e.g.
#define LV_ATTRIBUTE_MEM_ALIGN PLATFORM_MEMALIGN
#define LV_DRAW_BUF_STRIDE_ALIGN PLATFORM_STRIDE_ALIGN
#define LV_COLOR_DEPTH DEMO_COLOR_DEPTH
etc.
In this new scheme which config file would be most appropriate for the SDK engineers to add their #include ?
@cristian-stoica Exactly this is the reason to split the config. Our platform needs will go to the platform config file.
Hi @kisvegabor I am glad we get back to this topic. I suggest to:
From my point of view I would say 2 should have everything from:
/*====================
COLOR SETTINGS
*====================*/
/*====================
HAL SETTINGS
*====================*/
/*=================
* OPERATING SYSTEM
*=================*/
/*========================
* RENDERING CONFIGURATION
*========================*/
/*=====================
* COMPILER SETTINGS
*====================*/
@nicusorcitu
LV_COLOR_DEPTH
depends on the actual hardware, so it's not something that can be set the NXP once, and the user shouldn't touch aynmore. lv_platform_config.h
lv_platform_config.h
What is the purpose of this separation? Is not to have an application config that will stay unchanged due to multiple HW setups?
All the above IMO should be platform specific. Not vendor, but platform specific. NXP, for example, will have different versions of platform specific configurations for different NXP platforms.
The key with this separation is not to separate vendors NXP, Xiaomi, Renesas, but somehow to separate the lvgl platform config to the lvgl application config.
For lv_platform_config.h
:
COLOR SETTINGS
: LV_COLOR_DEPTH
is mandatory, this will be set based on different displayHAL_SETTINGS
: LV_DEF_REFR_PERIOD
should match the display refresh rateOPERATING SYSTEM
: for LV_USE_OS
RENDERING CONFIGURATION
: for GPU draw enablement or SW draw configuration - which is also platform specific (one platform can work GPU only, others can have a dual core CPU so 2 SW draw units)COMPILER SETTINGS
: for LV_ATTRIBUTE_***
The key with this separation is not to separate vendors NXP, Xiaomi, Renesas, but somehow to separate the lvgl platform config to the lvgl application config.
I think both. See this comment.
Letting the vendors provide a "framework config" is great, as they can pre-configure a few things for their environment. However, IMO from this point the user land comes to configure
We agree that 2) should be done by the user, however I believe 1) should remain in the hands of the user as well. As e.g. NXP can't decide whether the user wan't to use PXP during rendering or only for flushing. The vendor can't disable the unused LV_DRAW_SW_SUPPORT_RGB888/RGB565/etc
options either.
In order to make lv_conf.h
platform independent the user can do this:
#define SIMULATOR 1
#define LV_USE_ASSERT_OBJ SIMULATOR
#define LV_DRAW_USE_PXP (!SIMULATOR)
We can even promote this practice in lv_conf_template.h
.
What do you think?
I still don't know how it applies to Kconfig.
Are you suggesting 3 config files?
Nope, I mean 2 files:
lv_platform_config
LV_ATTRIBUTE_*
LV_USE_STD*_
LV_USE_OS
lv_conf.h
#define SIMULATOR
here)We need some feedback on this issue.
Now we mark this as "Abandoned" because there was no activity here for 14 days.
Remove the "Stale" label or comment else this will be closed in 7 days.
Problem to solve
Continue https://github.com/lvgl/lvgl/issues/5624 As it was shown in https://github.com/lvgl/lvgl/pull/5614 and https://github.com/lvgl/lvgl/issues/5391 adding vendor/Platform specific default configs can be useful.
Success criteria
lv_conf.h
should work on PC and an embedded device too.Solution outline
Keep
lv_conf.h
but move the followings tolv_platform_conf.h
:LV_CONF_SKIP
in Kconfig: I think we can set it toy
unconditionally as we can assume that if there is Kconfig there is nolv_conf.h
LV_USE_STDLIB_*
: Some might want to use Clib or custom STDLIB implementationsLV_USE_DRAW_SW_ASM
settingsLV_USE_OS
LV_DRAW_BUF_STRIDE_ALIGN
to match the requirements of GPUs by defaultLV_USE_DRAW_<GPU>
: enable automaticallyLV_ATTRIBUTE_*
sLV_USE_SDL
lodepng
vslibpng
lv_conf.h
should start with includinglv_platform_conf.h
. If it's not included LVGL will fall back to the default values inlv_conf_internal.h
.lv_conf_internal.h
should be generated fromlv_conf_template.h
andlv_platform_conf.h
.Rabbit holes
lv_platform_conf.h
file?Testing
Testing on ESP/PC should cover most of the cases.
Teaching
Update the docs and example projects
Considerations
No response