Hello, I am just hoping for a little help and a detailed explanation of one aspect of version 9.2. I was a confident LVGL user and I have not included processor type or display type because I have used a variety of processor families (all successfully) and display types. Some have been spi, some i2c, some parallel. But I could use the data in color_p easily by sorting out the colours and writing the driver to suit what order, size etc it wanted.
But I am baffled by *px_map. I can find nothing in the documentation which I have read, and re read, until my eyes bleed. What is it? How do I parse it out into colours and sort out a driver? Will an rgb8888 be 32 bits but a rgb888 only 24?
The example just shows “putting” the values from it to somewhere with the note to write some code to do it.
So my question ( and I hope some kind soul will help me) is “What is it?” and does it have different formats for 32bit, 24bit , 16bit etc ? and how is it parsed into colours so I can write, or modify my existing drivers. Very many thanks indeed.
Hello again,
I didn’t get a reply but I found on a GitHub a user (Schoumi) had dissected the px_map buffer and retrieved the colour order and format. So I am working on that and don’t need anything else.
Thank you anyway
If you are talking about the buffer that gets passed to the flush function this is a simple uint8_t single dimension array of the data that is going to be flushed. What the encoding of that buffer is will depend on what color mode you supplied to to lvgl when creating the lvgl display driver.
Hello Kevin, thank you for responding. I got the colour order from Schoumi and I have altered my driver to suit. I needed to parse in sets of 3 (or 4) for the colours rather than .ch blue etc.
Thanks again
I am not understanding what you mean…
if you are having issues with the colors not being correct on the display because you are using 16 bit color (rgb565) there i a function that you can call in lvgl that will reorder the colors properly. otherwise it is something you should be able to correct pretty easily by passing a different byte order to LVGL when constructing the driver.
Hello Kevin,
Thanks again for your interest and help. Over the years I have used them all 8888, 888, 565 etc. My initial question has been answered now and I am altering all my drivers to suit.
But again, many thanks for your help and advice.