Just spent a (very nice) week porting V9 to our custom board, STM32H7 with 800x480 pcap display, with great preliminary results. Still working on it right now…
Kudos to Gabor for this really well designed library!
I did read this thread with great interest because I did sponsor adoption of LVGL in the company, buying also two full SLS licenses, to implement our next new platform.
I think that for industrial players like us, choosing LVGL instead of TouchGFX on STM32 is a safer bet for long term maintenance of heavy software projects, given past components shortages.
But I think that the display rotation “problem” can be serious in more situations than one could expect.
Let me give some numbers. I work in a medium sized company that is a very well known player in our field; develops and sells 150K+ diagnostic devices each year as a whole.
Roughly 1/3 of those have displays in many different shapes and sizes.
Very low volumes compared to consumer elecronics, but reasonably common in the industrial field.
We do almost source custom displays, asking for cover lens shape, thickness, color, touch controller parameters changes, display controller changes or cusotm flat interface signals.
But product fragmentation keeps each display to 10K pcs./yr each, no more.
Given this, we never had a chance to handle rotation at display level. That would require a truly custom lcd module, while customization happens tipically at the lcd+pcap+coverlens+fw level.
Only axis swapping.
Our platform uses:
480x800 portrait, recycling the same display as above. Just 5K / year, but still.
I did not “discover” that rotation might be a problem until very recently so now I need to find a reasonable solution somehow.
Any help is truly appreciated.
Just my $0.02 to confirm what others (nylnx, kdschlosser) have said, that (static, compile time) rotation is often a necessity even for serious projects.
Sorry for the long post!
Now i’m unsure if going back to 8.3 where rotation is maybe handled somehow, but i’ll miss badly the 24 bit native framebuffer format, needed to keep sdram bandwidth low enough at 800x480, and the frame buffer native “stride” handling of V9 (needed on STM32 controller). Besides, driver model is very clean on V9, i was running on my hardware in a few hours work.