docs: review and improve the sections the users meet first (#10299)

Co-authored-by: André Costa <andre_miguel_costa@hotmail.com>

docs/src/api/meta.json

@@ -0,0 +1,7 @@
+{
+  "pages": [
+    "public",
+    "private",
+    "deprecated"
+  ]
+}

docs/src/changelog/meta.json

@@ -0,0 +1,6 @@
+{
+  "pages": [
+    "CHANGELOG",
+    "migration-v10"
+  ]
+}

docs/src/getting_started/examples.mdx

@@ -5,7 +5,7 @@ description: Below are several basic examples. They include the application code
 
 Below are several basic examples.  They include the application code that produces
 the Widget Tree needed to make LVGL render the examples shown.  Each example assumes
-LVGL has undergone normal initialization, meaning that a `lv_display_t` object
+LVGL has undergone normal initialization, meaning that a <ApiLink name="lv_display_t" /> object
 was created and therefore has an [Active Screen](/common-widget-features/screens).
 
 ### A very simple *hello world* label

docs/src/getting_started/index.mdx

@@ -2,5 +2,25 @@
 title: Getting started
 ---
 
+LVGL (Light and Versatile Graphics Library) is a free and open-source graphics
+library providing everything you need to create an embedded GUI with easy-to-use
+mobile-phone-like graphical elements, beautiful visual effects, and a low memory
+footprint.
+
+You can think of LVGL as a collection of C and H files that can be dropped into
+any project to add UI capabilities to the product.
+
+With the help of consistent and easy-to-learn API functions you can create [widgets](/widgets)
+(buttons, sliders, charts, etc), style them, add events, layouts, or animations.
+
+Based on these settings LVGL will render an image (either by using its built-in
+software rendering engine or a GPU) and will call a callback function to show
+the rendered image on the display. This callback function is the main interface
+between LVGL and the display. Most of the porting-related work is focused on
+writing such a callback in an effective way.
+
+This chapter will show the basics to give an idea about how LVGL works and how it can be used.
+For more details about each feature visit that feature's dedicated documentation page.
+
 
 <DirectoryIndex />

docs/src/getting_started/learn_the_basics.mdx

@@ -1,113 +1,25 @@
 ---
 title: Learn the Basics
-description: "LVGL (Light and Versatile Graphics Library) is a free and open-source graphics library providing everything you need to create an embedded GUI with easy-to-use mobile-phone-like graphical elements,..."
+description: "Learn how to use LVGL in a few minutes"
 ---
 
-## Overview
 
-LVGL (Light and Versatile Graphics Library) is a free and open-source graphics
-library providing everything you need to create an embedded GUI with easy-to-use
-mobile-phone-like graphical elements, beautiful visual effects, and a low memory
-footprint.
+In LVGL you dynamically create and delete screens and widgets to build up your UI. Styles, animations, event handlers, and data bindings
+can also be added to make the UI look better and connect it easily to an application.
 
-You can think of LVGL as a collection of C and H files that can be dropped into
-any project to add UI capabilities to the product.
 
-With the help of consistent and easy-to-learn API functions you can create widgets
-(buttons, sliders, charts, etc), style them, add events, layouts, or animations.
+## Display
 
-Based on these settings LVGL will render an image (either by using its built-in
-software rendering engine or a GPU) and will call a callback function to show
-the rendered image on the display. This callback function is the main interface
-between LVGL and the display. Most of the porting-related work is focused on
-writing such a callback in an effective way.
-
-This chapter will show the basics to give an idea about how LVGL works and how it can be used.
-For more details about each feature visit that feature's dedicated documentation page.
-
-### LVGL Integration Overview
-
-The following is an overview of how to integrate LVGL into your project.  Complete
-details are available at [Overview](/integration/overview).
-
-| Field | Description |
-|-------|-------------|
-| `Driver Initialization` | It is the user's responsibility to set up the clock, timers, peripherals, etc. |
-| `Call lv_init()` | Initialize LVGL itself. |
-| `Create display and input devices` | Create display(s) (<ApiLink name="lv_display_t" />) and input device(s) (<ApiLink name="lv_indev_t" />) and set up their callbacks. |
-| `Create the UI` | Call LVGL functions to create screens, widgets, styles, animations, events, etc. |
-| `Call lv_timer_handler() in a loop` | This handles all the LVGL-related tasks: - refresh display(s), - read input devices, - fire events based on user input (and other things), - run any animations, and - run user-created timers. |
-
-##### Example
-
-This is just a brief example of how to add LVGL to a new project. For more details
-check out [Integration Overview](/integration/overview).
-
-```c
-void main(void)
-{
-    your_driver_init();
-
-    lv_init();
-
-    lv_tick_set_cb(my_get_millis);
-
-    lv_display_t * display = lv_display_create(320, 240);
-
-    /* LVGL will render to this 1/10 screen sized buffer for 2 bytes/pixel */
-    static uint8_t buf[320 * 240 / 10 * 2];
-    lv_display_set_buffers(display, buf, NULL, LV_DISPLAY_RENDER_MODE_PARTIAL);
-
-    /* This callback will display the rendered image */
-    lv_display_set_flush_cb(display, my_flush_cb);
-
-    /* Create widgets */
-    lv_obj_t * label = lv_label_create(lv_screen_active());
-    lv_label_set_text(label, "Hello LVGL!");
-
-    /* Make LVGL periodically execute its tasks */
-    while(1) {
-        /* Provide updates to currently-displayed Widgets here. */
-        lv_timer_handler();
-        my_sleep(5);  /*Wait 5 milliseconds before processing LVGL timer again*/
-    }
-}
-
-/* Return the elapsed milliseconds since startup.
- * It needs to be implemented by the user */
-uint32_t my_get_millis(void)
-{
-    return my_tick_ms;
-}
-
-/* Copy rendered image to screen.
- * This needs to be implemented by the user. */
-void my_flush_cb(lv_display_t * disp, const lv_area_t * area, uint8_t * px_buf)
-{
-    /* Show the rendered image on the display */
-    my_display_update(area, px_buf);
-
-    /* Indicate that the buffer is available.
-     * If DMA were used, call in the DMA complete interrupt. */
-    lv_display_flush_ready();
-}
-```
-
-## Displays
-
-*Display* refers to the actual hardware. In order to connect LVGL to the hardware an <ApiLink name="lv_display_t" />
+A *Display* refers to the actual hardware. In order to connect LVGL to the hardware an <ApiLink name="lv_display_t" />
 object needs to be created and initialized.
 
-LVGL has built-in support for many built-in drivers (see [Integration](/integration)), but it's easy to initialize a
-display from scratch as well (as shown above).
+See the [Quick porting guide](/getting_started/porting).
 
-LVGL also handles multiple displays at once.
+## Screen
 
-## Screens
-
-A *Screen* is an LVGL widget created on a *Display*. It's a logical container for other widgets. A display can
-have multiple screens, but there is always one active screen, which can be retrieved by using <ApiLink name="lv_screen_active" />.
-It returns an `lv_obj_t *` pointer. See [Active Screen](/common-widget-features/screens) for more information.
+Screens are LVGL widgets created on a *Display*. They are logical containers for other widgets. A display can
+have multiple screens, but there is always a single active screen, which can be retrieved by using <ApiLink name="lv_screen_active" />.
+It returns an <ApiLink name="lv_obj_t" display="lv_obj_t *" /> pointer. See [Active Screen](/common-widget-features/screens) for more information.
 
 The most common way to create a screen is by creating a [Base widget](/widgets/base_widget) with a `NULL` parent. E.g.
 
@@ -152,9 +64,9 @@ lv_obj_set_size(my_button1, lv_pct(100), LV_SIZE_CONTENT);
 lv_obj_align(my_button1, LV_ALIGN_RIGHT_MID, -20, 0);
 
 lv_obj_t * my_label1 = lv_label_create(my_button1);
-lv_label_set_text_fmt(my_label1, "Click me!");
-lv_obj_set_style_text_color(my_label1, lv_color_hex(0xff0000), 0);
+lv_label_set_text(my_label1, "Click me!");
 /* Make the text red */
+lv_obj_set_style_text_color(my_label1, lv_color_hex(0xff0000), 0);
 ```
 
 To see the full API for any widget, see its documentation at [All Widgets](/widgets), or check
@@ -207,10 +119,10 @@ has only one part called <ApiLink name="LV_PART_MAIN" />. However, a
 [Slider (lv_slider)](/widgets/slider) has <ApiLink name="LV_PART_MAIN" />, <ApiLink name="LV_PART_INDICATOR" />
 and <ApiLink name="LV_PART_KNOB" />.
 
-By using parts you can apply different [styles](/getting_started/learn_the_basics) to the parts
+By using [parts](/common-widget-features/parts_and_states) you can apply different [styles](/common-widget-features/styles) to the different parts
 of a widget.
 
-Read the Widget's documentation to learn which parts it uses.
+Read the specific Widget's documentation to learn which parts it uses.
 
 ### States
 
@@ -250,7 +162,7 @@ lv_obj_remove_state(widget, LV_STATE_...);
 Styles are carried in <ApiLink name="lv_style_t" /> objects. They contain properties such as
 background color, border width, font, etc.
 
-The styles can be added to a widget's given [Part](/getting_started/learn_the_basics) and [State](/getting_started/learn_the_basics).
+The styles can be added to a widget's given [Part](/common-widget-features/parts_and_states) and [State](/common-widget-features/parts_and_states).
 Only their pointer is saved in the Widgets so they need to be defined as static or global variables.
 
 Before using a style it needs to be initialized with <ApiLink name="lv_style_init" display="lv_style_init(&style1)" />.
@@ -287,8 +199,7 @@ font is specified on the widget or one of its parents.
 
 ### Local styles
 
-Local style properties also can be added to Widgets. This creates a
-style which resides inside the Widget and is used only by that Widget:
+Local style properties can also be added to Widgets. The local style properties affect only the targeted widget.
 
 ```c
 lv_obj_set_style_bg_color(slider1, lv_color_hex(0x2080bb), LV_PART_INDICATOR | LV_STATE_PRESSED);
@@ -296,9 +207,9 @@ lv_obj_set_style_bg_color(slider1, lv_color_hex(0x2080bb), LV_PART_INDICATOR | L
 
 See [Styles](/common-widget-features/styles) for full details.
 
-## Subjects and Observers
+## Data bindings
 
-Subjects and Observers are powerful tools to easily create data bindings.
+To realize data bindings, LVGL uses the Subject/Observer pattern.
 
 Subjects are global <ApiLink name="lv_subject_t" /> variables that store integer, color, string, etc. values.
 
@@ -311,7 +222,7 @@ For some widgets, helper functions make it simple to connect them to subjects. E
 <ApiLink name="lv_slider_bind_value" />, <ApiLink name="lv_label_bind_text" />.
 
 In general, using subjects and observers is a way to connect various parts of the UI and make them dynamically
-react to application data changes—or allow the application to react to UI changes.
+react to application data changes, or allow the application to react to UI changes.
 
 ```c
 static void label_observer_cb(lv_observer_t * observer, lv_subject_t * subject)

docs/src/getting_started/meta.json

@@ -1,6 +1,7 @@
 {
   "title": "Getting started",
   "pages": [
+    "porting",
     "learn_the_basics",
     "examples",
     "whats_next"

docs/src/getting_started/porting.mdx

@@ -0,0 +1,89 @@
+---
+title: Porting overview
+description: "Learn the basics about how to port LVGL to any hardware"
+---
+
+
+
+## Quick start
+
+The following is an overview of how to integrate LVGL into your project.
+A more detailed description is available at [Overview](/integration/overview).
+
+
+The main steps are the following:
+1. **Driver Initialization**:  It is the user's responsibility to set up the clock, timers, peripherals, etc.
+2. **Call <ApiLink name="lv_init" display="lv_init()" />**: Initialize LVGL itself.
+3. **Create display and input devices and set up the tick**:  Create display(s) (<ApiLink name="lv_display_t" />) and input device(s) (<ApiLink name="lv_indev_t" />) and set up their callbacks.
+4. **Create the UI**:  Call LVGL functions to create screens, widgets, styles, animations, events, etc.
+5. **Call <ApiLink name="lv_timer_handler" display="lv_timer_handler()" /> in a loop**: This handles all the LVGL-related tasks, such as refreshing display(s), reading input devices, firing events based on user input, running animations, and running user-created timers.
+
+This is just a brief example of how to add LVGL to a new project.
+
+```c
+void main(void)
+{
+    your_driver_init();
+
+    lv_init();
+
+    lv_tick_set_cb(my_get_millis);
+
+    lv_display_t * display = lv_display_create(320, 240);
+
+    /* LVGL will render to this 1/10 screen sized buffer for 2 bytes/pixel */
+    static uint8_t buf[320 * 240 / 10 * 2];
+    lv_display_set_buffers(display, buf, NULL, sizeof(buf), LV_DISPLAY_RENDER_MODE_PARTIAL);
+
+    /* This callback will display the rendered image */
+    lv_display_set_flush_cb(display, my_flush_cb);
+
+    /* Create widgets */
+    lv_obj_t * label = lv_label_create(lv_screen_active());
+    lv_label_set_text(label, "Hello LVGL!");
+
+    /* Make LVGL periodically execute its tasks */
+    while(1) {
+        /* Provide updates to currently-displayed Widgets here. */
+        lv_timer_handler();
+        my_sleep(5);  /*Wait 5 milliseconds before processing LVGL timer again*/
+    }
+}
+
+/* Return the elapsed milliseconds since startup.
+ * It needs to be implemented by the user */
+uint32_t my_get_millis(void)
+{
+    return my_tick_ms;
+}
+
+/* Copy rendered image to screen.
+ * This needs to be implemented by the user. */
+void my_flush_cb(lv_display_t * disp, const lv_area_t * area, uint8_t * px_buf)
+{
+    /* Show the rendered image on the display */
+    my_display_update(area, px_buf);
+
+    /* Indicate that the buffer is available.
+     * If DMA were used, call in the DMA complete interrupt. */
+    lv_display_flush_ready(disp);
+}
+```
+
+## Drivers
+
+### Custom driver
+
+By writing a custom `flush_cb` for your display and `read_cb` for the input devices you can easily create
+your own drivers. Learn more in the [Integration](/integration/overview#connecting-to-hardware) section.
+
+
+## Built-in drivers
+
+LVGL comes with many built-in drivers for display controllers (like ILI9341, ST7789, etc.), Linux drivers (like Wayland, DRM, etc.),
+(RT)OS support (FreeRTOS, NuttX, Linux, etc.), and GPUs (Dave2D, VG-Lite, OpenGL ES, etc.).
+
+These just need to be enabled in `lv_conf.h` to use them right away. Learn more about the built-in drivers in
+the [Integration](/integration/overview#connecting-to-hardware) section.
+
+

docs/src/getting_started/whats_next.mdx

@@ -1,9 +1,9 @@
 ---
 title: "What's Next?"
-description: There are several good ways ways to gain deeper knowledge of LVGL.
+description: There are several good ways to gain deeper knowledge of LVGL.
 ---
 
-There are several good ways ways to gain deeper knowledge of LVGL.  Here is one
+There are several good ways to gain deeper knowledge of LVGL.  Here is one
 recommended order of documents to read and things to play with while you are
 advancing your knowledge:
 

docs/src/guides/how-to-articles/index.mdx

@@ -1,5 +0,0 @@
----
-title: "How-To Articles"
----
-
-

docs/src/guides/index.mdx

@@ -1,6 +0,0 @@
----
-title: Guides
----
-
-
-<DirectoryIndex />

docs/src/guides/internal-subsystems/index.mdx

@@ -1,5 +0,0 @@
----
-title: Internal Subsystems
----
-
-

docs/src/guides/meta.json

@@ -1,7 +0,0 @@
-{
-  "title": "Guides",
-  "pages": [
-    "how-to-articles",
-    "internal-subsystems"
-  ]
-}

docs/src/integration/bindings/cpp.mdx

@@ -1,6 +1,6 @@
 ---
 title: Cpp
-description: "In progress: https://github."
+description: "The C++ binding for LVGL is in progress. See https://github.com/lvgl/lv_binding_cpp."
 ---
 
 In progress: https://github.com/lvgl/lv_binding_cpp

docs/src/integration/bindings/micropython.mdx

@@ -35,9 +35,9 @@ LVGL is implemented in C and its APIs are in C.
 
 - Develop GUI in Python, a very popular high level language. Use paradigms such as Object-Oriented Programming.
 - Usually, GUI development requires multiple iterations to get things right. With C, each iteration consists of
-  [Change code` > `Build` > `Flash` > `Run`. In MicroPython it's just
+  `Change code` > `Build` > `Flash` > `Run`. In MicroPython it's just
   `Change code` > `Run`! You can even run commands interactively using the
-  `REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) (the interactive prompt)
+  [REPL](https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop) (the interactive prompt)
 
 ### MicroPython + LVGL could be used for:
 
@@ -91,6 +91,8 @@ Many LVGL examples are available also for MicroPython. Just click the link!
 
 ### PC Simulator
 
+You can also run LVGL on a [PC](/integration/pc) without MicroPython.
+
 MicroPython is ported to many platforms. One notable port is to "Unix", which allows
 you to build and run MicroPython (+LVGL) on a Linux machine.  (On a Windows machine
 you might need Virtual Box or WSL or MinGW or Cygwin etc.)
@@ -112,24 +114,24 @@ It can be ported to any other platform supported by MicroPython.
 **lv_micropython** already contains these drivers:
 
 - Display drivers:
-  
+
   - SDL on Linux
   - X11 on Linux
   - ESP32 specific:
-  
+
     - ILI9341
     - ILI9488
     - GC9A01
     - ST7789
     - ST7735
-  
+
   - Generic (pure Python):
-  
+
     - ILI9341
     - ST7789
     - ST7735
 - Input drivers:
-  
+
   - SDL
   - X11
   - XPT2046
@@ -138,8 +140,8 @@ It can be ported to any other platform supported by MicroPython.
 
 ## Where can I find more information?
 
-- [lv_micropython` `README](https://github.com/lvgl/lv_micropython)
-- [lv_binding_micropython` `README](https://github.com/lvgl/lv_binding_micropython)
+- [lv_micropython README](https://github.com/lvgl/lv_micropython)
+- [lv_binding_micropython README](https://github.com/lvgl/lv_binding_micropython)
 - The [LVGL micropython forum](https://forum.lvgl.io/c/micropython) (Feel free to ask anything!)
 - At MicroPython: [docs](http://docs.micropython.org/en/latest/) and [forum](https://forum.micropython.org/)
 - [Blog Post](https://blog.lvgl.io/2019-02-20/micropython-bindings), a little outdated.
@@ -162,28 +164,26 @@ For a summary of coding conventions to follow see the [Coding Style](/contributi
   manager which is [garbage-collected](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) (GC).
 - To prevent GC from collecting memory prematurely, all dynamic allocated RAM must be reachable by the GC.
 - GC is aware of most allocations, except from pointers to the [Data Segment](https://en.wikipedia.org/wiki/Data_segment):
-  
+
     - Pointers which are global variables
     - Pointers which are static global variables
     - Pointers which are static local variables
 
 Such pointers need to be defined in a special way to make them reachable by the GC.
 
-##### Identify The Problem
+#### Identify The Problem
 
 A problem occurs when an allocated memory's pointer (return value of <ApiLink name="lv_malloc" />)
 is stored only in either **global**, **static global** or **static local** pointer
 variable and not as part of a previously allocated `struct` or other variable.
 
-##### Solving the Problem
+#### Solving the Problem
 
-- Replace the global/static local var with <ApiLink name="(LV_GLOBAL_DEFAULT()->_var)" />
+- Replace the global/static local var with `LV_GLOBAL_DEFAULT()->_var` (see <ApiLink name="LV_GLOBAL_DEFAULT" />)
 - Include `lv_global.h` on files that use <ApiLink name="LV_GLOBAL_DEFAULT" />
 - Add `_var` to `lv_global_t` on `lv_global.h`
 
-##### Example
-
-##### Further Reading on Memory Management
+#### Further Reading on Memory Management
 
 - [In the README](https://github.com/lvgl/lv_binding_micropython#memory-management)
 - [In the Blog](https://blog.lvgl.io/2019-02-20/micropython-bindings#i-need-to-allocate-a-littlevgl-struct-such-as-style-color-etc-how-can-i-do-that-how-do-i-allocatedeallocate-memory-for-it)
@@ -207,27 +207,27 @@ next to the function pointer when registering a callback, and access that object
 There are a few options for defining a callback in LVGL C API:
 
 - Option 1: `user_data` in a struct
-  
+
   - There's a struct that contains a field called `void * user_data`
-  
+
     - A pointer to that struct is provided as the **first** argument of a callback registration function.
     - A pointer to that struct is provided as the **first** argument of the callback itself.
 - Option 2: `user_data` as a function argument
-  
+
   - A parameter called `void * user_data` is provided to the registration function as the **last** argument
-  
+
     - The callback itself receives `void *` as the **last** argument
 - Option 3: both callback and `user_data` are struct fields
-  
+
   - The API exposes a struct with both function pointer member and `user_data` member
-  
+
     - The function pointer member receives the same struct as its **first** argument
 
 In practice it's also possible to mix these options, for example provide a struct pointer when registering a callback
 (option 1) and provide `user_data` argument when calling the callback (options 2),
 **as long as the same** `user_data` **that was registered is passed to the callback when it's called**.
 
-##### Examples
+#### Examples
 
 - <ApiLink name="lv_anim_t" /> contains `user_data` field. <ApiLink name="lv_anim_set_path_cb" /> registers `path_cb` callback.
   Both `lv_anim_set_path_cb` and <ApiLink name="lv_anim_path_cb_t" /> receive <ApiLink name="lv_anim_t" /> as their first argument
@@ -236,7 +236,7 @@ In practice it's also possible to mix these options, for example provide a struc
 - <ApiLink name="lv_imgfont_create" /> registers `path_cb` and receives `user_data` as the last argument.
   The callback <ApiLink name="lv_imgfont_get_path_cb_t" /> also receives the `user_data` as the last argument.
 
-##### Further Reading on Callbacks
+#### Further Reading on Callbacks
 
 - In the [Blog](https://blog.lvgl.io/2019-08-05/micropython-pure-display-driver#using-callbacks)
   and in the [README](https://github.com/lvgl/lv_binding_micropython#callbacks)

docs/src/integration/boards/manufacturers/icop.mdx

@@ -40,7 +40,7 @@ See the
 [store page](https://www.icop.com.tw/product/QEC-PPC-M-090T)
 for documentation and the ordering information.
 
-##### Specs
+#### Specs
 
 CPU and Memory
 

docs/src/integration/boards/manufacturers/toradex.mdx

@@ -33,16 +33,13 @@ making the board extra reliable, especially in these environments.
 
 Aquila Computer on Module:
 
-- [Aquila iMX95](https://www.toradex.com/computer-on-modules/
-      aquila-arm-family/nxp-imx95)
-    - [Aquila AM69](https://www.toradex.com/computer-on-modules/
-      aquila-arm-family/ti-am69)
+- [Aquila iMX95](https://www.toradex.com/computer-on-modules/aquila-arm-family/nxp-imx95)
+    - [Aquila AM69](https://www.toradex.com/computer-on-modules/aquila-arm-family/ti-am69)
 
 Aquila Carrier Boards:
 
 - [Clover](https://www.toradex.com/products/carrier-board/clover)
-    - [Aquila Development Board](https://www.toradex.com/products/carrier-board/
-      aquila-development-board-kit)
+    - [Aquila Development Board](https://www.toradex.com/products/carrier-board/aquila-development-board-kit)
 
 ### Apalis
 
@@ -58,19 +55,14 @@ offerings and the company's rich ecosystem of other products and services.
 
 Apalis Computer on Module:
 
-- [Apalis iMX8](https://www.toradex.com/computer-on-modules/
-      apalis-arm-family/nxp-imx-8)
-    - [Apalis iMX6](https://www.toradex.com/computer-on-modules/
-      apalis-arm-family/nxp-freescale-imx-6)
-    - [Apalis T30](https://www.toradex.com/computer-on-modules/
-      apalis-arm-family/nvidia-tegra-3)
+- [Apalis iMX8](https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-imx-8)
+    - [Apalis iMX6](https://www.toradex.com/computer-on-modules/apalis-arm-family/nxp-freescale-imx-6)
+    - [Apalis T30](https://www.toradex.com/computer-on-modules/apalis-arm-family/nvidia-tegra-3)
 
 Apalis Carrier Boards:
 
-- [Ixora](https://www.toradex.com/products/carrier-board/
-      ixora-carrier-board)
-    - [Apalis Evaluation Board](https://www.toradex.com/products/carrier-board/
-      ixora-carrier-board)
+- [Ixora](https://www.toradex.com/products/carrier-board/ixora-carrier-board)
+    - [Apalis Evaluation Board](https://www.toradex.com/products/carrier-board/ixora-carrier-board)
 
 ### Colibri
 
@@ -85,33 +77,21 @@ Colibri Arm family of modules.
 
 Colibri Computer on Module:
 
-- [Colibri iMX8X](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nxp-imx-8x)
-    - [Colibri T30](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nvidia-tegra-3)
-    - [Colibri T20](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nvidia-tegra-2)
-    - [Colibri iMX6](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nxp-freescale-imx6)
-    - [Colibri iMX7](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nxp-freescale-imx7)
-    - [Colibri iMXiMX6ULL8X](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nxp-imx6ull)
-    - [Colibri VF61](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nxp-freescale-vybrid-vf6xx)
-    - [Colibri VF50](https://www.toradex.com/computer-on-modules/
-      colibri-arm-family/nxp-freescale-vybrid-vf5xx)
+- [Colibri iMX8X](https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-imx-8x)
+    - [Colibri T30](https://www.toradex.com/computer-on-modules/colibri-arm-family/nvidia-tegra-3)
+    - [Colibri T20](https://www.toradex.com/computer-on-modules/colibri-arm-family/nvidia-tegra-2)
+    - [Colibri iMX6](https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-freescale-imx6)
+    - [Colibri iMX7](https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-freescale-imx7)
+    - [Colibri iMX6ULL](https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-imx6ull)
+    - [Colibri VF61](https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-freescale-vybrid-vf6xx)
+    - [Colibri VF50](https://www.toradex.com/computer-on-modules/colibri-arm-family/nxp-freescale-vybrid-vf5xx)
 
 Colibri Carrier Boards:
 
-- [Colibri Evaluation Board](https://www.toradex.com/products/carrier-board/
-      colibri-evaluation-board)
-    - [Iris Carrier Board](https://www.toradex.com/products/carrier-board/
-      iris-carrier-board)
-    - [Viola Carrier Board](https://www.toradex.com/products/carrier-board/
-      viola-carrier-board)
-    - [Aster Carrier Board](https://www.toradex.com/products/carrier-board/
-      aster-carrier-board)
+- [Colibri Evaluation Board](https://www.toradex.com/products/carrier-board/colibri-evaluation-board)
+    - [Iris Carrier Board](https://www.toradex.com/products/carrier-board/iris-carrier-board)
+    - [Viola Carrier Board](https://www.toradex.com/products/carrier-board/viola-carrier-board)
+    - [Aster Carrier Board](https://www.toradex.com/products/carrier-board/aster-carrier-board)
 
 ### Verdin
 
@@ -125,28 +105,19 @@ vibration-resistant connection.
 
 Verdin Computer on Module:
 
-- [Verdin iMX8M Plus](https://www.toradex.com/computer-on-modules/
-      verdin-arm-family/nxp-imx-8m-plus)
-    - [Verdin iMX8M Mini](https://www.toradex.com/computer-on-modules/
-      verdin-arm-family/nxp-imx-8m-mini-nano)
-    - [Verdin AM62](https://www.toradex.com/computer-on-modules/
-      verdin-arm-family/ti-am62)
-    - [i.MX 95 Verdin Evaluation Kit](https://www.toradex.com/
-      computer-on-modules/verdin-arm-family/nxp-imx95-evaluation-kit)
-    - [Verdin iMX95](https://www.toradex.com/computer-on-modules/
-      verdin-arm-family/nxp-imx95-evaluation-kit#verdin-imx95)
+- [Verdin iMX8M Plus](https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-plus)
+    - [Verdin iMX8M Mini](https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx-8m-mini-nano)
+    - [Verdin AM62](https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62)
+    - [i.MX 95 Verdin Evaluation Kit](https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95-evaluation-kit)
+    - [Verdin iMX95](https://www.toradex.com/computer-on-modules/verdin-arm-family/nxp-imx95-evaluation-kit#verdin-imx95)
 
 Verdin Carrier Boards:
 
-- [Verdin Development Board with HDMI Adapter](https://www.toradex.com/
-      products/carrier-board/verdin-development-board-kit)
-    - [Dahlia Carrier Board with HDMI Adapter](https://www.toradex.com/products/
-      carrier-board/dahlia-carrier-board-kit)
+- [Verdin Development Board with HDMI Adapter](https://www.toradex.com/products/carrier-board/verdin-development-board-kit)
+    - [Dahlia Carrier Board with HDMI Adapter](https://www.toradex.com/products/carrier-board/dahlia-carrier-board-kit)
     - [Yavia](https://www.toradex.com/products/carrier-board/yavia)
-    - [Mallow Carrier Board](https://www.toradex.com/products/carrier-board/
-      mallow-carrier-board)
-    - [Ivy Carrier Board](https://www.toradex.com/products/carrier-board/
-      ivy-carrier-board)
+    - [Mallow Carrier Board](https://www.toradex.com/products/carrier-board/mallow-carrier-board)
+    - [Ivy Carrier Board](https://www.toradex.com/products/carrier-board/ivy-carrier-board)
 
 ## TorizonOS
 
@@ -161,10 +132,8 @@ applications.
 A TorizonOS guide to develop an application using LVGL can be found in the
 [Torizon OS](/integration/embedded_linux/distros/torizon) section.
 
-More information is provided in the [Torizon documentation](https://www.torizon.
-io/torizon-os).
+More information is provided in the [Torizon documentation](https://www.torizon.io/torizon-os).
 
 ## Toradex Examples
 
-There are existing ready to use repositories available. Click [here](https://
-github.com/lvgl?q=lv_port_toradex&type=all&language=&sort=) to check them out.
+There are existing ready to use repositories available. Click [here](https://github.com/lvgl?q=lv_port_toradex&type=all&language=&sort=) to check them out.

docs/src/integration/building/cmake.mdx

@@ -24,7 +24,7 @@ You need to install
 
 ### How to build this project using cmake
 
-##### Build with Command line
+#### Build with Command line
 
 The simplest way to build LVGL using cmake is to use the command line calls:
 
@@ -42,7 +42,7 @@ cmake -B build      # Configure phase
 cmake --build build # build phase
 ```
 
-##### Build with cmake presets
+#### Build with cmake presets
 
 Another way to build this project is to use the provided CMakePresets.json or pass options using the command line.
 The CMakePresets.json file describes some cmake configurations and build phase. It is a way to quickly use a set of
@@ -70,7 +70,7 @@ cmake --build --preset windows-base_dbg
 ctest --preset windows-base_dbg
 ```
 
-##### Build with IDE
+#### Build with IDE
 
 The recommended way for consuming CMakePresets is a CMakePresets aware IDE such as
 
@@ -80,7 +80,7 @@ The recommended way for consuming CMakePresets is a CMakePresets aware IDE such
 
 Simply load this project into your IDE and select your desired preset and you are good to go.
 
-##### Build with CMake GUI
+#### Build with CMake GUI
 
 Open this project with CMake GUI and select your desired preset. When hitting the generate button,
 CMake will create solution files (for VS) or Ninja Files (for Linux Ninja Build)

docs/src/integration/chip_vendors/alif/overview.mdx

@@ -13,7 +13,7 @@ Alif offers both microcontrollers and microprocessors.
 ## LVGL on Alif Boards
 
 This is a guide for getting started with LVGL on an Alif board. It specifically details
-the all the steps needed to get the LVGL example project
+all the steps needed to get the LVGL example project
 [alif_m55-lvgl](https://github.com/alifsemi/alif_m55-lvgl) running on the
 [Alif E7 Devkit Gen2](https://alifsemi.com/ensemble-e7-series/); however, any project
 based on the [Alif VS Code Template](https://github.com/alifsemi/alif_vscode-template)
@@ -27,7 +27,7 @@ This project uses D/AVE 2D rendering acceleration with LVGL's D/AVE 2D [draw uni
 
 ### Step-by-Step Guide
 
-##### Install Visual Studio Code
+#### Install Visual Studio Code
 
 Install Visual Studio code. There are different ways of installing it depending on your platform.
 [See here](https://code.visualstudio.com/docs/setup/setup-overview).
@@ -45,7 +45,7 @@ Install the "Dev Containers" VS Code extension. Select your container from the "
 side panel.
 </Callout>
 
-##### Install Prerequisite tools
+#### Install Prerequisite tools
 
 Make sure these are installed in your environment. The VS Code extensions rely on these being present.
 
@@ -53,7 +53,7 @@ Make sure these are installed in your environment. The VS Code extensions rely o
 - `curl`
 - `unzip`
 
-##### Install the Alif SE Tools
+#### Install the Alif SE Tools
 
 Create an Alif account and download the tools from
 [here](https://alifsemi.com/support/software-tools/ensemble/) under "Alif Security Toolkit".
@@ -72,18 +72,18 @@ Among the results of `ls` you should see `app-release-exec-linux`. That, combine
 with the output of `pwd`, is the path you need to use later. I.e.,
 `/home/you/app-release-exec-linux`.
 
-##### Install J-Link Software (optional)
+#### Install J-Link Software (optional)
 
 Download the latest stable version of the [J-Link Software](https://www.segger.com/downloads/jlink).
 Its installation path will be needed later.
 
-##### Clone the `alif_m55-lvgl` Project
+#### Clone the `alif_m55-lvgl` Project
 
 ```bash
 git clone --recursive https://github.com/alifsemi/alif_m55-lvgl
 ```
 
-##### Open `alif_m55-lvgl` in VS Code
+#### Open `alif_m55-lvgl` in VS Code
 
 Open the cloned repo in VS Code. For the VS Code extensions to work properly,
 it's recommended to open the folder in VS Code instead of opening a
@@ -98,7 +98,7 @@ or navigate to **File \> Open Folder** in VS Code and open `alif_m55-lvgl`.
 If you are prompted to automatically install recommended extensions, click
 "install" so you can skip the next step.
 
-##### Install Required VS Code Extensions
+#### Install Required VS Code Extensions
 
 Install the following VS Code extensions from the "Extensions" side panel
 
@@ -107,7 +107,7 @@ Install the following VS Code extensions from the "Extensions" side panel
 - C/C++ Extension Pack
 - Cortex-Debug (optional. needed for debugging)
 
-##### Activate Environment
+#### Activate Environment
 
 If it hasn't happened automatically, Click "Arm Tools" on the bottom bar and then
 click "Activate Environment" in the list that appears. It will install CMake,
@@ -115,7 +115,7 @@ ninja-build, a GCC ARM compiler, and cmsis-toolbox.
 
 If you only see "Reactivate Environment" then it is likely already active.
 
-##### Set the Paths of Installed Tools
+#### Set the Paths of Installed Tools
 
 Press ctrl + shift + p. Type "preferences" and select the option
 "Preferences: Open User Settings (JSON)" from the choices.
@@ -149,7 +149,7 @@ If your `settings.json` looks like this initially...
 The above uses Windows paths as an example. A Linux path to the Alif SE Tools may look
 something like `"/home/you/app-release-exec-linux"`.
 
-##### Configure the Board Variant
+#### Configure the Board Variant
 
 Open the
 [board.h file](https://github.com/alifsemi/alif_vscode-template/blob/ce5423dbd15f62cb0aa4462533a960d79a014f97/board/board.h#L23-L30).
@@ -157,7 +157,7 @@ Open the
 Identify your board variant in the list and set `BOARD_ALIF_DEVKIT_VARIANT` to the correct value.
 You may also need to set `BOARD_ILI9806E_PANEL_VARIANT` if the default does not match yours.
 
-##### Set Up the Build Context, Compile, and Flash
+#### Set Up the Build Context, Compile, and Flash
 
 Get to the "Manage Solution" view from the CMSIS Solution extension. You can reach
 it by either clicking the gear icon on the bottom bar or by navigating to the CMSIS panel
@@ -192,7 +192,8 @@ Alif sources for more detailed steps.
 - [Getting Started with VSCode CMSIS pack project](https://github.com/alifsemi/alif_vscode-template/blob/main/doc/getting_started.md)
 - [VSCode Getting Started Template](https://github.com/alifsemi/alif_vscode-template/blob/main/README.md)
 
-You can download the "Alif Security Toolkit Quick Start Guide" from https://alifsemi.com/support/software-tools/ensemble/ ,
+You can download the "Alif Security Toolkit Quick Start Guide" from the
+[Alif software tools page](https://alifsemi.com/support/software-tools/ensemble/),
 assuming you have created an account, to learn how to use the Alif SE Tools to perform
 low-level manipulations on your board.
 
@@ -203,7 +204,7 @@ an HP target or an HE target. What these are referring to are the two distinct c
 present in the Alif E7. "HE" stands for "High Efficiency" while "HP" stands for
 "High Performance". To get the best performance out of an LVGL application, select HP.
 Consider HE when power usage is a concern. The merit of having asymmetrical cores
-is that your application can run theoretically run low-priority workloads efficiently on
+is that your application can theoretically run low-priority workloads efficiently on
 the HE core and delegate time critical, processing intensive workloads to the HP core.
 
 There is also an option to choose a "Build Type". For best performance, choose "release".

docs/src/integration/chip_vendors/arm/arm2d.mdx

@@ -7,7 +7,7 @@ Arm-2D is not a GPU but **an abstraction layer for 2D GPUs dedicated to
 Microcontrollers**. It supports all Cortex-M processors ranging from
 Cortex-M0 to the latest Cortex-M85.
 
-Arm-2D accelerates LVGL9 with two modes: **Synchronous Mode** and
+Arm-2D accelerates LVGL's [drawing](/main-modules/draw) with two modes: **Synchronous Mode** and
 **Asynchronous Mode**.
 
 - When **Helium** and **ACI (Arm Custom Instruction)** are available, it is recommend
@@ -15,18 +15,18 @@ Arm-2D accelerates LVGL9 with two modes: **Synchronous Mode** and
 - When Arm-2D backed 2D-GPUs are available, for example, **DMAC-350 based 2D
   GPUs**, it is recommend to use **Asynchronous Mode** to accelerate LVGL.
 
-Arm-2D is an open-source project on GitHub. For more, please refer to:
-https://github.com/ARM-software/Arm-2D.
+Arm-2D is an open-source project on GitHub. For more, please refer to
+[ARM-software/Arm-2D](https://github.com/ARM-software/Arm-2D).
 
 ## How to Use
 
 In general:
 
 - you can set the macro <ApiLink name="LV_USE_DRAW_ARM2D_SYNC" /> to `1` and
-  <ApiLink name="LV_DRAW_SW_ASM" /> to <ApiLink name="LV_DRAW_SW_ASM_HELIUM" /> in `lv_conf.h` to
+  <ApiLink name="LV_USE_DRAW_SW_ASM" /> to <ApiLink name="LV_DRAW_SW_ASM_HELIUM" /> in `lv_conf.h` to
   enable Arm-2D synchronous acceleration for LVGL.
 - You can set
-  the macro <ApiLink name="LV_USE_DRAW_ARM2D_ASYNC" /> to `1` in `lv_conf.h` to enable
+  the macro `LV_USE_DRAW_ARM2D_ASYNC` to `1` in `lv_conf.h` to enable
   Arm-2D Asynchronous acceleration for LVGL.
 
 If you are using

docs/src/integration/chip_vendors/arm/overview.mdx

@@ -5,13 +5,13 @@ description: "Arm is a leading semiconductor and software design company, renown
 
 Arm is a leading semiconductor and software design company, renowned for creating the Cortex-M microcontroller (MCU) cores and Cortex-A/R (MPU) processor cores, which are integral to a wide range of devices. These cores are at the heart of many embedded systems, powering chips from industry giants such as STMicroelectronics, NXP, and Renesas. Arm's energy-efficient designs are used in billions of devices worldwide, from microcontrollers to smartphones and servers. By licensing their processor designs, Arm enables a broad ecosystem of partners to develop customized solutions optimized for performance, power, and size. Arm's architecture is highly compatible with various operating systems and software libraries, including LVGL, making it a versatile choice for developers creating efficient, high-performance graphical user interfaces.
 
-### Compile LVGL for Arm
+## Compile LVGL for Arm
 
 No specific action is required. Any compiler that supports the target Arm architecture can be used to compile LVGL's source code, including GCC, LLVM, and AC6.
 
 It is also possible to cross-compile LVGL for an MPU (instead of compiling it on the target hardware) or create a shared library. For more information, check out [CMake](/integration/building/cmake).
 
-##### Getting Started with AC6
+### Getting Started with AC6
 
 Since AC6 is a proprietary toolchain, it contains many specific optimizations, so you can expect the best performance when using it.
 
@@ -20,11 +20,11 @@ AC6 is not free, but it offers a community license that can be activated as foll
 1. Download and install the AC6 compiler from [Arm's website](https://developer.arm.com/Tools%20and%20Software/Arm%20Compiler%20for%20Embedded).
 2. To register a community license, go to the `bin` folder of the compiler and, in a terminal, run `armlm.exe activate -server https://mdk-preview.keil.arm.com -product KEMDK-COM0` (On Linux, use `./armlm`).
 
-### IDE Support
+## IDE Support
 
 There are no limitations on the supported IDEs. LVGL works in various vendors' IDEs, including Arm's Keil MDK, IAR, Renesas's e2 studio, NXP's MCUXpresso, ST's CubeIDE, as well as custom make or CMake projects.
 
-### Arm2D and the Helium instruction set
+## Arm2D and the Helium instruction set
 
 Arm Cortex-M55 and Cortex-M85 have the [SIMD Helium](https://www.arm.com/technologies/helium) instruction set.
 Among many others, this can effectively speed up UI rendering. [Arm2D](/integration/chip_vendors/arm/arm2d) is a library maintained by Arm that leverages the Helium instruction set.
@@ -41,14 +41,14 @@ To add Arm2D to your project, follow these steps:
 6. The CMSIS DSP library also needs to be added to the project. You can use CMSIS-PACKS or add it manually.
 7. For better performance, enable `LTO` (Link Time Optimization) and use `-Omax` or `-Ofast`.
 8. Arm2D tries to read/write multiple data with a single instruction. Therefore, it's important to use the fastest memory (e.g., `BSS` or `TCM`) for LVGL's buffer to avoid memory bandwidth bottlenecks.
-9. Enable `LV_USE_DRAW_ARM2D_SYNC 1` and `LV_USE_DRAW_SW_ASM LV_DRAW_SW_ASM_HELIUM` in `lv_conf.h`.
+9. Enable <ApiLink name="LV_USE_DRAW_ARM2D_SYNC" /> and set <ApiLink name="LV_USE_DRAW_SW_ASM" /> to <ApiLink name="LV_DRAW_SW_ASM_HELIUM" /> in `lv_conf.h`.
 
-### Neon Acceleration
+## Neon Acceleration
 
-Some ARM Cortex-A and Cortex-R processors with the ARMv7 architecture and every ARM Cortex-A and Cortex-R processor from the ARMv8 architecture support the `Neon SIMD <https://www.arm.com/technologies/neon>` instruction set.
+Some ARM Cortex-A and Cortex-R processors with the ARMv7 architecture and every ARM Cortex-A and Cortex-R processor from the ARMv8 architecture support the [Neon SIMD](https://www.arm.com/technologies/neon) instruction set.
 LVGL has built-in support to improve the performance of software rendering by utilizing Neon instructions.
 
-### Architecture Support
+## Architecture Support
 
 Both 32-bit and 64-bit ARM architectures are supported. Simply set <ApiLink name="LV_USE_DRAW_SW_ASM" /> to <ApiLink name="LV_DRAW_SW_ASM_NEON" /> in `lv_conf`.
 

docs/src/integration/chip_vendors/espressif/add_lvgl_to_esp32_idf_project.mdx

@@ -28,7 +28,7 @@ In case you do not want to use esp_lvgl_port, you can add [LVGL component](https
 idf.py add-dependency "lvgl/lvgl^9.*"
 ```
 
-Adjust the [^9.*` part to match your LVGL version requirement. More information on version specifications can be found in the `IDF Component Manager documentation](https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/versioning.html#range-specifications). During the next build, the LVGL component will be fetched from the component registry and added to the project.
+Adjust the `^9.*` part to match your LVGL version requirement. More information on version specifications can be found in the [IDF Component Manager documentation](https://docs.espressif.com/projects/idf-component-manager/en/latest/reference/versioning.html#range-specifications). During the next build, the LVGL component will be fetched from the component registry and added to the project.
 
 **Advanced usage: Use LVGL as local component**
 
@@ -44,7 +44,7 @@ All components from `${project_dir}/components` are automatically added to the b
 
 ### Display Integration
 
-For a successful LVGL project, you will need a display driver and optionally a touch driver. Espressif provides these drivers that are built on its [esp_lcd](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/lcd/index.html) component.
+For a successful LVGL project, you will need a [display](/main-modules/display) driver and optionally a touch driver. Espressif provides these drivers that are built on its [esp_lcd](https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/lcd/index.html) component.
 
 - esp_lcd natively supports some [basic displays](https://github.com/espressif/esp-idf/tree/master/components/esp_lcd/src)
 - Other displays are maintained in [esp-bsp repository](https://github.com/espressif/esp-bsp/tree/master/components/lcd) and are uploaded to ESP Registry
@@ -63,7 +63,7 @@ idf.py add-dependency "espressif/esp_lcd_gc9a01^2.0.0"
 To configure LVGL, launch the configuration menu with `idf.py menuconfig` in your project root directory. Navigate to `Component config` and then `LVGL configuration`.
 
 Additionally the user can make the current LVGL settings permanent, or default, for the current
-project, all that is needed is to create a file on the project root called 
+project, all that is needed is to create a file on the project root called
 `sdkconfig.defaults` and move the `CONFIG_LV_` symbols to that file.
 
 It is possible to create a per-chip default configuration files by creating a
@@ -73,13 +73,13 @@ IDF project.
 
 ### Starting the LVGL component
 
-Once the IDF project and the LVGL component have been configured, all 
+Once the IDF project and the LVGL component have been configured, all
 the early initialization process inside of the code will be ready to use, however
-the user should manually start the LVGL subsystem for IDF by calling `bsp_display_start()`, 
+the user should manually start the LVGL subsystem for IDF by calling `bsp_display_start()`,
 or `lvgl_port_init()` if LVGL was manually configured, for example without using
 the `esp_bsp` component.
 
-After calling this function, LVGL will be running in the background; that is, 
+After calling this function, LVGL will be running in the background; that is,
 unlike the usual approach, there is no need to periodically call <ApiLink name="lv_timer_handler" />,
 this function is called by a background task managed by the IDF.
 

docs/src/integration/chip_vendors/espressif/hardware_accelerator_dma2d.mdx

@@ -9,11 +9,11 @@ Some chips from Espressif such as the ESP32-P4 family features a peripheral
 that enhances the copy of 2-D data from a place to another, including output
 this 2-D data to other peripherals.
 
-This peripheral is the 2-D direct memory access, or DMA2D, the Espressif 
+This peripheral is the 2-D direct memory access, or DMA2D, the Espressif
 SDK, the IDF, offers a full featured driver for the DMA2D that is automatically
 enabled on the supported chips.
 
-One of its primary role is to serve as support for the Pixel Processor Accelerator
+One of its primary roles is to serve as support for the Pixel Processor Accelerator
 the PPA, being used to copy the source image data to the desired PPA client splitting
 these data into fixed size blocks, called bursts. Also the DMA2D is used to pick the
 output chunks from the PPA client and copy over to the destination buffer, or the display
@@ -28,7 +28,7 @@ display driver uses the DMA2D to copy the target drawn buffer to the display buf
 intervention. Even though this option is available the user is responsible to explicitly enable
 it on the display driver of the LVGL port component.
 
-To enabling it the user should set on its `sdkconfig.defaults` the `CONFIG_BSP_DISPLAY_LVGL_AVOID_TEAR`, 
+To enabling it the user should set on its `sdkconfig.defaults` the `CONFIG_BSP_DISPLAY_LVGL_AVOID_TEAR`,
 which will tell the driver to use the DMA2D to optimize transfer. Please notice that enabling
 this option will be only available when using the PSRAM memory and double buffer mode, otherwise
 a compiler error will be raised.

docs/src/integration/chip_vendors/espressif/hardware_accelerator_ppa.mdx

@@ -19,7 +19,7 @@ The Espressif targets that support the PPA are:
 
 LVGL supports, in experimental level, the filling and the image blending
 acceleration through the PPA, the user can enable it in their `sdkconfig.defaults` by
-adding the following option to enable the PPA draw unit in conjunction with the software renderer, also:
+adding the following option to enable the PPA [draw unit](/main-modules/draw) in conjunction with the software renderer, also:
 don't forget to make the draw buffers aligned with the cache line size, typically 64bytes:
 
 ```c
@@ -30,7 +30,7 @@ CONFIG_LV_DRAW_BUF_ALIGN=64
 Save the file and then rebuild the project, this will be sufficient to add the PPA code and it will start to run automatically, so
 no further steps are required from the user code perspective.
 
-Is it suggested to use PPA with the double buffer support of the ESP LVGL Port since it will not offer performance increase when using it in partial mode due
+It is suggested to use PPA with the double buffer support of the ESP LVGL Port since it will not offer performance increase when using it in partial mode due
 to DMA2D memory bandwidth. To have the best performance and experience you can use the following snippet code to start the LVGL subsystem
 for ESP-IDF:
 

docs/src/integration/chip_vendors/espressif/overview.mdx

@@ -5,7 +5,7 @@ description: "Espressif Systems is a fabless chip manufacturer that produces the
 
 ## About
 
-Espressif Systems is a fabless chip manufacturer that produces the ESP32 series of 
+Espressif Systems is a fabless chip manufacturer that produces the ESP32 series of
 system on chips, these chips can be based on Xtensa or Risc-V architectures, and they
 feature the common set of analog and digital peripherals of a general purpose microcontroller
 combined to a radio subsystem capable to run a Bluetooth and/or a WiFi stack.
@@ -17,12 +17,12 @@ some of its components.
 
 ## Application Development
 
-The LVGL is supported by Espressif SDK, that is it, the IDF as mentioned before, 
+The LVGL is supported by Espressif SDK, that is it, the IDF as mentioned before,
 therefore ESP32 series of chips are supported on a different sets of frameworks
 called by Espressif as 3rd party projects.
 
 This guide will cover the usage of the LVGL using the Espressif-IDF software development
-kit. Although ESP32 are supported on other frameworks also supported by LVGL, it 
+kit. Although ESP32 are supported on other frameworks also supported by LVGL, it
 is recommended the user to check the following pages:
 
 - [Arduino Framework](/integration/frameworks/arduino)
@@ -36,25 +36,25 @@ these platforms where ESP32, and other chips are abstracted by the framework.
 
 ## Ready to use projects
 
-For a quick start with LVGL and ESP32, the LVGL maintains an demo project compatible to
-several ESP32 boards under its `LV Port for ESP32 <https://github.com/lvgl/lv_esp_idf>`.
+For a quick start with LVGL and ESP32, LVGL maintains a demo project compatible with
+several ESP32 boards under its [LV Port for ESP32](https://github.com/lvgl/lv_esp_idf).
 
-Refer to the README.md files in this repository for quick build and 
+Refer to the README.md files in this repository for quick build and
 flash instructions.
 
-These demo projects use Espressif's Board Support Packages (BSPs). 
+These demo projects use Espressif's Board Support Packages (BSPs).
 Additional BSPs and examples are available in the [esp-bsp](https://github.com/espressif/esp-bsp) repository.
 
 ## LVGL Support for ESP32 Graphical Peripherals
 
 Some of the ESP32 chips like the ESP32P4 family have built-in support
-for driving display through standard interfaces like RGB and MIPI, 
-the Espressif IDF (esp-idf), provides the necessary drivers, leaving 
+for driving display through standard interfaces like RGB and MIPI,
+the Espressif IDF (esp-idf), provides the necessary drivers, leaving
 to the user the responsibility to integrate them into the LVGL display
 subsystem.
 
 Espressif, via its component manager system, provides a ready to use
-LVGL porting component, which is the recommended and preferred way of 
+LVGL porting component, which is the recommended and preferred way of
 integrating input and output devices from the ESP32 chip to the LVGL
 Display subsystem, this component is covered in
 [Add LVGL to an ESP32 IDF project](/integration/chip_vendors/espressif/add_lvgl_to_esp32_idf_project)

docs/src/integration/chip_vendors/espressif/tips_and_tricks.mdx

@@ -9,14 +9,14 @@ The IDF project in general are configured to optimize the final application imag
 in respect of its size. For some LVGL applications this may not be desired or will
 result on poor speed of execution.
 
-In this case, it is interesting to set some of the IDF project wide options on the 
+In this case, it is interesting to set some of the IDF project wide options on the
 `sdkconfig.defaults` such as:
 
 ```c
 CONFIG_COMPILER_OPTIMIZATION_PERF=y
 ```
 
-This one will compile the application with performance as priority, using SIMD 
+This one will compile the application with performance as priority, using SIMD
 instructions where is possible. It is possible to perceive an increase up to 30%
 of overall speed execution increment.
 
@@ -29,7 +29,7 @@ CONFIG_LV_ATTRIBUTE_FAST_MEM_USE_IRAM=y
 ```
 
 It is also possible to set the CPU to always run on its maximum speed by
-setting the `CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_` option, the value of the 
+setting the `CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_` option, the value of the
 frequency varies from chip to chip, for example P4 families support 360MHz:
 
 ```c
@@ -42,7 +42,7 @@ And ESP32/ESP32-S3 support 240MHz:
 CONFIG_ESP_DEFAULT_CPU_FREQ_MHZ_240
 ```
 
-Please notice, some of these options needs to be enabled by setting the IDF 
+Please notice, some of these options needs to be enabled by setting the IDF
 experimental options to true:
 
 ```c
@@ -51,14 +51,14 @@ CONFIG_IDF_EXPERIMENTAL_FEATURES=y
 
 ## Configuring the PSRAM on ESP32 supported devices
 
-Some of the high-end chips of ESP32 features an external memory on its module, it is 
+Some of the high-end chips of ESP32 features an external memory on its module, it is
 Pseudo-Static Random Access Memory, the PSRAM. In general values from 4 to 16MB are
 present on the chip and LVGL can take a portion of this memory to:
 
 - Copy read-only objects from Flash to PSRAM to increase speed.
 - Use direct-mode plus dual buffer even on ESP32 that does not have built-in display controller.
 
-In both scenarios the result will be reflected on less time to flush data to the 
+In both scenarios the result will be reflected on less time to flush data to the
 display, resulting in higher frame-rates. To enable the PSRAM usage the user should:
 
 ```c
@@ -69,19 +69,19 @@ CONFIG_SPIRAM_ALLOW_BSS_SEG_EXTERNAL_MEMORY=y
 CONFIG_SPIRAM_RODATA=y
 ```
 
-These options can reside on the IDF project `sdkconfig.defaults`, the last option
+These options can reside on the IDF project `sdkconfig.defaults`.
 
 ## Application crashes when enabling PPA
 
 Is it possible to happen of an application to start crashing because the user
-enabled `CONFIG_LV_USE_PPA` option. The typical symptom is the appearance of 
-a message on the monitor console that indicates error when esp32 calls the 
+enabled `CONFIG_LV_USE_PPA` option. The typical symptom is the appearance of
+a message on the monitor console that indicates error when esp32 calls the
 `esp_msync` function.
 
-This happens because PPA only accepts chunks of data that are aligned to the 
+This happens because PPA only accepts chunks of data that are aligned to the
 cache L1 line size, that is it 64-bytes, even though the PPA draw unit handles
 the alignment of the source buffer, the target draw buffer area should be also
-aligned otherwise the transfer from PPA to it may fail. To prevent this 
+aligned otherwise the transfer from PPA to it may fail. To prevent this
 behavior is interesting to make `CONFIG_LV_DRAW_BUF_ALIGN` to be a multiple of the
 cache L1 line size, that is it, set its value to `64` instead of the default of `4`.
 
@@ -89,7 +89,7 @@ cache L1 line size, that is it, set its value to `64` instead of the default of
 CONFIG_LV_DRAW_BUF_ALIGN=64
 ```
 
-## EPS32-P4 monitor log reports buffer underrun and frame-rate decreases
+## ESP32-P4 monitor log reports buffer underrun and frame-rate decreases
 
 In cases when the PSRAM is enabled and the PPA is used, it is common to see
 frame-rate degradation followed by a message on the log that reports the display
@@ -103,7 +103,7 @@ CONFIG_SPIRAM_SPEED_200M=y
 ```
 
 Additionally it is possible to set the PPA burst length in order to increase
-the memory bandwidth of a particular channel to get speed improvement of the 
+the memory bandwidth of a particular channel to get speed improvement of the
 drawing operations, using the option:
 
 ```c
@@ -111,7 +111,7 @@ CONFIG_LV_PPA_BURST_LENGTH=128
 ```
 
 There is a downside of increasing the burst length, if another piece of code from
-ESP-IDF is using a DMA2D channel which is shared to PPA, this increase may cause 
+ESP-IDF is using a DMA2D channel which is shared to PPA, this increase may cause
 slow-down on that channel consumer. Also mind the burst length value supported
 are the following: 128, 64, 32, 16, and 8 bytes, other values set will result
 in a build error.
@@ -127,7 +127,7 @@ CONFIG_LV_LOG_LEVEL_INFO=y
 CONFIG_LV_LOG_PRINTF=y
 ```
 
-The logging subsystem of LVGL relies on the ESP-IDF presence of the 
+The logging subsystem of LVGL relies on the ESP-IDF presence of the
 printf.
 
 ## Using the File System under ESP-IDF
@@ -137,7 +137,7 @@ This allows seamless interoperability with LVGL when enabling the <ApiLink name=
 The process is described in details below, using `SPIFFS` as demonstration.
 
 - **Decide what storage system you want to use**
-  
+
   ESP-IDF has many, ready-to-use examples like
   [SPIFFS](https://github.com/espressif/esp-idf/tree/master/examples/storage/spiffsgen)
   ,
@@ -146,28 +146,30 @@ The process is described in details below, using `SPIFFS` as demonstration.
   [LittleFS](https://github.com/espressif/esp-idf/tree/master/examples/storage/littlefs)
   .
 - **Re-configure your own project**
-  
+
   The example project should be examined for details, but in general the changes involve:
-  
+
   - Enabling LVGL's STDIO file system in the configuration
-  
+
     You can use `menuconfig`:
-  
+
     - `Component config → LVGL configuration → 3rd Party Libraries`: enable `File system on top of stdio API`
     - Then select `Set an upper cased letter on which the drive will accessible` and set it to `65` (ASCII **A**)
     - You can also set `Default driver letter` to 65 to skip the prefix in file paths.
-  
+
   - Modifying the partition table
-  
+
     The exact configuration depends on your flash size and existing partitions,
     but the new final result should look something like this:
-  
-    .. csv-table:: Partition Table
-  
-       nvs,      data, nvs,     0x9000,  0x6000
-       phy_init, data, phy,     0xf000,  0x1000
-       factory,  app,  factory, 0x10000, 1400k
-       storage,  data, spiffs,         ,  400k
+
+    **Partition Table**
+
+    | Name     | Type | SubType | Offset  | Size   |
+    | -------- | ---- | ------- | ------- | ------ |
+    | nvs      | data | nvs     | 0x9000  | 0x6000 |
+    | phy_init | data | phy     | 0xf000  | 0x1000 |
+    | factory  | app  | factory | 0x10000 | 1400k  |
+    | storage  | data | spiffs  |         | 400k   |
 
 <Callout type="info">
 If you are not using a custom `partition.csv` yet, it can be added
@@ -183,49 +185,49 @@ Some ESP file systems provide automatic generation from a host folder using CMak
 </Callout>
 
 - **Prepare the image files**
-  
+
   LVGL's `LVGLImage.py` Python tool can be used to convert images to binary pixel map files.
   It supports various formats and compression.
-  
+
   Meanwhile 3rd party libraries
   (like [LodePNG](/libs/image_support/lodepng) and [Tiny JPEG](/libs/image_support/tjpgd))
   allow using image files without conversion.
-  
+
   After preparing the files, they should be moved to the target device:
-  
+
   - If properly activated a **SPIFFS** file system based on the `spiffs_image` folder should be automatically generated and later flashed to the target
   - Similar mechanism for **LittleFS** uses the `flash_data` folder, but it's only available for Linux hosts
   - For the **SD Card**, a traditional file browser can be used
 - **Invoke proper API calls in the application code**
-  
+
   The core functionality requires only a few lines. The following example draws the image as well.
-  
-  .. code:: c
-  
-     #include "esp_spiffs.h"
-  
-     void lv_example_image_from_esp_fs(void) \{
-  
-        esp_vfs_spiffs_conf_t conf = \{
-           .base_path = "/spiffs",
-           .partition_label = NULL,
-           .max_files = 5,
-           .format_if_mount_failed = false
-        \};
-  
-        esp_err_t ret = esp_vfs_spiffs_register(&conf);
-  
-        if (ret != ESP_OK) \{
-           ESP_LOGE(TAG, "Failed to register SPIFF filesystem");
-           return;
-        \}
-  
-        lv_obj_t * obj = lv_image_create(lv_screen_active());
-        lv_image_set_src(widget, "A:/spiffs/logo.bin");
-        lv_obj_center(widget);
-     \}
+
+  ```c
+  #include "esp_spiffs.h"
+
+  void lv_example_image_from_esp_fs(void) {
+
+     esp_vfs_spiffs_conf_t conf = {
+        .base_path = "/spiffs",
+        .partition_label = NULL,
+        .max_files = 5,
+        .format_if_mount_failed = false
+     };
+
+     esp_err_t ret = esp_vfs_spiffs_register(&conf);
+
+     if (ret != ESP_OK) {
+        ESP_LOGE(TAG, "Failed to register SPIFF filesystem");
+        return;
+     }
+
+     lv_obj_t * obj = lv_image_create(lv_screen_active());
+     lv_image_set_src(obj, "A:/spiffs/logo.bin");
+     lv_obj_center(obj);
+  }
+  ```
 - **Build and flash**
-  
+
   After calling `idf.py build flash` the picture should be displayed on the screen.
 
 <Callout type="info">

docs/src/integration/chip_vendors/nxp/elcdif.mdx

@@ -3,19 +3,19 @@ title: NXP eLCDIF
 description: "eLCDIF is a peripheral that is provided on some of the NXP devices capable to drive display panels through the RGB interface, it supports different color depths and, on MIPI-DSI capable devices, it..."
 ---
 
-### Overview
+## Overview
 
 eLCDIF is a peripheral that is provided on some of the NXP devices capable to drive display panels through
-the RGB interface, it supports different color depths and, on MIPI-DSI capable devices, its output ca be
+the RGB interface, it supports different color depths and, on MIPI-DSI capable devices, its output can be
 directed to the MIPI display physical interface. The LVGL's NXP eLCDIF driver is responsible to bind the
-NXP MCUx SDK low-level driver to the LVGL display subsystem.
+NXP MCUx SDK low-level driver to the LVGL [display](/main-modules/display) subsystem.
 
-### Prerequisites
+## Prerequisites
 
 - This driver relies on the presence of the MCUx SDK from NXP in the same project
 - Activate the driver by setting <ApiLink name="LV_USE_NXP_ELCDIF" /> to `1` in your *"lv_conf.h"*.
 
-### Usage
+## Usage
 
 The LVGL driver for eLCDIF assumes the platform already configured the display low-level driver,
 set the pin-mux, clocks, etc. It also requires the base address of the peripheral and configuration
@@ -26,7 +26,7 @@ please notice in this mode of operation the application is responsible to alloca
 and pass them to the display, in the example below `buffer1` and `buffer2` are the current and the next
 buffers that will be copied to the display screen, being swapped at each flush operation (managed
 internally by the display driver). Also observe, in direct mode, each buffer should have the space at
-least to hold at least the size of the screen, that is it, the height times the width times the bytes
+least to hold at least the size of the screen, that is, the height times the width times the bytes
 for a pixel (which is application dependent or display supported), on the code below this size is represented
 by `buf_size`.
 
@@ -41,8 +41,8 @@ lv_display_set_default(g_disp);
 To use the driver in <ApiLink name="LV_DISPLAY_RENDER_MODE_PARTIAL" /> mode, an extra buffer must be allocated,
 preferably in the fastest available memory region.
 
-Buffer swapping can be activated by passing a second buffer of same size instead of the <ApiLink name="NULL" /> argument.
-please notice in this case the `BUF_SIZE` needs to have, at least, space to hold data of 1/10 of the actual
+Buffer swapping can be activated by passing a second buffer of same size instead of the `NULL` argument.
+Please notice in this case the `BUF_SIZE` needs to have, at least, space to hold data of 1/10 of the actual
 display dimensions.
 
 ```c
@@ -51,8 +51,8 @@ static uint8_t partial_draw_buf[BUF_SIZE];
 lv_display_t * g_disp = lv_nxp_display_elcdif_create_partial(LCDIF, config, partial_draw_buf, NULL, BUF_SIZE);
 ```
 
-In runtime, the event handler function from the eLCDIF driver should be called inside of the eLCDIF interrupt handler
-This function is responsible for notify the LVGL display subsystem about a finished flush operation:
+In runtime, the event handler function from the eLCDIF driver should be called inside of the eLCDIF interrupt handler.
+This function is responsible for notifying the LVGL display subsystem about a finished flush operation:
 
 ```c
 void eLCDIF_IRQ_Handler(void)

docs/src/integration/chip_vendors/nxp/overview.mdx

@@ -19,38 +19,38 @@ LVGL enables graphics in our free GUI Guider UI tool. It's available for use
 with NXP's general purpose and crossover microcontrollers, providing developers
 with a tool for creating complete, high quality GUI applications with LVGL.
 
-### Creating new project with LVGL
+## Creating new project with LVGL
 
 [Download an SDK for a supported board](https://www.nxp.com/design/software/embedded-software/littlevgl-open-source-graphics-library:LITTLEVGL-OPEN-SOURCE-GRAPHICS-LIBRARY?&tid=vanLITTLEVGL-OPEN-SOURCE-GRAPHICS-LIBRARY)
 today and get started with your next GUI application. It comes fully configured
 with LVGL (and with PXP/VGLite/G2D support if the modules are present), no
 additional integration work is required.
 
-### HW acceleration for NXP iMX RT platforms
+## HW acceleration for NXP iMX RT platforms
 
 Depending on the RT platform used, the acceleration can be done by NXP PXP
 (PiXel Pipeline) and/or the Verisilicon GPU through an API named VGLite. Each
-accelerator has its own context that allows them to be used individually as well
+accelerator has its own context that allows them to be used individually as well as
 simultaneously (in LVGL multithreading mode).
 
-### HW acceleration for NXP iMX platforms
+## HW acceleration for NXP iMX platforms
 
 On MPU platforms, the acceleration can be done (hardware independent) by NXP G2D
 library. This accelerator has its own context that allows them to be used
-individually as well simultaneously with the CPU (in LVGL multithreading mode).
+individually as well as simultaneously with the CPU (in LVGL multithreading mode).
 
-##### PXP accelerator
+### PXP accelerator
 
 #### Basic configuration:
 
 - Select NXP PXP engine in "lv_conf.h": Set <ApiLink name="LV_USE_PXP" /> to `1`.
-- In order to use PXP as a draw unit, select in "lv_conf.h": Set <ApiLink name="LV_USE_DRAW_PXP" /> to `1`.
+- In order to use PXP as a [draw unit](/main-modules/draw), select in "lv_conf.h": Set <ApiLink name="LV_USE_DRAW_PXP" /> to `1`.
 - In order to use PXP to rotate the screen, select in "lv_conf.h": Set <ApiLink name="LV_USE_ROTATE_PXP" /> to `1`.
 - Enable PXP asserts in "lv_conf.h": Set <ApiLink name="LV_USE_PXP_ASSERT" /> to `1`.
   There are few PXP assertions that can stop the program execution in case the
   <ApiLink name="LV_ASSERT_HANDLER" /> is set to `while(1);` (Halt by default). Else,
   there will be logged just an error message via `LV_LOG_ERROR`.
-- If <ApiLink name="SDK_OS_FREE_RTOS" /> symbol is defined, FreeRTOS implementation
+- If `SDK_OS_FREE_RTOS` symbol is defined, FreeRTOS implementation
   will be used, otherwise bare metal code will be included.
 
 #### Basic initialization:
@@ -74,7 +74,7 @@ draw_pxp_unit->base_unit.dispatch_cb = _pxp_dispatch;
 draw_pxp_unit->base_unit.delete_cb = _pxp_delete;
 ```
 
-and an addition thread `_pxp_render_thread_cb()` will be spawned in order to
+and an additional thread `_pxp_render_thread_cb()` will be spawned in order to
 handle the supported draw tasks.
 
 ```c
@@ -88,7 +88,7 @@ and the PXP drawing task will get executed on the same LVGL main thread.
 
 `_pxp_evaluate()` will get called after each task is being created and will
 analyze if the task is supported by PXP or not. If it is supported, then an
-preferred score and the draw unit id will be set to the task. An `score` equal
+preferred score and the draw unit id will be set to the task. A `score` equal
 to `100` is the default CPU score. Smaller score means that PXP is capable of
 drawing it faster.
 
@@ -160,7 +160,7 @@ void lv_draw_pxp_rotate(const void * src_buf, void * dest_buf, int32_t src_width
 
 - Add PXP related source files (and corresponding headers if available) to
   project:
-  
+
    - "src/draw/nxp/pxp/lv_draw_buf_pxp.c": draw buffer callbacks
    - "src/draw/nxp/pxp/lv_draw_pxp_fill.c": fill area
    - "src/draw/nxp/pxp/lv_draw_pxp_img.c": blit image (w/ optional recolor or
@@ -172,26 +172,26 @@ void lv_draw_pxp_rotate(const void * src_buf, void * dest_buf, int32_t src_width
    - "src/draw/nxp/pxp/lv_pxp_utils.c": function helpers
 - PXP related code depends on two drivers provided by MCU SDK. These drivers
   need to be added to project:
-  
+
    - fsl_pxp.c: PXP driver
    - fsl_cache.c: CPU cache handling functions
 
 #### PXP default configuration:
 
 - Implementation depends on multiple OS-specific functions. The struct
-  <ApiLink name="pxp_cfg_t" /> with callback pointers is used as a parameter for the
+  `pxp_cfg_t` with callback pointers is used as a parameter for the
   <ApiLink name="lv_pxp_init" /> function. Default implementation for
   FreeRTOS in lv_pxp_osa.c.
-  
-   - <ApiLink name="pxp_interrupt_init" />: Initialize PXP interrupt (HW setup,
-     OS setup)
-   - <ApiLink name="pxp_interrupt_deinit" />: Deinitialize PXP interrupt (HW setup,
-     OS setup)
-   - <ApiLink name="pxp_run" />: Start PXP job. Use OS-specific mechanism to block
-     drawing thread.
-   - <ApiLink name="pxp_wait" />: Wait for PXP completion.
 
-##### VGLite accelerator
+   - `pxp_interrupt_init`: Initialize PXP interrupt (HW setup,
+     OS setup)
+   - `pxp_interrupt_deinit`: Deinitialize PXP interrupt (HW setup,
+     OS setup)
+   - `pxp_run`: Start PXP job. Use OS-specific mechanism to block
+     drawing thread.
+   - `pxp_wait`: Wait for PXP completion.
+
+### VGLite accelerator
 
 Extra drawing features in LVGL can be handled by the VGLite engine. The
 CPU is available for other operations while the VGLite is running. A
@@ -201,7 +201,7 @@ task or suspend the CPU for power savings.
 #### Basic configuration:
 
 - Select NXP VGLite engine in "lv_conf.h": Set <ApiLink name="LV_USE_DRAW_VGLITE" /> to
-  `1`. <ApiLink name="SDK_OS_FREE_RTOS" /> symbol needs to be defined so that FreeRTOS
+  `1`. `SDK_OS_FREE_RTOS` symbol needs to be defined so that FreeRTOS
   driver osal implementation will be enabled.
 - Enable VGLite asserts in "lv_conf.h": Set <ApiLink name="LV_USE_VGLITE_ASSERT" /> to
   `1`.
@@ -260,7 +260,7 @@ draw_vglite_unit->base_unit.dispatch_cb = _vglite_dispatch;
 draw_vglite_unit->base_unit.delete_cb = _vglite_delete;
 ```
 
-and an addition thread `_vglite_render_thread_cb()` will be spawned in order to
+and an additional thread `_vglite_render_thread_cb()` will be spawned in order to
 handle the supported draw tasks.
 
 ```c
@@ -274,7 +274,7 @@ and the VGLite drawing task will get executed on the same LVGL main thread.
 
 `_vglite_evaluate()` will get called after each task is being created and will
 analyze if the task is supported by VGLite or not. If it is supported, then an
-preferred score and the draw unit id will be set to the task. An `score` equal
+preferred score and the draw unit id will be set to the task. A `score` equal
 to `100` is the default CPU score. Smaller score means that VGLite is capable of
 drawing it faster.
 
@@ -351,8 +351,8 @@ switch(t->type) {
 All the below operation can be done in addition with optional opacity.
 
 - Fill area with color (w/ radius or gradient).
-- Blit source image (any format from `_vglite_src_cf_supported()) over
-  destination (any format from vglite_dest_cf_supported()`).
+- Blit source image (any format from `_vglite_src_cf_supported()`) over
+  destination (any format from `vglite_dest_cf_supported()`).
 - Recolor source image.
 - Scale and rotate (any decimal degree) source image.
 - Blending layers (w/ same supported formats as blitting).
@@ -370,13 +370,13 @@ All the below operation can be done in addition with optional opacity.
   buffer address alignment to be 32 bytes for RGB565 and 64 bytes for ARGB8888.
 - For pixel engine (PE) destination, the alignment should be 64 bytes for all
   tiled (4x4) buffer layouts. The pixel engine has no additional alignment
-  requirement for linear buffer layouts (<ApiLink name="VG_LITE_LINEAR" />).
+  requirement for linear buffer layouts (`VG_LITE_LINEAR`).
 
 #### Project setup:
 
 - Add VGLite related source files (and corresponding headers if available) to
   project:
-  
+
    - "src/draw/nxp/vglite/lv_draw_buf_vglite.c": draw buffer callbacks
    - "src/draw/nxp/vglite/lv_draw_vglite_arc.c": draw arc
    - "src/draw/nxp/vglite/lv_draw_vglite_border.c": draw border
@@ -392,7 +392,7 @@ All the below operation can be done in addition with optional opacity.
    - "src/draw/nxp/vglite/lv_vglite_path.c": create vglite path data
    - "src/draw/nxp/vglite/lv_vglite_utils.c": function helpers
 
-##### G2D accelerator
+### G2D accelerator
 
 #### Basic configuration:
 
@@ -406,7 +406,7 @@ All the below operation can be done in addition with optional opacity.
 #### Basic initialization:
 
 G2D draw initialization is done automatically in <ApiLink name="lv_init" /> once the
-G2D is enabled as a draw unit , no user code is required:
+G2D is enabled as a draw unit, no user code is required:
 
 ```c
 #if LV_USE_DRAW_G2D
@@ -424,12 +424,12 @@ draw_g2d_unit->base_unit.dispatch_cb = _g2d_dispatch;
 draw_g2d_unit->base_unit.delete_cb = _g2d_delete;
 ```
 
-and an addition thread `_g2d_render_thread_cb()` will be spawned in order to
+and an additional thread `_g2d_render_thread_cb()` will be spawned in order to
 handle the supported draw tasks.
 
 ```c
 #if LV_USE_G2D_DRAW_THREAD
-  lv_thread_init(&draw_g2d_unit->thread, LV_THREAD_PRIO_HIGH, _g2d_render_thread_cb, 2 * 1024, draw_g2d_unit);
+  lv_thread_init(&draw_g2d_unit->thread, "g2ddraw", LV_THREAD_PRIO_HIGH, _g2d_render_thread_cb, 2 * 1024, draw_g2d_unit);
 #endif
 ```
 
@@ -438,7 +438,7 @@ and the G2D drawing task will get executed on the same LVGL main thread.
 
 `_g2d_evaluate()` will get called after each task is being created and will
 analyze if the task is supported by G2D or not. If it is supported, then an
-preferred score and the draw unit id will be set to the task. An `score` equal
+preferred score and the draw unit id will be set to the task. A `score` equal
 to `100` is the default CPU score. Smaller score means that G2D is capable of
 drawing it faster.
 
@@ -455,7 +455,7 @@ available for other operations while the G2D is running. Linux OS is required to
 block the LVGL drawing thread and switch to another task or suspend the CPU for
 power savings.
 
-Supported draw tasks are available in "src/draw/nx/g2d/lv_draw_g2d.c":
+Supported draw tasks are available in "src/draw/nxp/g2d/lv_draw_g2d.c":
 
 ```c
 switch(t->type) {
@@ -496,7 +496,7 @@ switch(t->type) {
 
 - Add G2D related source files (and corresponding headers if available) to
   project:
-  
+
    - "src/draw/nxp/g2d/lv_draw_buf_g2d.c": draw buffer callbacks
    - "src/draw/nxp/g2d/lv_draw_g2d_fill.c": fill area
    - "src/draw/nxp/g2d/lv_draw_g2d_img.c": blit image (w/ optional recolor or

docs/src/integration/chip_vendors/nxp/vg_lite_gpu.mdx

@@ -7,11 +7,11 @@ This is a generic VG-Lite rendering backend implementation that is designed to u
 [VeriSilicon](https://verisilicon.com/)'s generic API to operate GPU hardware as much as possible.
 
 Even with different chip manufacturers, as long as they use the same version of VG-Lite API as the rendering backend,
-LVGL rendering acceleration can be supported without the need for LVGL adaptation work.
+LVGL [rendering](/main-modules/draw) acceleration can be supported without the need for LVGL adaptation work.
 
 ## Configuration
 
-1. Set <ApiLink name="LV_USE_DRAW_VG_LITE" /> to 1 in `lv_conf.h` to enabled the VG-Lite rendering backend.
+1. Set <ApiLink name="LV_USE_DRAW_VG_LITE" /> to 1 in `lv_conf.h` to enable the VG-Lite rendering backend.
    Make sure that your hardware has been adapted to the VG-Lite API and that the absolute path to `vg_lite.h`, which can be directly referenced by lvgl, has been exposed.
 2. Confirm the GPU initialization method, there are two ways:
 
@@ -43,10 +43,10 @@ LVGL rendering acceleration can be supported without the need for LVGL adaptatio
 6. Set the <ApiLink name="LV_VG_LITE_GRAD_CACHE_CNT" /> configuration to specify the number of gradient cache entries.
    Gradient drawing includes linear gradients and radial gradients. Using a cache can effectively reduce the number of times the gradient image is created and improve drawing efficiency.
    Each individual gradient consumes around 4K of GPU memory pool. If there are many gradients used in the interface, you can try increasing the number of gradient cache entries.
-   If the VG-Lite API returns the <ApiLink name="VG_LITE_OUT_OF_RESOURCES" /> error, you can try increasing the size of the GPU memory pool or reducing the number of gradient cache entries.
+   If the VG-Lite API returns the `VG_LITE_OUT_OF_RESOURCES` error, you can try increasing the size of the GPU memory pool or reducing the number of gradient cache entries.
 7. Set the <ApiLink name="LV_VG_LITE_STROKE_CACHE_CNT" /> configuration to specify the number of stroke path caches.
    When the stroke parameters do not change, the previously generated stroke parameters are automatically retrieved from the cache to improve rendering performance.
-   The memory occupied by the stroke is strongly related to the path length. If the VG-Lite API returns the <ApiLink name="VG_LITE_OUT_OF_RESOURCES" /> error,
+   The memory occupied by the stroke is strongly related to the path length. If the VG-Lite API returns the `VG_LITE_OUT_OF_RESOURCES` error,
    you can try increasing the size of the GPU memory pool or reducing the number of stroke cache entries.
 
 NOTE: VG-Lite rendering backend does not support multi-threaded calls, please make sure <ApiLink name="LV_USE_OS" /> is always configured as <ApiLink name="LV_OS_NONE" />.

docs/src/integration/chip_vendors/renesas/built_in_drivers.mdx

@@ -20,6 +20,8 @@ Dave2D is capable of accelerating most of the drawing operations of LVGL:
 As Dave2D works in the background, the CPU is free for other tasks. In practice, during rendering, Dave2D can reduce the CPU usage by
 half to one-third, depending on the application.
 
+More info can be found at the [driver's page](/integration/chip_vendors/renesas/dave2d_gpu).
+
 ## GLCDC
 
 GLCDC is a multi-stage graphics output peripheral available in several Renesas MCUs. It is able to drive LCD panels via a highly

docs/src/integration/chip_vendors/renesas/glcdc.mdx

@@ -48,7 +48,7 @@ lv_display_set_default(disp);
 To use the driver in <ApiLink name="LV_DISPLAY_RENDER_MODE_PARTIAL" /> mode, an extra buffer must be allocated,
 preferably in the fastest available memory region.
 
-Buffer swapping can be activated by passing a second buffer of same size instead of the <ApiLink name="NULL" /> argument.
+Buffer swapping can be activated by passing a second buffer of same size instead of the `NULL` argument.
 
 ```c
 static lv_color_t partial_draw_buf[DISPLAY_HSIZE_INPUT0 * DISPLAY_VSIZE_INPUT0 / 10] BSP_PLACE_IN_SECTION(".sdram") BSP_ALIGN_VARIABLE(1024);
@@ -66,11 +66,11 @@ Partial mode can be activated via the macro in `src/board_init.c` file of the de
 Software based screen rotation is supported in partial mode. It uses the common API, no extra configuration is required:
 
 ```c
-lv_display_set_rotation(lv_display_get_default(), LV_DISP_ROTATION_90);
+lv_display_set_rotation(lv_display_get_default(), LV_DISPLAY_ROTATION_90);
 /* OR */
-lv_display_set_rotation(lv_display_get_default(), LV_DISP_ROTATION_180);
+lv_display_set_rotation(lv_display_get_default(), LV_DISPLAY_ROTATION_180);
 /* OR */
-lv_display_set_rotation(lv_display_get_default(), LV_DISP_ROTATION_270);
+lv_display_set_rotation(lv_display_get_default(), LV_DISPLAY_ROTATION_270);
 ```
 
 Make sure the heap is large enough, as a buffer with the same size as the partial buffer will be allocated.

docs/src/integration/chip_vendors/renesas/ra_family.mdx

@@ -25,11 +25,11 @@ Supported boards in the RA Family:
   repositories, recursive updating of the git submodules is no longer needed.
 - JLink is used for debugging, it can be downloaded [here](https://www.segger.com/downloads/jlink/).
 - Clone the ready-to-use repository for your selected board, for FSP version prior to 6.0:
-  
+
     ```bash
         git clone https://github.com/lvgl/lv_port_renesas_ek-ra8d1_gcc.git --recurse-submodules
     ```
-  
+
   Downloading the `.zip` from GitHub doesn't work as it doesn't download the submodules.
 
 - Clone the ready-to-use repository for your selected board, for FSP version from 6.0 and above:
@@ -42,29 +42,26 @@ Supported boards in the RA Family:
   `General` / `Existing projects into workspace`.
 - Select the cloned folder and press `Finish`.
 - Double-click on `configuration.xml`. This will activate the `Configuration Window`.
-  
+
   Renesas' Flexible Software Package (FSP) includes BSP and HAL layer support extended
   with multiple RTOS variants and other middleware stacks.  The components will be
   available via code generation, including the entry point in *"main.c"*.
-  
+
   Press `Generate Project Content` in the top right corner.
-  
-  .. image:: /_static/images/renesas/generate.png
-     :alt: Code generation with FSP
+
+  ![Code generation with FSP](/_static/images/renesas/generate.png)
 - Build the project by pressing `Ctrl` + `Alt` + `B`
 - Click the Debug button (![img_debug_btn](/_static/images/renesas/debug_btn.png)). If prompted with `Debug Configurations`,
   on the `Debugger` tab select the `J-Link ARM` as `Debug hardware` and the proper
   IC as `Target Device`:
-  
+
   - `R7FA8D1BH` for EK-RA8D1
-  
-    .. image:: /_static/images/renesas/debug_ra8.png
-       :alt: Debugger parameters for RA8
-  
+
+    ![Debugger parameters for RA8](/_static/images/renesas/debug_ra8.png)
+
   - `R7FA6M3AH` for EK-RA6M3G
-  
-    .. image:: /_static/images/renesas/debug_ra6.png
-       :alt: Debugger parameters for RA6
+
+    ![Debugger parameters for RA6](/_static/images/renesas/debug_ra6.png)
 
 <Callout type="info">
 On EK-RA8D1 boards, the `SW1` DIP switch 7 (in the middle of the board) should be
@@ -72,7 +69,7 @@ ON, all others are OFF.
 
 Also note opening a project previously built on top of the FSP prior to v6.0 will trigger
 a dialog asking whether the user wants to migrate to the new FSP v6.0. The migration will
-not break the project,.
+not break the project.
 </Callout>
 
 ## Modify the project
@@ -90,7 +87,7 @@ You can disable the LVGL demos (or just comment them out) and call some
 
 - <ApiLink name="LV_COLOR_DEPTH" /> to set LVGL's default color depth
 - <ApiLink name="LV_MEM_SIZE" /> to set the maximum RAM available to LVGL
-- <ApiLink name="LV_USE_DAVE2D" /> to enable the GPU
+- <ApiLink name="LV_USE_DRAW_DAVE2D" /> to enable the [Dave2D GPU](/integration/chip_vendors/renesas/dave2d_gpu)
 
 Hardware and software components can be modified in a visual way using the
 `Configuration Window`.

docs/src/integration/chip_vendors/renesas/rx_family.mdx

@@ -16,23 +16,22 @@ Supported boards in the RX Family:
   it runs on Windows, Linux, and Mac as well.  It can be downloaded
   [here](https://www.renesas.com/us/en/software-tool/e-studio).
 - Download and install the required driver for the debugger
-  
+
    - for Windows: [64 bit here](https://www.renesas.com/us/en/document/uid/usb-driver-renesas-mcu-tools-v27700-64-bit-version-windows-os?r=488806)
      and [32 bit here](https://www.renesas.com/us/en/document/uid/usb-driver-renesas-mcu-toolse2e2-liteie850ie850apg-fp5-v27700for-32-bit-version-windows-os?r=488806)
    - for Linux: [here](https://www.renesas.com/us/en/document/swo/e2-emulator-e2-emulator-lite-linux-driver?r=488806)
 - RX72 requires an external compiler for the RXv3 core. A free and open-source version is available
   [here](https://llvm-gcc-renesas.com/rx-download-toolchains/) after registration.
-  
+
   The compiler must be activated in e² studio:
-  
-  - Go to go to `Help` -> `Add Renesas Toolchains`
+
+  - Go to `Help` -> `Add Renesas Toolchains`
   - Press the `Add...` button
   - Select the installation folder of the toolchain
-  
-  .. image:: /_static/images/renesas/toolchains.png
-     :alt: Toolchains
+
+  ![Toolchains](/_static/images/renesas/toolchains.png)
 - Clone the ready-to-use [lv_port_renesas_rx72n-envision-kit](https://github.com/lvgl/lv_port_renesas_rx72n-envision-kit.git) repository:
-  
+
 ```bash
     git clone https://github.com/lvgl/lv_port_renesas_rx72n-envision-kit.git --recurse-submodules
 ```
@@ -42,21 +41,19 @@ Downloading the `.zip` from GitHub doesn't work as it doesn't download the submo
 - Open e² studio, go to `File` -> `Import project` and select `General` / `Existing projects into workspace`
 - Select the cloned folder and press `Finish`.
 - Double-click on `RX72N_EnVision_LVGL.scfg` to activate the `Configuration Window`.
-  
+
   Renesas' Smart Configurator (SMC) includes BSP and HAL layer support extended with
   multiple RTOS variants and other middleware stacks.  The components will be
   available via code generation, including the entry point of the application.
-  
+
   Press `Generate Code` in the top right corner.
-  
-  .. image:: /_static/images/renesas/generate_smc.png
-     :alt: Code generation with SMC
+
+  ![Code generation with SMC](/_static/images/renesas/generate_smc.png)
 - Build the project by pressing `Ctrl` + `Alt` + `B`
 - Click the Debug button (![img_debug_btn](/_static/images/renesas/debug_btn.png)). If prompted with `Debug Configurations`, on the `Debugger` tab select the `E2 Lite`
   as `Debug hardware` and `R5F572NN` as `Target Device`:
-  
-  .. image:: /_static/images/renesas/debug_rx72.png
-     :alt: Debugger parameters for RX72
+
+  ![Debugger parameters for RX72](/_static/images/renesas/debug_rx72.png)
 
 <Callout type="info">
 Make sure that both channels of `SW1` DIP switch (next to `ECN1`) are OFF.
@@ -77,7 +74,7 @@ You can disable the LVGL demos (or just comment them out) and call some
 
 - <ApiLink name="LV_COLOR_DEPTH" /> to set LVGL's default color depth
 - <ApiLink name="LV_MEM_SIZE" /> to set the maximum RAM available to LVGL
-- <ApiLink name="LV_USE_DAVE2D" /> to enable the GPU
+- <ApiLink name="LV_USE_DRAW_DAVE2D" /> to enable the [Dave2D GPU](/integration/chip_vendors/renesas/dave2d_gpu)
 
 Hardware and software components can be modified in a visual way using the
 `Configuration Window`.

docs/src/integration/chip_vendors/renesas/rzg_family.mdx

@@ -22,8 +22,8 @@ Supported boards in the RZ/G Family:
   version, even though LVGL is statically linked. You may try using newer versions of LVGL.
   See the [v8-to-v9 Migration Guide](https://docs.lvgl.io/9.0/CHANGELOG.html#migration-guide) for things you will need to address.
 - Clone the ready-to-use repository for your selected board:
-  
-  
+
+
 ```bash
     git clone https://github.com/lvgl/lv_port_renesas_rz-g2l-evkit --recurse-submodules
 ```
@@ -34,21 +34,21 @@ Downloading the `.zip` from GitHub doesn't work as it doesn't download the submo
   build, and upload the project to the board.
 - Stop any automatically started demos (on G2UL run `systemctl stop demo-launcher` in the terminal).
 - Run the project:
-  
+
 ```bash
     ./lvgl_demo_benchmark
 ```
 
 ### Modify the project
 
-##### Open a demo
+#### Open a demo
 
 The entry point is contained in `src/main.c`.
 
 You can disable the LVGL demos (`lv_demo_benchmark()`) (or just comment them out)
 and call some `lv_example_...()` functions, or add your own custom code.
 
-##### Configuration
+#### Configuration
 
 Edit `lv_conf.h` and `lv_drv_conf.h` to configure LVGL. The board image
 contains LVGL and lv_drivers as dynamically linkable libraries. This project builds
@@ -67,7 +67,7 @@ LVGL statically for customizability and to port the LVGL v9 benchmark from LVGL
 - LVGL is not included in the SDK so you should build whichever version you need. Later
   versions of LVGL include the optimal OpenGL driver.
 - Clone the ready-to-use repository:
-  
+
 ```bash
     git clone https://github.com/lvgl/lv_port_renesas_rz-g3e-evkit --recurse-submodules
 ```
@@ -78,21 +78,21 @@ Downloading the `.zip` from GitHub doesn't work as it doesn't download the submo
   Yocto SD Card image and SDK (pre-built or custom-built), build, and upload the project to the board.
 - Stop the Wayland desktop if using the OpenGL, DRM, or fbdev drivers. Run `systemctl stop weston` in the terminal.
 - Run the project:
-  
+
 ```bash
 ./lvglsim
 ```
 
 ### Modify the project
 
-##### Open a demo
+#### Open a demo
 
 The entry point is contained in `lv_port_linux/src/main.c`.
 
 You can disable the LVGL demos (`lv_demo_benchmark()`) (or just comment them out)
 and call some `lv_example_...()` functions, or add your own custom code.
 
-##### Configuration
+#### Configuration
 
 Edit `lv_conf.h` to configure LVGL. You can edit `lv_conf.defaults` --- a sparse
 version of `lv_conf.h` which you can use to regenerate `lv_conf.h` by running

docs/src/integration/chip_vendors/stm32/dma2d_gpu.mdx

@@ -54,9 +54,9 @@ other RTOS tasks while a DMA2D transfer is ongoing, do the following:
 
 ## Interop with LTDC and NeoChrom
 
-DMA2D usage can be freely mixed with LTDC usage as long as <ApiLink name="LV_ST_LTDC_USE_DMA2D_FLUSH" />
+DMA2D usage can be freely mixed with [LTDC](/integration/chip_vendors/stm32/ltdc) usage as long as <ApiLink name="LV_ST_LTDC_USE_DMA2D_FLUSH" />
 is **not** enabled. LTDC will use the DMA2D peripheral for flushing, if that is enabled.
 
-NeoChrom and DMA2D may be enabled at the same time. They are both draw units
+[NeoChrom](/integration/chip_vendors/stm32/neochrom) and DMA2D may be enabled at the same time. They are both draw units
 and they will both independently accept draw tasks.
 

docs/src/integration/chip_vendors/stm32/lcd_stm32_guide.mdx

@@ -3,10 +3,11 @@ title: SPI Display Driver Creation for STM32
 description: Here is how you can drive a RGB565 240x320 SPI display using STM32 HAL SPI. You can use direct or partial mode.
 ---
 
-### Display Driver
+## Display Driver
 
 Here is how you can drive a RGB565 240x320 SPI display using STM32 HAL SPI.
 You can use direct or partial mode. Single-buffered direct is shown in this example.
+See the [Display](/main-modules/display) module for general background on LVGL displays.
 
 In your initialization code, create the display and set the buffers and flush callback.
 
@@ -44,9 +45,9 @@ static void flush_cb(lv_display_t * disp, const lv_area_t * area, uint8_t * px_m
 
 Performance can be improved by using DMA with double buffering.
 
-### Touch indev
+## Touch indev
 
-In your initialization code, create the touch screen indev.
+In your initialization code, create the touch screen [input device](/main-modules/indev).
 
 ```c
 lv_indev_t * indev = lv_indev_create();

docs/src/integration/chip_vendors/stm32/ltdc.mdx

@@ -8,6 +8,7 @@ title: STM32 LTDC Display Driver
 
 Some STM32s have a specialized peripheral called
 LTDC (LCD-TFT Display Controller) for driving displays.
+See the [Display](/main-modules/display) module for general background on LVGL displays.
 
 ## Usage Modes With LVGL
 
@@ -58,7 +59,7 @@ size as the default framebuffer for double-buffered
 mode, or `NULL` otherwise. `my_ltdc_layer_index` is the layer index of the
 LTDC layer to create the display for.
 
-For the best visial results, `optional_other_full_size_buffer` should be used
+For the best visual results, `optional_other_full_size_buffer` should be used
 if enough memory is available. Single-buffered mode is what you should use
 if memory is very scarce. Chips with a CPU data cache have unavoidable visual
 artifacts when using single-buffered direct mode. If there is almost enough
@@ -134,13 +135,13 @@ disp = lv_st_ltdc_create_partial(partial_buf1,
 
 The driver supports display rotation with
 <ApiLink name="lv_display_set_rotation" display="lv_display_set_rotation(disp, rotation)" /> where rotation is one of
-<ApiLink name="LV_DISP_ROTATION_90" />, <ApiLink name="LV_DISP_ROTATION_180" />,
-or <ApiLink name="LV_DISP_ROTATION_270" />. The rotation is initially
-<ApiLink name="LV_DISP_ROTATION_0" />.
+<ApiLink name="LV_DISPLAY_ROTATION_90" />, <ApiLink name="LV_DISPLAY_ROTATION_180" />,
+or <ApiLink name="LV_DISPLAY_ROTATION_270" />. The rotation is initially
+<ApiLink name="LV_DISPLAY_ROTATION_0" />.
 
 The rotation is done in software and only works if the display was
 created using <ApiLink name="lv_st_ltdc_create_partial" />.
-<ApiLink name="LV_ST_LTDC_USE_DMA2D_FLUSH" /> will be have no effect if rotation
+<ApiLink name="LV_ST_LTDC_USE_DMA2D_FLUSH" /> will have no effect if rotation
 is used.
 
 ## Interop with the DMA2D and NeoChrom Draw Units

docs/src/integration/chip_vendors/stm32/neochrom.mdx

@@ -28,7 +28,7 @@ Enable the renderer by setting <ApiLink name="LV_USE_NEMA_GFX" /> to `1` in
 lv_conf.h.
 
 Set <ApiLink name="LV_USE_NEMA_LIB" /> to the correct version for the core in
-your MCU. If left as `LV_NEMA_LIB_NONE`, M33 RevC will be assumed.
+your MCU. If left as <ApiLink name="LV_NEMA_LIB_NONE" />, M33 RevC will be assumed.
 
 If using <ApiLink name="LV_USE_NEMA_VG" />,
 set <ApiLink name="LV_NEMA_GFX_MAX_RESX" /> and <ApiLink name="LV_NEMA_GFX_MAX_RESY" />
@@ -137,9 +137,9 @@ const lv_image_dsc_t img_demo_widgets_avatar_tsc6a = {
 
 ## Interop with the LTDC driver and the DMA2D Draw Unit
 
-NeoChrom can be enabled at the same time as LTDC. They will not interfere
+NeoChrom can be enabled at the same time as [LTDC](/integration/chip_vendors/stm32/ltdc). They will not interfere
 with each other at all.
 
-NeoChrom and DMA2D may be enabled at the same time. They are both draw units
+NeoChrom and [DMA2D](/integration/chip_vendors/stm32/dma2d_gpu) may be enabled at the same time. They are both draw units
 and they will both independently accept draw tasks.
 

docs/src/integration/embedded_linux/distros/buildroot/app_deployment.mdx

@@ -3,15 +3,15 @@ title: LVGL Application on Buildroot
 description: "How to build and deploy an LVGL application into a Buildroot rootfs overlay."
 ---
 
-# LVGL application
+## LVGL application
 
 This section provides information about the steps to follow to get a custom
 application using LVGL running on the board.
 
-## Update RootFS
+### Update RootFS
 
 Depending on the application, it might be necessary to update the rootfs. Let's
-take as example the compilation of LVGL with DRM. The system must have
+take as example the compilation of LVGL with [DRM](/integration/embedded_linux/drivers/drm). The system must have
 `libdrm` installed.
 
 ```bash
@@ -41,7 +41,7 @@ find build/ -name "*libdrm*"
 
 You should see the include folder and the .so files.
 
-## Generate SDK and set up environment
+### Generate SDK and set up environment
 
 Generate an SDK that you can use to cross-compile the application for the
 target (RPi4).
@@ -90,10 +90,10 @@ export CFLAGS="--sysroot=${SYSROOT}"
 export LDFLAGS="--sysroot=${SYSROOT}"
 ```
 
-## Build the application
+### Build the application
 
 The environment is now set up, and we're ready to build an application using
-the [lv_benchmark` repository that is inspired from `lv_port_linux](https://github.com/lvgl/lv_port_linux).
+the [`lv_benchmark`](https://github.com/EDGEMTech/lv_benchmark) repository, which is inspired by [`lv_port_linux`](https://github.com/lvgl/lv_port_linux).
 
 Navigate back to the root of the project and clone the repository:
 
@@ -124,7 +124,7 @@ The output should contain these information:
 - ARM aarch64
     - interpreter /lib/ld-linux-aarch64.so.1
 
-## Set a rootfs overlay
+### Set a rootfs overlay
 
 In Buildroot, a rootfs overlay (or root filesystem overlay) is a mechanism that
 allows you to add custom files, directories, and configurations directly into

docs/src/integration/embedded_linux/distros/buildroot/custom_image.mdx

@@ -3,7 +3,7 @@ title: Custom Buildroot Image
 description: "Step-by-step guide to creating a custom Buildroot image, using the Raspberry Pi 4 as an example. Adaptable to other boards."
 ---
 
-# Custom image for buildroot
+## Custom image for buildroot
 
 This chapter offers a detailed guide for creating a custom image for the
 Raspberry Pi 4 (RPi4). Key Buildroot components and concepts will be
@@ -33,8 +33,7 @@ Each folder utility will be explained throughout the guide.
 
 ## Get Buildroot
 
-First, according to the [Builroot Manual](https://buildroot.org/downloads/
-manual/manual.html), Buildroot requires certain packages to be installed
+First, according to the [Buildroot Manual](https://buildroot.org/downloads/manual/manual.html), Buildroot requires certain packages to be installed
 before starting the build. Lets install them using Ubuntu's package manager.
 
 ```bash
@@ -58,7 +57,7 @@ cd buildroot
 make list-defconfigs | grep rasp
 ```
 
-There is a build available for RPi4 62 bits: `raspberrypi4_64_defconfig`.
+There is a build available for RPi4 64 bits: `raspberrypi4_64_defconfig`.
 
 You can also find all the configurations in the Buildroot repository
 `buildroot > configs`
@@ -131,7 +130,7 @@ the `build` folder, where the build process takes place. It includes files
 such as configuration files, source code, and object files that are generated
 as part of the build process.
 
-# host
+### host
 
 The `host` folder contains files and binaries that are built for the host
 system rather than the target system. This includes tools and utilities that
@@ -139,14 +138,14 @@ are needed to build packages or to run the build system itself. It may contain
 compilers, build tools, and libraries that are required to support the build
 process for the target.
 
-# images
+### images
 
 This directory holds the final output images generated for the target system,
 such as filesystem images, kernel images, or bootloader images. Depending on
 the configuration, you may find files like `rootfs.tar`, `zImage`,
 `uImage`, or others that are ready to be deployed onto the target hardware.
 
-# target
+### target
 
 The `target` folder contains the files that are specifically intended for the
 target system. This includes the root filesystem and any additional files that

docs/src/integration/embedded_linux/distros/buildroot/quick_start.mdx

@@ -3,7 +3,7 @@ title: Quick Start
 description: "Get up and running quickly with a pre-configured Buildroot setup for LVGL."
 ---
 
-# Quick Start
+## Quick Start
 
 A Git repository is available that includes everything needed to test the
 Buildroot setup without following the guide. It is intended for testing

docs/src/integration/embedded_linux/distros/torizon.mdx

@@ -12,7 +12,7 @@ instead of building and maintaining a custom distribution.
 This guide explains how to create a docker image containing LVGL and a simple demo
 application that can be deployed on any Toradex device running TorizonOS.
 
-### Prerequisites
+## Prerequisites
 
 To follow this guide you obviously need to have a Toradex SoM along with a carrier board.
 More information is available on the Toradex [website](https://www.toradex.com/computer-on-modules).
@@ -25,7 +25,7 @@ this guide. Also Docker needs to be present on the development host.
 The [Toradex documentation](https://developer.toradex.com) is a helpful resource. This article contains many references
 to it.
 
-### Board setup
+## Board setup
 
 Begin by installing TorizonOS by using the Toradex Easy Installer.
 Follow the official bring-up [guides](https://developer.toradex.com/quickstart/bringup/).
@@ -37,16 +37,16 @@ The address is displayed in the bottom right corner. It will be used later.
 
 Once the setup is complete, the device will boot into TorizonOS.
 
-### VS Code extension
+## VS Code extension
 
-Toradex provides a [VS Code extension](https://developer.toradex.com/torizon/application-development/ide-extension/) that offers a collection of templates used 
+Toradex provides a [VS Code extension](https://developer.toradex.com/torizon/application-development/ide-extension/) that offers a collection of templates used
 to configure and automate the tasks needed to cross-compile applications and build Docker images.
 
 These templates now include support for LVGL applications, available as one of the [partner templates](https://github.com/torizon/vscode-torizon-templates?tab=readme-ov-file#partner-templates).
 
 This guide explains how to perform those operations manually.
 
-### Creating the Docker image
+## Creating the Docker image
 
 To build a Torizon container for ARM on your development machine, you need to enable Docker emulation.
 Run the following commands to enable it:
@@ -78,7 +78,7 @@ These commands create the project directory and the `Dockerfile`.
 `git` is used to download the `lv_port_linux` and `lvgl` repositories from Github.
 
 <Callout type="info">
-By default, `lv_port_linux` is configured to use the legacy framebuffer device
+By default, `lv_port_linux` is configured to use the legacy [framebuffer](/integration/embedded_linux/drivers/fbdev) device
 `/dev/fb0`. It is also possible to use another rendering backend by enabling the
 correct options in `lv_port_linux/lv_conf.h`.
 </Callout>
@@ -131,10 +131,10 @@ The `Dockerfile` acts like a recipe to build two images:  `build` and `deploy`.
 
 First it downloads the necessary packages to build the simulator using Debian's package manager `apt-get`.
 
-After compilation, the resulting executable is written to `lv_port_linux/bin/lvglsim`.
+After compilation, the resulting executable is written to `/app/build/bin/lvglsim`.
 
 The `deploy` image will be deployed on the device.
-The executable created in the previous image is copied to the `/usr/bin` directory of the current image.
+The executable created in the previous image is copied to the `/usr/lvgl_widgets` path of the current image.
 
 This creates a smaller image that does not include the tool chain and the build dependencies.
 
@@ -156,7 +156,7 @@ lvgl_app                  latest    2967a34a9e74   2 minutes ago    118MB
 
 Alongside the image name, you'll also find its ID (`2967a34a9e74` in this example). This will be useful for later.
 
-### Deploying the container image to the device
+## Deploying the container image to the device
 
 The image is now ready to be deployed on the device. There are several ways to perform
 this task.
@@ -191,7 +191,7 @@ Get the IP address of the development host and open a remote shell on the device
 ```sh
 sudo su # When prompted type in the password of the torizon user
 
-# Be sure to replace set the IP address of your host instead
+# Be sure to set the IP address of your host instead
 cat << heredoc > /etc/docker/daemon.json
 {
      "insecure-registries" : ["<IP_ADDR_OF_DEVELOPMENT_HOST>:5000"]
@@ -221,14 +221,14 @@ Start the container like so, using the image ID:
 docker run --device /dev/fb0:/dev/fb0 <IMAGE_ID>
 ```
 
-### Conclusion
+## Conclusion
 
 You now have a running LVGL application. Where to go from here?
 
 - You are now ready to build your LVGL application for Torizon OS.
   It is recommended to get familiar with VSCode IDE extension
   as it will simplify your workflow.
-  
+
   If you are a VSCode user, it is the best way to develop for Torizon OS. If you use
   another editor or IDE you can always
   write scripts to automate the building/pushing/pulling operations.

docs/src/integration/embedded_linux/distros/yocto/core_components.mdx

@@ -29,8 +29,7 @@ responsible for parsing the Metadata, generating a list of tasks from it, and
 then executing those tasks.
 
 This section briefly introduces BitBake. If you want more information on
-BitBake, see the [BitBake User Manual](https://docs.yoctoproject.org/bitbake/2.
-8/index.html).
+BitBake, see the [BitBake User Manual](https://docs.yoctoproject.org/bitbake/2.8/index.html).
 
 To see a list of the options BitBake supports, use either of the
 following commands:
@@ -52,8 +51,7 @@ $ bitbake matchbox-desktop
 
 the one selected by the distribution configuration. You can get more details
 about how BitBake chooses between different target versions and providers in the
-"[Preferences](https://docs.yoctoproject.org/bitbake/2.8/bitbake-user-manual/
-bitbake-user-manual-execution.html#preferences)" section of the BitBake User
+"[Preferences](https://docs.yoctoproject.org/bitbake/2.8/bitbake-user-manual/bitbake-user-manual-execution.html#preferences)" section of the BitBake User
 Manual.
 
 BitBake also tries to execute any dependent tasks first. So for example,
@@ -86,27 +84,24 @@ using the term "package" when referring to recipes.
 Class files (`.bbclass`) contain information that is useful to share
 between recipes files. An example is the autotools* class,
 which contains common settings for any application that is built with
-the `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>[.
-The "`Classes](https://docs.yoctoproject.org/ref-manual/classes.
-html#classes)" chapter in the Yocto Project
+[GNU Autotools](https://en.wikipedia.org/wiki/GNU_Autotools).
+The "[Classes](https://docs.yoctoproject.org/ref-manual/classes.html#classes)" chapter in the Yocto Project
 Reference Manual provides details about classes and how to use them.
 
 ## Configurations
 
-The configuration files ([.conf`) define various configuration
+The configuration files (`.conf`) define various configuration
 variables that govern the OpenEmbedded build process. These files fall
 into several areas that define machine configuration options,
 distribution configuration options, compiler tuning options, general
 common configuration options, and user configuration options in
-`conf/local.conf`, which is found in the `Build Directory](https://docs.
-yoctoproject.org/ref-manual/terms.html#term-Build-Directory).
+`conf/local.conf`, which is found in the [Build Directory](https://docs.yoctoproject.org/ref-manual/terms.html#term-Build-Directory).
 
 ## Layers
 
 Layers are repositories that contain related metadata (i.e. sets of
 instructions) that tell the OpenEmbedded build system how to build a
-target. [The yocto project layer model](https://docs.yoctoproject.org/
-overview-manual/yp-intro.html#the-yocto-project-layer-model)
+target. [The yocto project layer model](https://docs.yoctoproject.org/overview-manual/yp-intro.html#the-yocto-project-layer-model)
 facilitates collaboration, sharing, customization, and reuse within the
 Yocto Project development environment. Layers logically separate
 information for your project. For example, you can use a layer to hold
@@ -116,16 +111,12 @@ using a different layer where that metadata might be common across
 several pieces of hardware.
 
 There are many layers working in the Yocto Project development environment. The
-[Yocto Project Compatible Layer Index](https://www.yoctoproject.org/development/
-yocto-project-compatible-layers/) and [OpenEmbedded Layer Index](https://
-layers.openembedded.org/layerindex/branch/master/layers/) both contain layers
-from
-which you can use or leverage.
+[Yocto Project Compatible Layer Index](https://www.yoctoproject.org/development/yocto-project-compatible-layers/) and [OpenEmbedded Layer Index](https://layers.openembedded.org/layerindex/branch/master/layers/) both contain layers
+from which you can use or leverage.
 
 By convention, layers in the Yocto Project follow a specific form. Conforming
 to a known structure allows BitBake to make assumptions during builds on where
 to find types of metadata. You can find procedures and learn about tools (i.e.
-[bitbake-layers`) for creating layers suitable for the Yocto Project in the
-"`understanding and creating layers](https://docs.yoctoproject.org/dev-manual/
-layers.html#understanding-and-creating-layers)" section of the
+`bitbake-layers`) for creating layers suitable for the Yocto Project in the
+"[understanding and creating layers](https://docs.yoctoproject.org/dev-manual/layers.html#understanding-and-creating-layers)" section of the
 Yocto Project Development Tasks Manual.

docs/src/integration/embedded_linux/distros/yocto/lvgl_recipe.mdx

@@ -21,8 +21,7 @@ liblz4-tool file locales libacl1
 
 <Callout type="info">
 For host package requirements on all supported Linux distributions, see the
-[Required Packages for the Build Host](https://docs.yoctoproject.org/
-ref-manual/system-requirements.html#required-packages-for-the-build-host)
+[Required Packages for the Build Host](https://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host)
 section in the Yocto Project Reference Manual.
 </Callout>
 
@@ -138,7 +137,7 @@ bitbake-layers show-layers
 - networking-layer
 - meta-python
 
-# Build for RaspberryPi3 64
+## Build for RaspberryPi3 64
 
 The available machine configurations for Raspberrypi can be listed like this
 
@@ -169,8 +168,6 @@ Everything is setup, time to build the image:
 bitbake core-image-base
 ```
 
-=====================
-
 Let's go through the build folders to understand what happened.
 
 ### Downloads
@@ -194,9 +191,9 @@ There are some key folders:
 - **images**: it contains the images that can be flashed or deployed to
    the target device. Files like the Linux kernel, root filesystem (e.g.,
    .ext4, .tar.gz, .squashfs), bootloaders (e.g., U-Boot), and other
-   bootable images for the device are found here. t's organized by the
+   bootable images for the device are found here. It's organized by the
    machine (or target board) for which the image was built.
-- **rmp/deb/ipk**: These folders contain the individual software packages
+- **rpm/deb/ipk**: These folders contain the individual software packages
    generated during the build, in the specified package format (RPM, DEB,
    or IPK). These packages are typically created when you're building your
    Yocto project with package management support enabled. These can later
@@ -282,7 +279,6 @@ There is a recipe in `meta-openembedded` since `honister`.
 | nanbield (Yocto Project 4.3) | lvgl 8.3.10 |
 | mickledore (Yocto Project 4.2) | lvgl 8.1.0 |
 | langdale (Yocto Project 4.1) | lvgl 8.1.0 |
-| langdale (Yocto Project 4.1) | lvgl 8.1.0 |
 | kirkstone (Yocto Project 4.0) | lvgl 8.0.3 |
 
 In this guide, we are on the `scarthgap` branch, so we are using lvgl 9.1.0.
@@ -291,8 +287,7 @@ Let's dive into this recipe to understand what is done. The objective is to add
 this library as a shared object in the target rootfs, and also to generate a
 SDK with lvgl.
 
-This is the path of lvgl recipes: `lvgl_yocto_guide/sources/meta-openembedded/
-meta-oe/recipes-graphics/lvgl`
+This is the path of lvgl recipes: `lvgl_yocto_guide/sources/meta-openembedded/meta-oe/recipes-graphics/lvgl`
 
 Here is the architecture of lvgl recipes folder:
 
@@ -415,11 +410,9 @@ The fetch Repo address has to be stored in **SRC_URI** variable. In
 When the fetch task has been completed, you can find the fetched sources in
    `build/downloads`.
 
-For this recipe, you will find a new folder here: `lvgl_yocto_guide
-   build/downloads/git2/github.com.lvgl.lvgl`.
+For this recipe, you will find a new folder here: `lvgl_yocto_guide/build/downloads/git2/github.com.lvgl.lvgl`.
 
-You can also find the folder architecture created in `lvgl_yocto_guide/
-   build/tmp/work/cortexa53-poky-linux/lvgl` but these folders are empty since
+You can also find the folder architecture created in `lvgl_yocto_guide/build/tmp/work/cortexa53-poky-linux/lvgl` but these folders are empty since
    only the fetch was done.
 
 Unpack (do_unpack)
@@ -466,8 +459,7 @@ In this case, it creates a build directory, It invokes CMake to configure
    recipe. It generates Makefiles or project files needed for the build. Also,
    there are operations added in the task in `lv-conf.inc`.
 
-So at the end of the task, in the `lvgl_yocto_guide/build/tmp/work/
-   cortexa53-poky-linux/lvgl/9.1.0`, you will find a `build` folder that was
+So at the end of the task, in the `lvgl_yocto_guide/build/tmp/work/cortexa53-poky-linux/lvgl/9.1.0`, you will find a `build` folder that was
    generated running the CMake command, but nothing is built yet. Also, the
    sysroots have everything required to build lvgl library.
 
@@ -488,7 +480,7 @@ If there are any compilation steps, then these steps are define in
 Like in the previous task, this is handle by `inherit cmake`.
 
 In the build folder, you can now see the built library. The `.so` files
-   are available in `lvgl_yocto_guide/build/tmp/work/ cortexa53-poky-linux/lvgl/9.1.0/build/lib`.
+   are available in `lvgl_yocto_guide/build/tmp/work/cortexa53-poky-linux/lvgl/9.1.0/build/lib`.
 
 After this task has been completed, everything is ready to be installed.
 
@@ -523,14 +515,13 @@ TOOLCHAIN_HOST_TASK:append = " lvgl"
 This will add the lvgl library in the generated image, and it will also add
 the library to the host SDK we will generate later on.
 
-With these modifications, you can now run the image recipe again::
+With these modifications, you can now run the image recipe again:
 
 bitbake core-image-base
 
-This will execute all the previous described tasks.
+This will execute all the previously described tasks.
 
-If everything went well, you should now found this file `build/tmp/deploy/
-rpm/cortexa53/lvgl-9.1.0-r0.cortexa53.rpm` and other rpm files related to
+If everything went well, you should now find this file `build/tmp/deploy/rpm/cortexa53/lvgl-9.1.0-r0.cortexa53.rpm` and other rpm files related to
 lvgl.
 </Callout>
 
@@ -553,7 +544,7 @@ purposes, particularly in embedded development:
       Developers don't need to manually install and configure tools and
       libraries; everything needed is included in the SDK.
     - **Consistent Build Environment**: The SDK ensures that developers are
-      working with the same versions of and tools used in the Yocto
+      working with the same versions of libraries and tools used in the Yocto
       build, which helps to avoid compatibility issues and ensures that
       applications will behave as expected on the target device.
 
@@ -580,7 +571,7 @@ If you want to ensure the SDK was generated with lvgl being installed, go to
 the path you extracted the SDK and find all lvgl files:
 
 ```bash
-cd /opt/poky/5.0.4/sysroots/cortexa53-poky-linux
+cd /opt/poky/sdk-with-lvgl/sysroots/cortexa53-poky-linux
 find . -name "*lvgl*"
 ```
 
@@ -589,7 +580,7 @@ The `.so` files you will find will depend on the LVGL configuration you used.
 Now to use the SDK environment and cross-compile an application:
 
 ```bash
-source /opt/poke/5.0.4/environment-setup-cortexa53-poky-linux
+source /opt/poky/sdk-with-lvgl/environment-setup-cortexa53-poky-linux
 ```
 
 <Callout type="info">
@@ -603,7 +594,7 @@ Until this section, everything was already done for you. We used existing
 recipes. The objective here is to create a recipe from scratch and to add the
 generated binary in the image.
 
-# Create a layer
+### Create a layer
 
 First, create a layer and add it to the configuration file
 
@@ -625,7 +616,7 @@ directory tree should look like the following
         └── example_0.1.bb
 ```
 
-# Create a recipe
+### Create a recipe
 
 Following this structure, create a folder containing the recipes to build 1
 or multiple applications using lvgl
@@ -668,7 +659,7 @@ do_install() {
 
 The sources come from `lv_port_linux` repository. We apply 2 patches to modify the `CMakeLists.txt` and `lv_conf.h`.
 
-### Patch 1
+#### Patch 1
 
 Create the first patch file
 
@@ -790,9 +781,9 @@ index 62a834f..58fbe7a 100644
 2.34.1
 ```
 
-### Patch 2
+#### Patch 2
 
-Create the first patch file
+Create the second patch file
 
 ```c
 touch 0002-adapt-CMakeLists-file-to-compile-and-link-fbdev.patch
@@ -848,7 +839,7 @@ target_include_directories(lvgl PUBLIC ${PROJECT_SOURCE_DIR})
 2.34.1
 ```
 
-# Build the recipe
+### Build the recipe
 
 You should now be able to see the recipe listing the existing recipes
 

docs/src/integration/embedded_linux/distros/yocto/terms_and_variables.mdx

@@ -1,14 +1,13 @@
 ---
 title: Yocto Project Terms
-description: Getting started in Yocto can be overwheming. There are many terms used that are specific to Yocto and Bitbake environment.
+description: Getting started in Yocto can be overwhelming. There are many terms used that are specific to Yocto and Bitbake environment.
 ---
 
-Getting started in Yocto can be overwheming. There are many terms used that are
+Getting started in Yocto can be overwhelming. There are many terms used that are
 specific to Yocto and Bitbake environment.
 
 A list of terms and definitions users new to the Yocto Project
-development environment might find helpful can be found [here](https://docs.
-yoctoproject.org/ref-manual/terms.html).
+development environment might find helpful can be found [here](https://docs.yoctoproject.org/ref-manual/terms.html).
 
 ## Yocto Variables Glossary
 
@@ -160,8 +159,7 @@ package contents or metadata.
 
 Because manually managing PR can be cumbersome and error-prone,
 an automated solution exists. See the
-"[working with a pr service](https://docs.yoctoproject.org/dev-manual/packages.
-html#working-with-a-pr-service)" section in the Yocto Project Development
+"[working with a pr service](https://docs.yoctoproject.org/dev-manual/packages.html#working-with-a-pr-service)" section in the Yocto Project Development
 Tasks Manual for more information.
 
 PV

docs/src/integration/embedded_linux/draw_units/draw_nanovg.mdx

@@ -3,7 +3,7 @@ title: NanoVG Draw Unit
 description: "NanoVG is a lightweight, antialiased 2D vector graphics library built on top of OpenGL/OpenGL ES. The NanoVG draw unit integrates NanoVG as a hardware-accelerated rendering backend for LVGL, provide..."
 ---
 
-# Introduction
+## Introduction
 
 NanoVG is a lightweight, antialiased 2D vector graphics library built on top of OpenGL/OpenGL ES.
 The NanoVG draw unit integrates NanoVG as a hardware-accelerated rendering backend for LVGL,
@@ -17,13 +17,13 @@ Unlike the software renderer, NanoVG leverages the GPU for:
 - Box shadows and gradients
 - Vector graphics support
 
-# Requirements
+## Requirements
 
 - OpenGL 2.0+ / OpenGL ES 2.0+ / OpenGL ES 3.0+
 - An initialized OpenGL context (via GLFW, EGL, or custom setup)
 - Stencil buffer support (8-bit recommended)
 
-# Configuration
+## Configuration
 
 Enable the NanoVG draw unit in `lv_conf.h`:
 
@@ -47,7 +47,7 @@ Enable the NanoVG draw unit in `lv_conf.h`:
 #define LV_NANOVG_FBO_CACHE_CNT    8   /* Framebuffer object cache entries */
 ```
 
-# Supported Features
+## Supported Features
 
 The NanoVG draw unit supports all standard LVGL drawing operations:
 
@@ -66,7 +66,7 @@ The NanoVG draw unit supports all standard LVGL drawing operations:
 | Canvas | Direct drawing to canvas buffers |
 | Vector Graphics | SVG-style path rendering (requires `LV_USE_VECTOR_GRAPHIC`) |
 
-# Supported Image Formats
+## Supported Image Formats
 
 NanoVG supports zero-copy texture upload for these LVGL color formats:
 
@@ -78,14 +78,14 @@ NanoVG supports zero-copy texture upload for these LVGL color formats:
 | `LV_COLOR_FORMAT_RGB888` | BGR→RGB swizzle | No alpha channel |
 | `LV_COLOR_FORMAT_RGB565` | Direct upload | Note: LVGL uses BGR565 layout |
 
-# Performance Tips
+## Performance Tips
 
 1. **Minimize Layer Usage**: Each layer requires a framebuffer object (FBO) switch
 2. **Use Premultiplied Alpha**: Set `LV_IMAGE_FLAGS_PREMULTIPLIED` for pre-processed images
 3. **Cache Static Content**: NanoVG caches textures automatically; avoid recreating images
 4. **Batch Similar Operations**: Group widgets with similar styles for better GPU batching
 
-# Limitations
+## Limitations
 
 - **Blur**: Not natively supported; Using this style will not affect the rendering results.
 - **Complex Gradients**: Limited to 2-color gradients (LVGL supports multi-stop)

docs/src/integration/embedded_linux/draw_units/draw_opengl.mdx

@@ -3,9 +3,7 @@ title: OpenGL ES Draw Unit
 description: "The OpenGL ES Draw Unit provides a hardware-accelerated rendering backend for LVGL that leverages OpenGL ES capabilities."
 ---
 
-## Introduction
-
-# Overview
+## Overview
 
 The OpenGL ES Draw Unit provides a hardware-accelerated rendering backend for LVGL that leverages OpenGL ES capabilities.
 
@@ -35,7 +33,7 @@ The OpenGL ES Draw Unit provides excellent performance for:
 
 ## Configuration
 
-# Enable in lv_conf.h
+Enable the OpenGL ES draw unit in `lv_conf.h`:
 
 ```c
 #define LV_USE_OPENGLES 1

docs/src/integration/embedded_linux/draw_units/draw_sdl.mdx

@@ -3,9 +3,7 @@ title: SDL Draw Unit
 description: "The SDL Draw Unit provides a hardware-accelerated rendering backend for LVGL that leverages SDL2's texture system. It uses software rendering to create SDL textures which are then cached and effici..."
 ---
 
-## Introduction
-
-# Overview
+## Overview
 
 The SDL Draw Unit provides a hardware-accelerated rendering backend for LVGL that leverages SDL2's texture system.
 It uses software rendering to create SDL textures which are then cached and efficiently blended together by the GPU to compose the final UI.
@@ -33,7 +31,7 @@ The SDL Draw Unit excels in scenarios with:
 
 ## Configuration
 
-# Enable in lv_conf.h
+Enable the SDL draw unit in `lv_conf.h`:
 
 ```c
 #define LV_USE_SDL 1

docs/src/integration/embedded_linux/drivers/X11.mdx

@@ -3,7 +3,7 @@ title: X11
 description: The X11 display/input driver offers support for simulating the LVGL display and keyboard/mouse inputs in an X11 desktop window.
 ---
 
-### Overview
+## Overview
 
 The **X11** display/input [driver](https://github.com/lvgl/lvgl/tree/master/src/drivers/x11)
 offers support for simulating the LVGL display and keyboard/mouse inputs in an X11
@@ -14,14 +14,14 @@ It is an alternative to **Wayland**, **XCB**, **SDL** or **Qt**.
 The main purpose for this driver is for testing/debugging the LVGL application in a
 **Linux** simulation window.
 
-### Prerequisites
+## Prerequisites
 
 The X11 driver uses XLib to access the linux window manager.
 
 1. Install XLib: `sudo apt-get install libx11-6` (should be installed already)
 2. Install XLib development package: `sudo apt-get install libx11-dev`
 
-### Configure X11 driver
+## Configure X11 driver
 
 1. Enable the X11 driver support in lv_conf.h, by cmake compiler define or by KConfig
 
@@ -32,34 +32,34 @@ The X11 driver uses XLib to access the linux window manager.
 2. Optional configuration options:
     -  Direct Exit
 
-    ```c
-    #define LV_X11_DIRECT_EXIT  1 /* preferred default - ends the application automatically if last window has been closed */
-    // or
-    #define LV_X11_DIRECT_EXIT  0 /* application is responsible for ending the application (e.g. by own LV_EVENT_DELETE handler) */
-    ```
+        ```c
+        #define LV_X11_DIRECT_EXIT  1 /* preferred default - ends the application automatically if last window has been closed */
+        // or
+        #define LV_X11_DIRECT_EXIT  0 /* application is responsible for ending the application (e.g. by own LV_EVENT_DELETE handler) */
+        ```
 
--  Double buffering
+    -  Double buffering
 
-    ```c
-    #define LV_X11_DOUBLE_BUFFER  1 /* preferred default */
-    // or
-    #define LV_X11_DOUBLE_BUFFER  0 /* not recommended */
-    ```
+        ```c
+        #define LV_X11_DOUBLE_BUFFER  1 /* preferred default */
+        // or
+        #define LV_X11_DOUBLE_BUFFER  0 /* not recommended */
+        ```
 
-- Render mode
+    - Render mode
 
-    ```c
-    #define LV_X11_RENDER_MODE_PARTIAL 1  /* LV_DISPLAY_RENDER_MODE_PARTIAL, preferred default */
-    // or
-    #define LV_X11_RENDER_MODE_DIRECT  1  /* LV_DISPLAY_RENDER_MODE_DIRECT, not recommended for X11 driver */
-    // or
-    #define LV_X11_RENDER_MODE_DULL    1  /* LV_DISPLAY_RENDER_MODE_FULL, not recommended for X11 driver */
-    ```
+        ```c
+        #define LV_X11_RENDER_MODE_PARTIAL 1  /* LV_DISPLAY_RENDER_MODE_PARTIAL, preferred default */
+        // or
+        #define LV_X11_RENDER_MODE_DIRECT  1  /* LV_DISPLAY_RENDER_MODE_DIRECT, not recommended for X11 driver */
+        // or
+        #define LV_X11_RENDER_MODE_FULL    1  /* LV_DISPLAY_RENDER_MODE_FULL, not recommended for X11 driver */
+        ```
 
-### Usage
+## Usage
 
-| The minimal initialisation opening a window and enabling keyboard/mouse support
-| (e.g. in main.c, LV_X11_DIRECT_EXIT must be 1):
+The minimal initialisation opening a window and enabling keyboard/mouse support
+(e.g. in main.c, LV_X11_DIRECT_EXIT must be 1):
 
 ```c
 int main(int argc, char ** argv)
@@ -84,8 +84,8 @@ int main(int argc, char ** argv)
 }
 ```
 
-| Full initialisation with mouse pointer symbol and own application exit handling
-| (dependent on LV_X11_DIRECT_EXIT (can be 1 or 0))
+Full initialisation with mouse pointer symbol and own application exit handling
+(dependent on LV_X11_DIRECT_EXIT (can be 1 or 0))
 
 ```c
 bool terminated = false;
@@ -95,7 +95,7 @@ static void on_close_cb(lv_event_t * e)
 {
     ...
 
-    terminate = true;
+    terminated = true;
 }
 #endif