Add missing documentation

[kisvegabor]

Introduce the problem

Some new features are not documented properly.

• [ ] Gradients
• [ ] Vector fonts
• [ ] Vector API
• [ ] ThorVG
• [ ] Caching
• [ ] SW rendering
• [ ] Styles
  • [ ] Color filter
  • [ ] Gradients
• [ ] Chip vendors
  • [ ] ST
  • [ ] NXP
  • [ ] ESP See https://github.com/lvgl/lvgl/issues/6574
• [ ] RTOS
  • [ ] FreeRTOS

Proposal

No response

[vwheeler63]

@kisvegabor

Hi, Gabor! I can help with this. Esp. the FreeRTOS part. There is a lot more in the list as well. We can use at least part of the (upcoming) Doxygen "is not documented" baseline list to help.

As an aside, I also note that the documentation about threading is incomplete. I have taken some notes about this, as I had to deal with it extensively in a project that was handed over to me in early 2022 that had LVGL calls being made from 6 different threads! I think I can do a good job of supplementing that documentation. I think there will be a lot more too. Let me know your thoughts.

[kisvegabor]

Hi Vic,

It would be amazing!

Regarding ESP, I've opened an issue earlier: https://github.com/lvgl/lvgl/issues/6574 Espressif is an important partner of LVGL, so if you are interested in it, it would be great to start with it.

[kisvegabor]

I've just noticed that @tore-espressif already sent a PR to update the ESP docs: #6658

[vwheeler63]

Hi, Gabor!

I'm sorry, I created a misunderstanding: I should be more careful about abbreviating. By "Esp." I meant "especially" -- especially FreeRTOS.

I do keep hearing however about the ESP32 -- it must be a popular microcontroller. I am guessing it is going to be in my future.... Minus actual knowledge of the ESP32, I gave their PR a review as the document content and web linked looked good from the perspective of grammar and web links being valid. What a nice partnership with LVGL!! I hope it's proving profitable!

I am an expert, however, with the PIC32MX and PIC32MZ. :-)

[clydebarrow]

Another undocumented (old) feature - color filters. And color gradients.

[kisvegabor]

@vwheeler63 FreeRTOS only is awesome too :blush:

Microchip is not an official partner of LVGL yet and we don't have in house expertise for PICs now. It might be a good collaboration/work opportunity in the future!

@clydebarrow

Another undocumented (old) feature - color filters. And color gradients.

Added to the list, thank you!

[vwheeler63]

It might be a good collaboration/work opportunity in the future!

I like the sound of that. :-)

[lorenzo-arena]

About "Color filter" and "Gradients": what would be a good place for them? I see that there's already a section with a "TODO" for Color filter, would it be good to add gradients right after that?

[vwheeler63]

About "Color filter" and "Gradients": what would be a good place for them? I see that there's already a section with a "TODO" for Color filter, would it be good to add gradients right after that?

Seems logical.

[lvgl-bot]

We need some feedback on this issue.

Now we mark this as "Abandoned" because there was no activity here for 14 days.

Remove the "Stale" label or comment else this will be closed in 7 days.

[apavelm]

Hi Gabor!

Let me add a documentation request here.

Here: https://docs.lvgl.io/9.3/details/integration/driver/display/gen_mipi.html And as well as for all others display controller drivers, there is a mentioning "all you need is just to implement the following functions..."

/* Send short command to the LCD. This function shall wait until the transaction finishes. */
int32_t my_lcd_send_cmd(lv_display_t *disp, const uint8_t *cmd, size_t cmd_size, const uint8_t *param, size_t param_size)
{
        ...
}

/* Send large array of pixel data to the LCD. If necessary, this function has to do the byte-swapping. This function can do the transfer in the background. */
int32_t my_lcd_send_color(lv_display_t *disp, const uint8_t *cmd, size_t cmd_size, uint8_t *param, size_t param_size)
{
        ...
}

But without any details or samples, it's difficult to guess what exactly should be there. Considering ESP and LVGL version related changes in approaches, this is not clear at all.

[vwheeler63]

@kisvegabor I don't think I have seen it yet -- shouldn't there be something in the docs about how to do clipping and masking?

[apavelm]

Its difficult to get on what level it should be done: by sending direct commands to display or by using kind of abstraction especially for that? I tried to find any simple implementation over the internet based on this, but didn't find anything. Everything what I found was based on previous version (flush/flush_cb). So, still no clue which way is better. On one hand - I want to stick with the latest version, but on the other hand I have no information why this should be better (may be it is faster or something?). There is no information about pros and cons or why API was changed. I'd very appreciate (and probably not only me) if you could provide more details on this.

[kisvegabor]

Thank your for pointing it out. @liamHowatt was working on some related docs changes recently. Liam, could you add more details to these too?

In short you need to do an SPI or parallel port transfer here. You also need set the C/D (command/data) pin as needed when sending the cmd and param parts.

When my_lcd_send_color finishes you also need to call lv_display_flush_ready(disp).

As I'm writing it all down, these really should be in to docs and some pseudo code should be added inside these functions.

[vwheeler63]

On this topic: there is still a large quantity of Doxygen warnings. Out of 2436 warnings, 2399 contain the string "is not documented".

Also, at the point in time where it is the right priority to do so, I would really like to go through the existing API documentation and clean it up and make it consistent.