fix: eliminate misc sphinx warnings... (#6929)

docs/overview/event.rst

@@ -22,7 +22,7 @@ Add events to a widget
 The user can assign callback functions to an object to see its events.
 In practice, it looks like this:
 
-.. code:: c
+.. code-block:: c
 
    lv_obj_t * btn = lv_button_create(lv_screen_active());
    lv_obj_add_event_cb(btn, my_event_cb, LV_EVENT_CLICKED, NULL);   /*Assign an event callback*/
@@ -44,7 +44,7 @@ more detail.
 
 More events can be added to an object, like this:
 
-.. code:: c
+.. code-block:: c
 
    lv_obj_add_event_cb(obj, my_event_cb_1, LV_EVENT_CLICKED, NULL);
    lv_obj_add_event_cb(obj, my_event_cb_2, LV_EVENT_PRESSED, NULL);
@@ -53,7 +53,7 @@ More events can be added to an object, like this:
 Even the same event callback can be used on an object with different
 ``user_data``. For example:
 
-.. code:: c
+.. code-block:: c
 
    lv_obj_add_event_cb(obj, increment_on_click, LV_EVENT_CLICKED, &num1);
    lv_obj_add_event_cb(obj, increment_on_click, LV_EVENT_CLICKED, &num2);
@@ -64,7 +64,7 @@ Other objects can use the same *event callback*.
 
 In the very same way events can attached to the input devices and displays like this
 
-.. code:: c
+.. code-block:: c
 
    lv_display_add_event_cb(disp, event_cb, LV_EVENT_RESOLUTION_CHANGED, NULL);
    lv_indev_add_event_cb(indev, event_cb, LV_EVENT_CLICKED, NULL);
@@ -73,7 +73,7 @@ In the very same way events can attached to the input devices and displays like
 Remove event(s) from widgets
 ****************************
 
-.. code:: c
+.. code-block:: c
 
    uint32_t i;
    uint32_t event_cnt = lv_obj_get_event_count(obj);
@@ -133,11 +133,11 @@ Input device events
 -  :cpp:enumerator:`LV_EVENT_HOVER_OVER`: Indev hover over object
 -  :cpp:enumerator:`LV_EVENT_HOVER_LEAVE`: Indev hover leave object
 
-Drawing events
+Drawing Events
 --------------
 
--  :cpp:enumerator:`LV_EVENT_COVER_CHECK`: Check if the object fully covers an area. The event parameter is :cpp:type:`lv_cover_check_info_t *`.
--  :cpp:enumerator:`LV_EVENT_REFR_EXT_DRAW_SIZE`: Get the required extra draw area around the object (e.g. for shadow). The event parameter is :cpp:type:`int32_t *` to store the size.
+-  :cpp:enumerator:`LV_EVENT_COVER_CHECK`: Check if the object fully covers an area. The event parameter is :cpp:type:`lv_cover_check_info_t` ``*``.
+-  :cpp:enumerator:`LV_EVENT_REFR_EXT_DRAW_SIZE`: Get the required extra draw area around the object (e.g. for shadow). The event parameter is :cpp:type:`int32_t` ``*`` to store the size.
 -  :cpp:enumerator:`LV_EVENT_DRAW_MAIN_BEGIN`: Starting the main drawing phase
 -  :cpp:enumerator:`LV_EVENT_DRAW_MAIN`: Perform the main drawing
 -  :cpp:enumerator:`LV_EVENT_DRAW_MAIN_END`: Finishing the main drawing phase
@@ -150,7 +150,7 @@ Special events
 --------------
 
 -  :cpp:enumerator:`LV_EVENT_VALUE_CHANGED`: The object's value has changed (i.e. slider moved)
--  :cpp:enumerator:`LV_EVENT_INSERT`: A text is inserted to the object. The event data is `char *` being inserted.
+-  :cpp:enumerator:`LV_EVENT_INSERT`: A text is inserted to the object. The event data is :cpp:type:`char` ``*`` being inserted.
 -  :cpp:enumerator:`LV_EVENT_REFRESH`: Notify the object to refresh something on it (for the user)
 -  :cpp:enumerator:`LV_EVENT_READY`: A process has finished
 -  :cpp:enumerator:`LV_EVENT_CANCEL`: A process has been cancelled
@@ -234,11 +234,11 @@ contains all data about the event. The following values can be gotten from it:
 
 - :cpp:expr:`lv_event_get_code(e)`: get the event code
 - :cpp:expr:`lv_event_get_current_target(e)`: get the object to which an event was sent. I.e. the object whose event handler is being called.
-- :cpp:expr:`lv_event_get_target(e)`: get the object that originally triggered the event (different from :cpp:func:`lv_event_get_target` if :ref:`event bubbling <events_bubbling>` is enabled)
+- :cpp:expr:`lv_event_get_target(e)`: get the object that originally triggered the event (different from :cpp:func:`lv_event_get_target` if :ref:`event bubbling <event_bubbling>` is enabled)
 - :cpp:expr:`lv_event_get_user_data(e)`: get the pointer passed as the last parameter of :cpp:func:`lv_obj_add_event`.
 - :cpp:expr:`lv_event_get_param(e)`: get the parameter passed as the last parameter of :cpp:func:`lv_obj_send_event`
 
-.. _events_bubbling:
+.. _event_bubbling:
 
 Event bubbling
 **************

docs/overview/font.rst

@@ -9,7 +9,7 @@ to render images of individual letters (glyph). A font is stored in a
 :cpp:type:`lv_font_t` variable and can be set in a style's *text_font* field.
 For example:
 
-.. code:: c
+.. code-block:: c
 
    lv_style_set_text_font(&my_style, &lv_font_montserrat_28);  /*Set a larger font*/
 
@@ -36,7 +36,7 @@ and be sure that, :c:macro:`LV_TXT_ENC` is set to :c:macro:`LV_TXT_ENC_UTF8` in
 
 To test it try
 
-.. code:: c
+.. code-block:: c
 
    lv_obj_t * label1 = lv_label_create(lv_screen_active(), NULL);
    lv_label_set_text(label1, LV_SYMBOL_OK);
@@ -101,19 +101,19 @@ font.
 
 The symbols can be used singly as:
 
-.. code:: c
+.. code-block:: c
 
    lv_label_set_text(my_label, LV_SYMBOL_OK);
 
 Or together with strings (compile time string concatenation):
 
-.. code:: c
+.. code-block:: c
 
    lv_label_set_text(my_label, LV_SYMBOL_OK "Apply");
 
 Or more symbols together:
 
-.. code:: c
+.. code-block:: c
 
    lv_label_set_text(my_label, LV_SYMBOL_OK LV_SYMBOL_WIFI LV_SYMBOL_PLAY);
 
@@ -303,7 +303,7 @@ to have a special binary format. (Not TTF or WOFF). Use
 
 Example
 
-.. code:: c
+.. code-block:: c
 
    lv_font_t *my_font = lv_binfont_create("X:/path/to/my_font.bin");
    if(my_font == NULL) return;
@@ -313,8 +313,8 @@ Example
    /*Free the font if not required anymore*/
    lv_binfont_destroy(my_font);
 
-Load a font from a memory buffer at run-time
-******************************************
+Load a Font from a Memory Buffer at Run-Time
+********************************************
 
 :cpp:func:`lv_binfont_create_from_buffer` can be used to load a font from a memory buffer.
 This function may be useful to load a font from an external file system, which is not
@@ -325,7 +325,7 @@ supported by LVGL. The font needs to be in the same format as if it were loaded
 
 Example
 
-.. code:: c
+.. code-block:: c
 
    lv_font_t *my_font;
    uint8_t *buf;
@@ -397,10 +397,10 @@ line 1
 
     #!/usr/bin/env python3
 
-Example for a 12px font
------------------------
+Example for a 12-px Font
+------------------------
 
-.. code:: bash
+.. code-block:: console
 
     cd mkttf
     ./mkttf.py ./TerminusMedium-12-12.bdf
@@ -432,7 +432,7 @@ the font's bitmap and read them when the library needs them. FreeType can be use
 
 To add a new font engine, a custom :cpp:type:`lv_font_t` variable needs to be created:
 
-.. code:: c
+.. code-block:: c
 
    /*Describe the properties of a font*/
    lv_font_t my_font;
@@ -487,7 +487,7 @@ font from ``fallback`` to handle.
 
 ``fallback`` can be chained, so it will try to solve until there is no ``fallback`` set.
 
-.. code:: c
+.. code-block:: c
 
    /* Roboto font doesn't have support for CJK glyphs */
    lv_font_t *roboto = my_font_load_function();

docs/overview/fs.rst

@@ -13,24 +13,24 @@ drive letter. For example, if an SD card is associated with the letter
 
 	If you want to skip the drive prefix from the path, you can use the :c:macro:`LV_FS_DEFAULT_DRIVE_LETTER` config parameter.
 
-Ready to use drivers
+Ready-to-Use Drivers
 ********************
 
 LVGL contains prepared drivers for the API of POSIX, standard C,
 Windows, and `FATFS <http://elm-chan.org/fsw/ff/00index_e.html>`__.
 Learn more :ref:`here <libs_filesystem>`.
 
-Adding a driver
+Adding a Driver
 ***************
 
-Registering a driver
+Registering a Driver
 --------------------
 
 To add a driver, a :cpp:type:`lv_fs_drv_t` needs to be initialized like below.
 The :cpp:type:`lv_fs_drv_t` needs to be static, global or dynamically allocated
 and not a local variable.
 
-.. code:: c
+.. code-block:: c
 
    static lv_fs_drv_t drv;                   /*Needs to be static or global*/
    lv_fs_drv_init(&drv);                     /*Basic initialization*/
@@ -65,7 +65,7 @@ Open callback
 
 The prototype of ``open_cb`` looks like this:
 
-.. code:: c
+.. code-block:: c
 
    void * (*open_cb)(lv_fs_drv_t * drv, const char * path, lv_fs_mode_t mode);
 
@@ -83,7 +83,7 @@ Other callbacks
 The other callbacks are quite similar. For example ``write_cb`` looks
 like this:
 
-.. code:: c
+.. code-block:: c
 
    lv_fs_res_t (*write_cb)(lv_fs_drv_t * drv, void * file_p, const void * buf, uint32_t btw, uint32_t * bw);
 
@@ -99,7 +99,7 @@ Usage example
 
 The example below shows how to read from a file:
 
-.. code:: c
+.. code-block:: c
 
    lv_fs_file_t f;
    lv_fs_res_t res;
@@ -120,7 +120,7 @@ This example shows how to read a directory's content. It's up to the
 driver how to mark directories in the result but it can be a good
 practice to insert a ``'/'`` in front of each directory name.
 
-.. code:: c
+.. code-block:: c
 
    lv_fs_dir_t dir;
    lv_fs_res_t res;
@@ -183,8 +183,8 @@ The implementation is documented below. Note that the FS functions make calls
 to other driver FS functions when the cache is enabled. i.e., ``lv_fs_read`` may call the driver's ``seek``
 so the driver needs to implement more callbacks when the cache is enabled.
 
-``lv_fs_read`` :sub:`(behavior when the cache is enabled)`
--------------------------------------------------
+``lv_fs_read`` :sub:`(Behavior When Cache is Enabled)`
+----------------------------------------------------------
 
 .. mermaid::
    :zoom:
@@ -230,21 +230,21 @@ so the driver needs to implement more callbacks when the cache is enabled.
              --> P["copy the required bytes
                     to the destination buffer"]
 
-``lv_fs_write`` :sub:`(behavior when the cache is enabled)`
---------------------------------------------------
+``lv_fs_write`` :sub:`(Behavior When Cache is Enabled)`
+-------------------------------------------------------
 
 The part of the cache that coincides with the written content
 will be updated to reflect the written content.
 
-``lv_fs_seek`` :sub:`(behavior when the cache is enabled)`
--------------------------------------------------
+``lv_fs_seek`` :sub:`(Behavior When Cache is Enabled)`
+------------------------------------------------------
 
 The driver's ``seek`` will not actually be called unless the ``whence``
 is ``LV_FS_SEEK_END``, in which case ``seek`` and ``tell`` will be called
 to determine where the end of the file is.
 
-``lv_fs_tell`` :sub:`(behavior when the cache is enabled)`
--------------------------------------------------
+``lv_fs_tell`` :sub:`(Behavior When Cache is Enabled)`
+------------------------------------------------------
 
 The driver's ``tell`` will not actually be called.
 

docs/overview/layer.rst

@@ -24,7 +24,7 @@ its children.
 
 .. image:: /misc/layers.png
 
-.. code:: c
+.. code-block:: c
 
    /*Create a screen*/
    lv_obj_t * scr = lv_obj_create(NULL, NULL);
@@ -89,7 +89,7 @@ everywhere. For example, a menu bar, a pop-up, etc. If the ``click``
 attribute is enabled, then ``layer_top`` will absorb all user clicks and
 acts as a modal.
 
-.. code:: c
+.. code-block:: c
 
    lv_obj_add_flag(lv_layer_top(), LV_OBJ_FLAG_CLICKABLE);
 
@@ -128,8 +128,8 @@ In this case widget will be sliced into ``LV_DRAW_SW_LAYER_SIMPLE_BUF_SIZE`` siz
 If there is no memory for a new chunk, LVGL will try allocating layer when another chunk is rendered and freed.
 
 
-Transformed layer
----------------
+Transformed Layer
+-----------------
 
 When the widget is transformed a larger part of the widget needs to rendered to provide enough data for transformation. LVGL tries to render as small area of the widget as possible, but due to the nature of transformations no slicing is possible in this case.
 

docs/overview/vg_lite_tvg.rst

@@ -9,10 +9,10 @@ Its purpose is to simplify the debugging of VG-Lite adaptation and reduce the ti
 
 It has been integrated into the CI automated compilation and testing process to ensure that the VG-Lite rendering backend can be fully tested after each PR modification.
 
-How it works
+How It Works
 ************
 
-Sort out the APIs in the ``vg_lite.h`` header file provided by the vendor, re-implement the APIs using `ThorVG <https://github.com/thorvg/thorvg>`_, 
+Sort out the APIs in the ``vg_lite.h`` header file provided by the vendor, re-implement the APIs using `ThorVG <https://github.com/thorvg/thorvg>`_,
 and simulate the same rendering images as the real hardware on the simulator.
 
 Configuration
@@ -21,7 +21,7 @@ Configuration
 1. Enable VG-Lite rendering backend, see `VG-Lite Rendering Backend </overview/renderers/vg_lite>`__.
 
 2. Enable ThorVG and turn on the configuration :c:macro:`LV_USE_THORVG_INTERNAL` or :c:macro:`LV_USE_THORVG_EXTERNAL`.
-It is recommended to use the internal ThorVG library to ensure uniform rendering results.
+   It is recommended to use the internal ThorVG library to ensure uniform rendering results.
 
 3. Enable :c:macro:`LV_USE_VG_LITE_THORVG` and set :c:macro:`LV_DRAW_BUF_ALIGN` to 64. The rest of the options can remain default.
-Make sure :c:macro:`LV_VG_LITE_USE_GPU_INIT` is enabled, because the thorvg drawing context needs to be initialized before it can be used.
+   Make sure :c:macro:`LV_VG_LITE_USE_GPU_INIT` is enabled, because the thorvg drawing context needs to be initialized before it can be used.