double buffering fb0 ?

[Chuck McManis]

Greetings all. So I'm interested in double buffering /dev/fb0 so that I can get smooth transitions on my sign. This link

http://pandorawiki.org/Kernel_interface

Talks about opening the frame buffer, them mapping a buffer that is'twice' as big. 

Well some interesting bits, if I do an FBIOGET_FSCREENINFO the line length is 8192. (this is the stride) Now I can map 1920 x 8192 but that sets up for 2K pixels per line (4 bytes per pixel) however this seems to be correct as writing into the frame buffer memory using that stride and the ARGB32 format gets me what I expect.

Now I want to double buffer it, so I want to map two buffers, and I want to be able to tell the frame buffer to switch. 

This is my code:

    /* open frame buffer device */

    __fb = fd = open("/dev/fb0", O_RDWR);

    if (fd >= 0) {

        if (!ioctl(fd, FBIOGET_VSCREENINFO, &screen_info) &&

            !ioctl(fd, FBIOGET_FSCREENINFO, &fixed_info)) {

            buflen = screen_info.yres_virtual * fixed_info.line_length;

            screen_data(&screen_info);

            buffer = (unsigned char *) mmap(NULL, buflen,

                        PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

            if (buffer != MAP_FAILED) {

If I try to map buflen * 2 (two frames) the mmap fails. So I'm wondering how to allocate a second buffer, and once allocated how I can swap to it in my 'flip_page()' routine.

--Chuck

[lioric...@gmail.com]

Have you set the correct fb size?

Fbset x y doubleX doubleY   

Lioric

-- Sent from my HP TouchPad

---

[Rob Clark]

the fbdev fb is only going to be allocated for the size of your fbcon
console.. really if you want to double (or triple) buffer you should
use the kms interface to control the display. This gives you a lot
more flexibility. (Including cached buffers, overlays, etc)

BR,
-R

> --Chuck
>

[ChuckMcM]

Well in this case you really only need doubleY (for two frames) the frame buffer driver then would pan between the two, anyway I gave it a shot and got the invalid arg call.

Per Rob's response I've been scouring the web for a way to "use kms"  unfortunately my embedded linux book pre-dates kms so there isn't any help there, the linkage in the kernel between fbdev and fbdev-omap4 is still opaque but my plan is to start putting kprintf's in the kernel to try to figure that out. Worst comes to worse I suppose I can hack together a kernel module to poke this stuff on the omap4 specific bits. 

As an example of how weirdly non-documented this stuff is, if you use Google to look for 'FBIO_ALLOC' (seems like a likely candidate for allocating a second buffer you get things like this: http://valadoc.org/#!api=linux/Linux.Framebuffer.FBIO_ALLOC) blank pages, lots and lots of hits on copies of the source repos version of /usr/include/linux/fb.h but even in that file nothing. 

I find somewhat surreal actually.

--Chuck

[lioric...@gmail.com]

Doubling (and tripling) the frame buffer size works for me (I'm using triple buffering) with the omapfb driver, by setting the kernel arguments at boot time, probably you are using the omapdrm driver

Lioric

-- Sent from my HP TouchPad

[ChuckMcM]

So yes, I am apparently using the omapdrm driver from the fix.id field. I've been reading through the sources but I have not yet found a kernel/boot argument to force it to use omapfb. A pointer would be helpful here if you've got a moment.
--Chuck

[lioric...@gmail.com]

 rmmod omapdrm
modprobe omapfb

If you don't have the omapfb you need to recompile the kernel adding that module. I don't use Ubuntu or any other distro but documentation on that is on omapmedia or other wikis.

Then increase the vram value  at boot time "vram=24M" (or some like that)

I'm doing triple buffering, so my fbset shows 800 600 800 1800

Lioric    


  

-- Sent from my HP TouchPad