diff --git a/docs/src/details/common-widget-features/scrolling.rst b/docs/src/details/common-widget-features/scrolling.rst index d1bdbfe3f4..56a98483fa 100644 --- a/docs/src/details/common-widget-features/scrolling.rst +++ b/docs/src/details/common-widget-features/scrolling.rst @@ -76,7 +76,9 @@ inherit the base direction. ``pad_left/right/top/bottom`` sets the spacing around the scrollbars, ``width`` sets the scrollbar's width and ``length`` sets the scrollbar's length: -If `length` is not set or left at `0` the scrollbar's length will be set automatically according to the length of the content. +If `length` is not set or left at `0` the scrollbar's length will be set automatically +according to the length of the content. + .. code-block:: c static lv_style_t style_scrollbar; diff --git a/docs/src/details/common-widget-features/styles/styles.rst b/docs/src/details/common-widget-features/styles/styles.rst index 9de48e4533..12b7971fbf 100644 --- a/docs/src/details/common-widget-features/styles/styles.rst +++ b/docs/src/details/common-widget-features/styles/styles.rst @@ -59,7 +59,7 @@ A style can be added to any state or state combination. For example, setting a different background color for the default and pressed states. If a property is not defined in a state the best matching state's property will be used. Typically this means the property with -:cpp:enumerator:`LV_STATE_DEFAULT` is used.˛ If the property is not set even for the +:cpp:enumerator:`LV_STATE_DEFAULT` is used. If the property is not set even for the default state the default value will be used. (See later) Since :cpp:enumerator:`LV_PART_MAIN` and :cpp:enumerator:`LV_STATE_DEFAULT` both diff --git a/docs/src/details/integration/chip/nxp.rst b/docs/src/details/integration/chip/nxp.rst index 675109964c..d46bc003cc 100644 --- a/docs/src/details/integration/chip/nxp.rst +++ b/docs/src/details/integration/chip/nxp.rst @@ -2,6 +2,8 @@ NXP === +.. |deg| unicode:: U+000B0 .. DEGREE SIGN + NXP has integrated LVGL into the MCUXpresso SDK packages for several of our microcontrollers as an optional software component, allowing easy evaluation and migration into your product design. LVGL is a free and open-source embedded @@ -40,6 +42,7 @@ individually as well simultaneously with the CPU (in LVGL multithreading mode). PXP accelerator ~~~~~~~~~~~~~~~ + Basic configuration: ^^^^^^^^^^^^^^^^^^^^ @@ -48,7 +51,7 @@ Basic configuration: - In order to use PXP to rotate the screen, select in "lv_conf.h": Set :c:macro:`LV_USE_ROTATE_PXP` to `1`. - Enable PXP asserts in "lv_conf.h": Set :c:macro: `LV_USE_PXP_ASSERT` to `1`. There are few PXP assertions that can stop the program execution in case the - c:macro:`LV_ASSERT_HANDLER` is set to `while(1);` (Halt by default). Else, + :c:macro:`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 :c:macro:`SDK_OS_FREE_RTOS` symbol is defined, FreeRTOS implementation will be used, otherwise bare metal code will be included. @@ -220,7 +223,7 @@ Basic configuration: - Enable VGLite asserts in "lv_conf.h": Set :c:macro: `LV_USE_VGLITE_ASSERT` to `1`. VGLite assertions will verify the driver API status code and in any error, it - can stop the program execution in case the c:macro: `LV_ASSERT_HANDLER` is set + can stop the program execution in case the :c:macro: `LV_ASSERT_HANDLER` is set to `while(1);` (Halt by default). Else, there will be logged just an error message via `LV_LOG_ERROR`. @@ -425,7 +428,7 @@ Basic configuration: - In order to use G2D as a draw unit, select in "lv_conf.h": Set :c:macro:`LV_USE_DRAW_G2D` to `1`. - Enable G2D asserts in "lv_conf.h": Set :c:macro: `LV_USE_G2D_ASSERT` to `1`. There are few G2D assertions that can stop the program execution in case the - c:macro: `LV_ASSERT_HANDLER` is set to `while(1);` (Halt by default). Else, + :c:macro: `LV_ASSERT_HANDLER` is set to `while(1);` (Halt by default). Else, there will be logged just an error message via `LV_LOG_ERROR`. Basic initialization: @@ -505,7 +508,7 @@ Supported draw tasks are available in "src/draw/nx/g2d/lv_draw_g2d.c": Known limitations: ^^^^^^^^^^^^^^^^^^ -- G2D/PXP can only rotate at 90x angles. +- G2D/PXP can only rotate at 90\ |deg| angles. - Rotation is not supported for images unaligned to blocks of 16x16 pixels. G2D/PXP is set to process 16x16 blocks to optimize the system for memory bandwidth and image processing time. The output engine essentially truncates any output diff --git a/docs/src/details/integration/chip/renesas/ra_family.rst b/docs/src/details/integration/chip/renesas/ra_family.rst index db60a30617..e9bd609b00 100644 --- a/docs/src/details/integration/chip/renesas/ra_family.rst +++ b/docs/src/details/integration/chip/renesas/ra_family.rst @@ -108,7 +108,7 @@ Configuration Hardware and software components can be modified in a visual way using the ``Configuration Window``. -As of e2studio 2025-04.1 and FSP 6.0.0, LVGL is a managed component. +As of e\ |sup2| Studio 2025-04.1 and FSP 6.0.0, LVGL is a managed component. diff --git a/docs/src/details/integration/chip/renesas/rza_family.rst b/docs/src/details/integration/chip/renesas/rza_family.rst index 8d713cc3aa..aeb05fc24d 100644 --- a/docs/src/details/integration/chip/renesas/rza_family.rst +++ b/docs/src/details/integration/chip/renesas/rza_family.rst @@ -2,6 +2,8 @@ RZ/A Family =========== +.. |sup2| unicode:: U+000B2 .. SUPERSCRIPT TWO + Supported boards in the RZ/A Family: - **RZ/A3M** @@ -11,7 +13,7 @@ Supported boards in the RZ/A Family: Run the Project *************** -- The RZ/A boards are MPUs with a focus on baremetal and RTOS applications. Projects are built for them using e2 Studio IDE, available for Windows, Mac, and Linux. +- The RZ/A boards are MPUs with a focus on bare metal and RTOS applications. Projects are built for them using e\ |sup2| Studio IDE, available for Windows, Mac, and Linux. - Clone the ready-to-use repository for your board: .. code-block:: shell diff --git a/docs/src/details/integration/driver/X11.rst b/docs/src/details/integration/driver/X11.rst index 0ed8246cf6..c7991bd1e5 100644 --- a/docs/src/details/integration/driver/X11.rst +++ b/docs/src/details/integration/driver/X11.rst @@ -5,10 +5,14 @@ X11 Display/Inputs driver Overview -------- -| The **X11** display/input `driver `__ offers support for simulating the LVGL display and keyboard/mouse inputs in an X11 desktop window. -| It is an alternative to **Wayland**, **XCB**, **SDL** or **Qt**. +The **X11** display/input `driver `__ +offers support for simulating the LVGL display and keyboard/mouse inputs in an X11 +desktop window. -The main purpose for this driver is for testing/debugging the LVGL application in a **Linux** simulation window. +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 diff --git a/docs/src/details/integration/driver/display/renesas_glcdc.rst b/docs/src/details/integration/driver/display/renesas_glcdc.rst index 7c94f157f1..9727faf24a 100644 --- a/docs/src/details/integration/driver/display/renesas_glcdc.rst +++ b/docs/src/details/integration/driver/display/renesas_glcdc.rst @@ -40,7 +40,7 @@ Prerequisites ------------- - This diver relies on code generated by e\ |sup2| studio. Missing the step while setting up the project will cause a compilation error. -- Activate the diver by setting :c:macro:`LV_USE_RENESAS_GLCDC` to ``1`` in your *"lv_conf.h"*. +- Activate the diver by setting :c:macro:`LV_USE_RENESAS_GLCDC` to ``1`` in your ``lv_conf.h``. Usage ----- diff --git a/docs/src/details/integration/driver/opengles.rst b/docs/src/details/integration/driver/opengles.rst index 66554d1ff0..334b0c4479 100644 --- a/docs/src/details/integration/driver/opengles.rst +++ b/docs/src/details/integration/driver/opengles.rst @@ -7,10 +7,15 @@ OpenGL ES Display/Inputs Driver Overview -------- -| The **OpenGL ES** display/input `driver `__ offers support for simulating the LVGL display and keyboard/mouse inputs in an desktop window created via GLFW. -| It is an alternative to **Wayland**, **XCB**, **SDL** or **Qt**. +The **OpenGL ES** display/input +`driver `__ +offers support for simulating the LVGL display and keyboard/mouse inputs in an desktop +window created via GLFW. -The main purpose for this driver is for testing/debugging the LVGL application in an **OpenGL** simulation window. +It is an alternative to **Wayland**, **XCB**, **SDL** or **Qt**. + +The main purpose for this driver is for testing/debugging the LVGL application in +an **OpenGL** simulation window. Prerequisites ------------- diff --git a/docs/src/details/integration/driver/sdl.rst b/docs/src/details/integration/driver/sdl.rst index e345fdbc20..0a0310215f 100644 --- a/docs/src/details/integration/driver/sdl.rst +++ b/docs/src/details/integration/driver/sdl.rst @@ -7,7 +7,9 @@ SDL Driver Overview -------- -| SDL (Simple DirectMedia Layer) provides a cross-platform way to handle graphics, input, and multimedia, making it an excellent choice for running LVGL applications on a PC. +SDL (Simple DirectMedia Layer) provides a cross-platform way to handle graphics, +input, and multimedia, making it an excellent choice for running LVGL applications on +a PC. Prerequisites diff --git a/docs/src/details/integration/driver/wayland.rst b/docs/src/details/integration/driver/wayland.rst index 6ca711d2fe..d69fee47bb 100644 --- a/docs/src/details/integration/driver/wayland.rst +++ b/docs/src/details/integration/driver/wayland.rst @@ -7,10 +7,14 @@ Wayland Display/Inputs driver Overview -------- -| The **Wayland** `driver `__ offers support for simulating the LVGL display and keyboard/mouse inputs in a desktop window. -| It is an alternative to **X11** or **SDL2** +The **Wayland** `driver `__ +offers support for simulating the LVGL display and keyboard/mouse inputs in a desktop +window. -The main purpose for this driver is for testing/debugging the LVGL application, it can also be used to run applications in 'kiosk mode' +It is an alternative to **X11** or **SDL2** + +The main purpose for this driver is for testing/debugging the LVGL application. It can +also be used to run applications in "kiosk mode". Dependencies ------------ diff --git a/docs/src/details/integration/framework/tasmota-berry.rst b/docs/src/details/integration/framework/tasmota-berry.rst index 2c8943f3b6..15b64846aa 100644 --- a/docs/src/details/integration/framework/tasmota-berry.rst +++ b/docs/src/details/integration/framework/tasmota-berry.rst @@ -6,7 +6,7 @@ What is Tasmota? ---------------- `Tasmota `__ is a widely used -open-source firmware for ESP8266 and EPS32 based devices. It supports a +open-source firmware for ESP8266 and ESP32 based devices. It supports a wide variety of devices, sensors and integrations to Home Automation and Cloud services. Tasmota firmware is downloaded more than 200,000 times each month, and has an active and growing community. diff --git a/docs/src/details/integration/os/buildroot/lvgl_app.rst b/docs/src/details/integration/os/buildroot/lvgl_app.rst index d432ec01fa..9611b70442 100644 --- a/docs/src/details/integration/os/buildroot/lvgl_app.rst +++ b/docs/src/details/integration/os/buildroot/lvgl_app.rst @@ -137,7 +137,7 @@ to extend or modify the content of the root filesystem without altering the base packages or recompiling everything. Create the rootfs overlay structure and include the executable of the built -$application. +application. .. code-block:: bash diff --git a/docs/src/details/integration/os/nuttx.rst b/docs/src/details/integration/os/nuttx.rst index 680745a752..97fa47f3d4 100644 --- a/docs/src/details/integration/os/nuttx.rst +++ b/docs/src/details/integration/os/nuttx.rst @@ -133,7 +133,7 @@ Running the NuttX Simulator $ ./nuttx -Using the 'NSH>' terminal start the LVGL demo: +Using the ``NSH>`` terminal start the LVGL demo: .. code-block:: shell diff --git a/docs/src/details/integration/os/torizon_os.rst b/docs/src/details/integration/os/torizon_os.rst index 2a32428ec7..40089b7283 100644 --- a/docs/src/details/integration/os/torizon_os.rst +++ b/docs/src/details/integration/os/torizon_os.rst @@ -143,7 +143,7 @@ Now edit the Dockerfile. Copy-paste the block below into the file: ENTRYPOINT [ "./lvglsim" ] -The ``Dockerfile`` acts like a recipe to build two images and ``build`` and ``deploy``. +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``. diff --git a/docs/src/details/integration/os/yocto/lvgl_recipe.rst b/docs/src/details/integration/os/yocto/lvgl_recipe.rst index 9aabb7a2f4..76cfc04ef4 100644 --- a/docs/src/details/integration/os/yocto/lvgl_recipe.rst +++ b/docs/src/details/integration/os/yocto/lvgl_recipe.rst @@ -201,8 +201,8 @@ build process. 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 + 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 machine (or target board) for which the image was built. - **rmp/deb/ipk**: These folders contain the individual software packages @@ -593,10 +593,10 @@ To generate an SDK of the environment, run the following command: bitbake core-image-base -c populate_sdk -This will create a script ``build/tmp/deploy/sdk/ -poky-glibc-x86_64-core-image-base-cortexa53-raspberrypi3-64-toolchain-5.0.4. -sh``. This script allows you to install the SDK where you prefer. Here is the -execution output of the script +This will create a script +``build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-base-cortexa53-raspberrypi3-64-toolchain-5.0.4.sh``. +This script allows you to install the SDK where you prefer. Here is the execution +output of the script .. code-block:: bash @@ -674,8 +674,7 @@ or multiple applications using lvgl We will focus on 1 application that will clone an lvgl git repository and patch it for our needs. -The content of ``recipes-lvglapp/lvgl-fbdev-benchmark/lvglbenchmarkfbdev_2.4. -bb`` +The content of ``recipes-lvglapp/lvgl-fbdev-benchmark/lvglbenchmarkfbdev_2.4.bb`` .. code-block:: none diff --git a/docs/src/details/integration/os/yocto/terms_and_variables.rst b/docs/src/details/integration/os/yocto/terms_and_variables.rst index c6d9bc723d..7f982c7bfa 100644 --- a/docs/src/details/integration/os/yocto/terms_and_variables.rst +++ b/docs/src/details/integration/os/yocto/terms_and_variables.rst @@ -18,7 +18,7 @@ Yocto Variables Glossary This chapter lists basic variables used in the LVGL Yocto guide and gives an overview of their function and contents. -A More complete variable glossary can be found in `Yocto Variable Glossary +A more complete variable glossary can be found in `Yocto Variable Glossary `_. This section covers a lot of variables used in the OpenEmbedded build system. diff --git a/docs/src/details/integration/renderers/vg_lite.rst b/docs/src/details/integration/renderers/vg_lite.rst index 2fcebac30e..aafa2c816e 100644 --- a/docs/src/details/integration/renderers/vg_lite.rst +++ b/docs/src/details/integration/renderers/vg_lite.rst @@ -36,13 +36,12 @@ Configuration - Set :c:macro:`LV_VG_LITE_FLUSH_MAX_COUNT` to zero (recommended). The rendering backend will obtain the GPU's working status every time it writes rendering instructions to the command buffer. - When the GPU is idle, it will immediately call ``vg_lite_flush`` to notify the GPU to start rendering and swap the command buffer. When the GPU is busy, it will continue to fill the command buffer cache with rendering instructions. - The underlying driver will automatically determine if the command buffer has been filled. When it is about to be filled, it will forcibly wait for the unfinished drawing tasks to end and swap the command buffer. - This method can effectively improve GPU utilization, especially in scenarios where rendering text, as the GPU's drawing time and the CPU's data preparation time are very close, allowing the CPU and GPU to run in parallel. + When the GPU is idle, it will immediately call ``vg_lite_flush`` to notify the GPU to start rendering and swap the command buffer. When the GPU is busy, it will continue to fill the command buffer cache with rendering instructions. + The underlying driver will automatically determine if the command buffer has been filled. When it is about to be filled, it will forcibly wait for the unfinished drawing tasks to end and swap the command buffer. + This method can effectively improve GPU utilization, especially in scenarios where rendering text, as the GPU's drawing time and the CPU's data preparation time are very close, allowing the CPU and GPU to run in parallel. - Set :c:macro:`LV_VG_LITE_FLUSH_MAX_COUNT` to a value greater than zero, such as 8. After writing 8 rendering instructions to the command buffer, the rendering backend - - will call ``vg_lite_flush`` to notify the GPU to start rendering and swap the command buffer. + will call ``vg_lite_flush`` to notify the GPU to start rendering and swap the command buffer. 5. Set the :c:macro:`LV_VG_LITE_USE_BOX_SHADOW` configuration to use GPU rendering for shadows. In fact, GPU hardware does not actually support shadow rendering. However, through experimentation, it has been found that a similar shadow effect