fix(docs): fix most sphinx warnings (#6916)

Co-authored-by: Kevin Schlosser <kdschlosser@users.noreply.github.com>
Co-authored-by: Liam <30486941+liamHowatt@users.noreply.github.com>

docs/porting/display.rst

@@ -183,7 +183,7 @@ It's very important that draw buffer(s) should be large enough for any
 selected color format.
 
 
-Swap Endianness
+Swap endianness
 ---------------
 
 In case of RGB565 color format it might be required to swap the 2 bytes
@@ -350,7 +350,8 @@ Further reading
 
 -  `lv_port_disp_template.c <https://github.com/lvgl/lvgl/blob/master/examples/porting/lv_port_disp_template.c>`__
    for a template for your own driver.
--  :ref:`Drawing <porting_draw>` to learn more about how rendering works in LVGL.
+-  :ref:`Drawing <porting_draw>` to learn more about how rendering
+   works in LVGL.
 -  :ref:`display_features` to learn more about higher
    level display features.
 

docs/porting/draw.rst

@@ -62,11 +62,15 @@ Hierarchy of modules
 --------------------
 
 All these together looks like this
+
 - list of draw units
 - display(s)
+
    - layer(s): Each display has its own list of layers
+
       - draw tasks: Each layer has its own list of draw tasks
 
+
 References
 **********
 

docs/porting/indev.rst

@@ -82,10 +82,12 @@ The final diff is calculated like this:
 
 ``diff_final = diff_in * (indev_sensitivity / 256) +  (widget_sensitivity / 256);``
 
+
 For example, if both the indev and widget sensitivity is set to 128 (0.5), the input diff. will be
 multiplied by 0.25 (divided by 4). The value of the widget will be incremented by this value or
 the widget will be scrolled this amount of pixels.
 
+
 Keypad or keyboard
 ------------------
 
@@ -150,7 +152,7 @@ added to groups.
      else data->state = LV_INDEV_STATE_RELEASED;
    }
 
-Using Buttons with Encoder Logic
+Using buttons with Encoder logic
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In addition to standard encoder behavior, you can also utilize its logic

docs/porting/log.rst

@@ -41,7 +41,7 @@ can register a "logger" callback with :cpp:func:`lv_log_register_print_cb`.
 
 For example:
 
-.. code:: c
+.. code-block:: c
 
    void my_log_cb(lv_log_level_t level, const char * buf)
    {

docs/porting/os.rst

@@ -36,7 +36,7 @@ than ``LV_OS_NONE``.
 
 Here is some pseudocode to illustrate the concept:
 
-.. code:: c
+.. code-block:: c
 
    void lvgl_thread(void)
    {

docs/porting/project.rst

@@ -32,7 +32,7 @@ LVGL also supports ``make`` and ``CMake`` build systems out of the box.
 To add LVGL to your Makefile based build system add these lines to your
 main Makefile:
 
-.. code:: make
+.. code-block:: make
 
    LVGL_DIR_NAME ?= lvgl     #The name of the lvgl folder (change this if you have renamed it)
    LVGL_DIR ?= ${shell pwd}  #The path where the lvgl folder is
@@ -113,7 +113,7 @@ in TLS (Thread Local Storage).
 
 For example:
 
-.. code:: c
+.. code-block:: c
 
    lv_global_t * lv_global_default(void)
    {

docs/porting/sleep.rst

@@ -5,7 +5,7 @@ Sleep management
 The MCU can go to sleep when no user input happens. In this case, the
 main ``while(1)`` should look like this:
 
-.. code:: c
+.. code-block:: c
 
    while(1) {
      /*Normal operation (no sleep) in < 1 sec inactivity*/
@@ -23,7 +23,7 @@ main ``while(1)`` should look like this:
 You should also add the following lines to your input device read
 function to signal a wake-up (press, touch or click etc.) has happened:
 
-.. code:: c
+.. code-block:: c
 
    lv_tick_inc(LV_DEF_REFR_PERIOD); /*Force task execution on wake-up*/
    timer_start();                   /*Restart the timer where lv_tick_inc() is called*/

docs/porting/tick.rst

@@ -23,7 +23,8 @@ The ticks (milliseconds)  should be independent from any other activities of the
 
 For example this works, but LVGL's timing will be incorrect as the execution time of ``lv_timer_handler`` is not considered:
 
-.. code:: c
+.. code-block:: c
+
    // Bad idea
    lv_timer_handler();
    lv_tick_inc(5);

docs/porting/timer_handler.rst

@@ -13,7 +13,7 @@ periodically in one of the following:
 
 Example:
 
-.. code:: c
+.. code-block:: c
 
    while(1) {
      uint32_t time_till_next = lv_timer_handler();
@@ -24,7 +24,7 @@ If you want to use :cpp:func:`lv_timer_handler` in a super-loop, a helper
 function :cpp:func:`lv_timer_handler_run_in_period` is provided to simplify
 the porting:
 
-.. code:: c
+.. code-block:: c
 
    while(1) {
       ...
@@ -34,7 +34,7 @@ the porting:
 
 Or use the sleep time automatically calculated by LVGL:
 
-.. code:: c
+.. code-block:: c
 
    while(1) {
      ...
@@ -45,7 +45,7 @@ Or use the sleep time automatically calculated by LVGL:
 In an OS environment, you can use it together with the **delay** or
 **sleep** provided by OS to release CPU whenever possible:
 
-.. code:: c
+.. code-block:: c
 
    while (1) {
       uint32_t time_till_next = lv_timer_handler();