framebuffer rotation

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,
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.

Cheers!

Andreas

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can't you use the framebuffer rotation option in the kernel? I don't know if directfb supports it or not.

I like cats, too. Let's exchange recipes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrew_feet wrote:
We do not want to hack the directfb, so I want to rotate the display content in the atmel_lcdcfb driver.

There's one more option: Hack the application so that it renders everything rotated the right way. I think that option will give you the best performance.

Quote:
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.

Hmm...so the "pseudo framebuffer" is the real framebuffer as far as the hardware is concerned?

Quote:
What do you think about this? Any suggestions? Has anybody done anything similar? What do you think about performance problems?

Well...you certainly won't see any _higher_ performance by doing the transformation in kernel space.

Quote:
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?

The framebuffer you point the LCDC at (whatever you call it) must be allocated using dma_alloc_coherent or dma_alloc_writecombine. You should probably allocate the shadow framebuffer that the application renders into from the page allocator (alloc_pages() and friends) since there's no point in disabling caching there, and you can make it physically discontiguous if you want (helps if you run into problems with memory fragmentation.)

Quote:
atmel_lcdfb_set_par should be the right place to set up the changed dot orientation.

Sounds about right, yes.

Quote:
atmel_lcdcfb_pan_display is should be the place to call the turning algorithm.

Yes, that might work, but only if your application uses double buffering. To make it completely transparent, you need to set up a timer to transfer the data from the shadow framebuffer to the HW framebuffer periodically, or do MMU trickery to get notified whenever the application writes to the shadow framebuffer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Andreas,

 

Although your post is a bit old...I am wondering...

Have you ever managed to rotate the framebuffer this way?

 

I am having the same debate with my customer working with Atmel SAMA5D2 chip-set. In my case userspace app uses portrait while the LCD itself is landscape orientated.

I will appreciate any help on this matter.

 

Cheers!

Yechiel

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Although your post is a bit old

Indeed.  Andreas hasn't been active in nearly ten years.  I doubt your request will reach him.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]