Hi there,
Awesome, and Yes there is. So I guess 2 options according to Jim 
The Long and Short of it, Try a newer BSP the current one must have some hardcoded hooks in it for LVGL 8.
I asked about the difference:
" The LVGL 8 vs. 9 Driver Conflict
In the Seeed SenseCAP Indicator template, the display and touch peripheral initializations are usually tightly coupled with LVGL inside the project’s components folder (often something like indicator_display.c or similar).
- The Structural Shift: LVGL 9 completely deprecated the old
lv_disp_drv_t (display driver) and lv_indev_drv_t (input device) structures used in version 8, replacing them with a simplified lv_display_t and lv_indev_t API.
- The Crash Trigger: The Seeed template likely has FreeRTOS background tasks or interrupts still trying to fire standard LVGL 8 flush callbacks or poll the touch screen using the old structures. When it tries to push that data into the newly initialized LVGL 9 core, it immediately dereferences a null pointer or hits a race condition and panics on startup.
How to Strip LVGL out of the Template
To answer their question directly: Yes, they can strip it out, but it requires a bit of surgical commenting rather than just deleting folders.
They need to decouple the native ESP-IDF hardware drivers from the GUI layer:
- Keep the
esp_lcd Initialization: The template uses ESP-IDF’s native esp_lcd driver to turn on the RGB panel, initialize the ST7701S (or similar) display IC, and allocate the frame buffers. They must keep this code so the screen actually powers on.
- Keep the I2C Touch Initialization: They need to keep the code that initializes the I2C bus and the touch controller IC.
- Sever the LVGL Bindings: They need to find the specific functions that bind these hardware peripherals to LVGL (usually functions containing
lv_disp_drv_register or lv_indev_drv_register) and comment them out entirely, along with the LVGL flush_cb and read_cb callbacks.
Once they sever those bindings, the ESP32 will initialize the hardware frame buffers natively without forcing LVGL to handle them, stopping the startup crash.
"
I know on the Arduino side & LVGL 9 the Newest BSP works and the older ones do in some situations, but generally I find LVGL 8 works ok for most cases with pretty much all of them. 
HTH
GL 
PJ 
So , I went back around and asked for any built-ins you could try. I was surprised 
The absolute easiest way for them to test their new LVGL 9 stack without downloading a completely new repository is to use the built-in LVGL Demos.
Because LVGL packages its own official demo apps right into the library, they can use this to immediately verify if their display buffers and touch controllers are correctly bonded to the new v9 API, completely separate from the old SenseCAP UI code.
Here is what you can tell b.ibo to do to fire up the classic Widgets demo:
How to run the built-in LVGL 9 Demo:
1. Enable the Demo in Config Open the project’s lv_conf.h file, scroll down to the Demos section, and enable the widgets demo by changing the 0 to a 1:
#define LV_USE_DEMO_WIDGETS 1
(They can also enable LV_USE_DEMO_BENCHMARK 1 if they want to stress-test their PSRAM configuration later).
2. Include the Demo Header At the top of their main file (wherever they are calling lv_init()), add the include path for the demos:
#include "demos/lv_demos.h"
3. Call the Demo Function After lv_init() is called and the esp_lcd hardware / touch drivers are fully initialized and registered to LVGL, simply call the demo function before entering the main FreeRTOS lv_timer_handler() loop:
lv_demo_widgets();
If the screen boots up and they can interact with the buttons and sliders, they know their ESP-IDF v6 and LVGL 9 foundation is rock solid. From there, they can start porting the actual SenseCAP indicator UI code over to the new v9 formatting!
I didn’t know, but now WE do