Embedded linux framebuffer rotate

Question

I have to integrate an LCD screen to my embedded linux (ARM9) system. The LCD is portrait 320x480 and I need to run the screen in landscape orientation 480x320. Using the LCD config register I can rotate it in hardware, so that (x,y)(0,0) is rotated 90 degrees. Here starts my problem, the screen's wide side gets narrowed from 480 pixels to 320, and the long side of the picture is out of the screen. This should be fixed by changing the framebuffer dimensions AFAIK, but I tried a few ways to do it with no success yet. using the fbset, below are the settings for portrait:

mode "480x320-55"
    # D: 9.091 MHz, H: 18.182 kHz, V: 55.096 Hz
    geometry 480 320 480 320 16
    timings 110000 4 4 4 4 12 2
    rgba 5/0,6/5,5/11,0/0
endmode

Sending the command:

fbset --geometry 480 320 480 320 16

Results in:

mode "480x320-55"
    # D: 9.091 MHz, H: 18.182 kHz, V: 55.096 Hz
    geometry 480 320 480 320 16
    timings 110000 4 4 4 4 12 2
    rgba 5/0,6/5,5/11,0/0
endmode

Which makes the picture appear a few times and overlaps, but the screen width is still too narrow.

I tried to provide double the screen size for the virtual xres and yres, but no change.

fbset --geometry 480 320 960 640 16

I also tried using fb rotate function I found on the web "saFbdevRotation.c", which uses the FB IOCTL, but the active screen size is still incorrect.

rotate 90 degrees, see output

$> ./fb_rotate -r 90
## Before rotation
### Fix Screen Info:
Line Length - 640
Physical Address = 81a00000
Buffer Length = 1048576

### Var Screen Info:
Xres - 320
Yres - 480
Xres Virtual - 320
Yres Virtual - 480
Bits Per Pixel - 16
Pixel Clk - 110000
Rotation - 0
## after rotation
###  Fix Screen Info:
Line Length - 960
Physical Address = 81a00000
Buffer Length = 1048576

### Var Screen Info:
Xres - 480
Yres - 320
Xres Virtual - 480
Yres Virtual - 320
Bits Per Pixel - 16
Pixel Clk - 110000
Rotation - 90

I can also add that the system is very limited with free memory, can this cause the fb to NOT allocate a new buffer? However there were no errors in dmesg.

Will appreciate your advise.

Answer 1

I can also add that the system is very limited with free memory, can this cause the fb to NOT allocate a new buffer? However there were no errors in dmesg.

Normally,the standard way for allocating video buffer is to pre-allocate a large video buffer(based on the max video resolution you support) in the boot time,which pass a men= argument to the kernel so that kernel won't occupy it initially.

then later on,the video driver can do

void *ioremap(unsigned long phys_addr, unsigned long size)

which will create a mmap area for driver directly operate the frame buffer.

You can check it via doing cat /proc/iomen

Thus,the video driver memory is pre-allocated and is different from linux kernel system memory(like kmalloc() or get_free_pages() or vmalloc()), what you concerned is ruled out.