Display Rotation

[c-mauderer]

Hello,

I’m working on an embedded system with a real time operating system (RTEMS). I have a simple (double buffered) frame buffer driver for a hardware that can only output the frame in exactly the direction it is in memory. I don’t have a rotation option in the hardware or on the display.

I tried to use the set_px_cb() in the driver to have the pixels at the right locations. That covered all cases for the lv_draw_basic.c. But now I noted that there is another file that can update the memory: The lv_refr.c.

Now I think about a number of possibilities (not sure yet which one will be used). One is to add a display rotation functionality to LittlevGL. As a rough direction I think about the following:

• find all locations in lv_draw_basic.c and lv_refr.c that draw to the buffer
• modify them to allow a rotation of 0, 90, 180 and 270 degree based on
  • either a #ifdef (better efficiency but less universal)
  • or a parameter in the display driver (less efficient but nice for multi display setups; although it’s no target for me, it maybe can be extended to support runtime rotation if someone want’s to add that in the future)

Would such an option be acceptable? If no I’ll strike that possibility from my list.

Best regards

Christian

[kisvegabor]

Hi,

In not true double buffered mode (1 or 2 smaller buffer and frame buffer) you can use this:

Setting rotated option in lv_disp_drv_t causes hard fault

Here is the code which worked me in the simulator: void get_col(const lv_color_t * src, const lv_area_t * area, lv_coord_t y, lv_color_t * dest) { lv_coord_t w = lv_area_get_width(area); lv_coord_t h = lv_area_get_height(area); lv_coord_t i; for(i = 0; i < h; i++) { dest[i].full = src[y].full; src += w ; } } void monitor_flush(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p) { lv_coord_t x2 = area->x2; if(x2 >= disp_drv->ver…

[embeddedt]

I think @c-mauderer is looking to add this functionality to LittlevGL itself so people don’t have to implement it in their driver.

[c-mauderer]

In not true double buffered mode (1 or 2 smaller buffer and frame buffer) you can use this:

Thanks for this hint. Currently my status is that I will try a quick solution like that in a first run. But I have a quite big display of 800 x 480 Pixel. So this solution might lead to a high CPU load or it will lead to tearing effects. Depending on whether the results are acceptable or not I might need another solution.

I think @c-mauderer is looking to add this functionality to LittlevGL itself so people don’t have to implement it in their driver.

That’s the second solution on my list. With my question I wanted to find out whether such a solution would be something that could be accepted as a patch to LittlevGL or not. Depending on that (and if my first approach doesn’t work) I’ll put more work into the topic to write a clean solution or less work to just add a quick hack on a private fork.

[kisvegabor]

The rotation feature was asked several times but the problem is that “thinking in lines” approach is deeply wired in lvgl. I think it’d be very difficult to add “column-based thinking” too.

[c-mauderer]

Although the CPU load is quite high for a 800x480 display (about 15% of a few 100MHz CPU in case of a lot of activity on the screen), I currently can rotate in software. As long as I don’t hit the limit of my system, I’ll use that solution for now.

If there is time left in the project for optimization or if the CPU load is too high, I’ll come back to the more complex solution of implementing it in LittlevGL.

Edit: Note that I accepted the first solution suggesting a software rotation so that the post is closed.

[kisvegabor]

If there is time left in the project for optimization or if the CPU load is too high, I’ll come back to the more complex solution of implementing it in LittlevGL.

Alright, thank you in advance!