I want to do something special with the framebuffer lcd driver.
We are developing an application which uses directfb to display text strings and graphics on the LCD display. For a special customer we have to use a small TFT display 1,8” 176x220 dots. As the customer wants to assemble and use the display in landscape orientation and we did not find any small landscape displays we have to rotate the display content.
We do not want to hack the directfb, so I want to rotate the display content in the atmel_lcdcfb driver.
What I exactly want to do is set up a second pseudo framebuffer memory area.
I don’t want to touch the interface to the application (I mean the whole thing upside the atmel_lcdcfb driver even in kernel space). I want to set up the framebuffer and display information in arch/avr32/boards/setup.c to 220x176 dots, so the application, directfb etc. are working on a landscape orientation.
The atmel_lcdfb driver should then set up the orientation for the LCD Controller to 176x220. Every time a picture is updatet, my own rotating algorithm should copy and rotate the display content into the pseudo framebuffer memory area. Then the DMA pointer for the LCD controller should be set to the pseudo framebuffer memory area.
What do you think about this? Any suggestions? Has anybody done anything similar? What do you think about performance problems?
After studying the documentation of framebuffer ,the atmel_lcdcfb and the vfb I found out the following:
atmel_lcdfb_aloc_video_memory should be the right place to set up the pseudo framebuffer memory area. I saw that the real framebuffer ist set up via dma_alloc_writecombine. Is this only for the DMA access of the LCD controller or does the framebuffer needs to be a DMA buffer?
atmel_lcdfb_set_par should be the right place to set up the changed dot orientation.
atmel_lcdcfb_pan_display is should be the place to call the turning algorithm.
I would be thankful for every suggestion and/or help.