I've put together a basic Virtual Framebuffer driver that when inserted creates N framebuffer devices backed by physically contiguous memory. This could be useful when working with applications/devices that can only render to /dev/fbN device nodes.
Original Attachment has been moved to: 259-virt_fb.tgz
Thanks, it's ok.
Hi,
I am getting following error when i try to insert the virtual_fb.ko in Linux 3.10.17 on wandboard.
ERROR: 256 KiB atomic DMA coherent pool is too small!
Please increase it with coherent_pool= kernel parameter!
(NULL device *): Unable to allocate framebuffer memory
detected fb_set_par error, error code: -12
(NULL device *): Unable to allocate framebuffer memory
detected fb_set_par error, error code: -12
(NULL device *): Unable to allocate framebuffer memory
detected fb_set_par error, error code: -12
How to set coherent_pool= for wandboard which is using uboot? I tried setenv bootargs coherent_pool=6M, but no luck.
Regards,
Vikash
Hi Christophe,
To get the virtual address you can use mmap on the framebuffer file handle. For the physical address you can use FBIOGET_FSCREENINFO framebuffer ioctl and read the smem_start member of the fb_fix_screeninfo structure.
Hi Philip,
have you any Idea what happen to smem_start when using eglSwapBuffers() with that device? How do I get the current read buffer to prevent tearing? Is it even set up double buffered? Need the read-buffer phys-adress for further processing on the ipu.
2nd: We got problems whit make on a 2.6.35 Kernel " make[1]: *** No rule to make target `.config', needed by \ `kernel/config_data.gz'. Stop."
Do you successfully build it on an 35er when you say that removing console_lock() should work.
Thanks for the Driver, when it actually works, it might solve nearly all my Probs. Pure Awesome!
Hi Philip,
I've remplaced console_lock() by the old instruction acquire_console_sem() and it seems to work fine.
I just wonder that is the best way to get physical and virtual address of new fb ?
Hi Christophe,
Yes, I have tested with OpenGLES, OpenVG, and DirectFB. You should be able to remove the console_lock() function from the driver and test like that.
Philip
Hi Philip,
I can see console_lock() is present from 2.6.38 linux version. I'm still using 2.6.35.
Did you test your driver with openGLES ?
Hi Philip,
Your idea is very good.
I'm trying to test it but i encounter some error when compiling the kernel with ./ltib -m scbuild -p kernel:
CC [M] kernel/virtual_fb.o
kernel/virtual_fb.c: In function 'virtfb_register':
kernel/virtual_fb.c:401: error: implicit declaration of function 'console_lock'
kernel/virtual_fb.c:405: error: implicit declaration of function 'console_unlock'
make[1]: *** [kernel/virtual_fb.o] Error 1
make: *** [kernel] Error 2
I'm not very familiar with kernel code, so maybe you could have a hint or a fix about that.
Thanks.
Permalink Reply by H R Krishna Pavan on March 13, 2012 at 7:16am Hi Philip
Hi,
No, actually the driver is only virtual. All display configuration, etc has been stripped out of it. This is basically a chunk of memory with a /dev/fb devnode associated with it.
Philip
Hi Philip Hatcher,
Can it be possible that, we connect another display to imx board and use virtual fb driver, to stream content to that extra display?
Please Suggest!
I good example are the graphics API like OpenVG or OpenGLES which use an EGL binding to the underlying window system for rendering to visible or "window" surfaces. In the EGL implementation where the /dev/fb handle is the native window type the GPU will render to the framebuffer directly. Imagine that you would like to render to a target that is offscree, but that you would like to have access the image without using the expensive readpixel APIs. Rendering to a virtual framebuffer gives you this possibility.
Hi Philip,
Can you please provide some sample code on how to create/use a virtual framebuffer ? I want to try this as an alternative to using an OpenGL FBO.
So I finally mastered the setup of the framebuffer device.
Now i stuck at: eglSurface= eglCreateWindowSurface(eglDisplay, eglConfig, fbdev, NULL);
with fbdev set to the framebuffer, checked all properties, give enough virtual space (quadruple y-size) for double or triple buffer, but the whole memory area stays zero.
The egl setup is OK, since it runs before with same attributes of resolution and glReadPixels(...). Now with eglSwapBuffers(eglDisplay, eglSurface); nothing appears in the physical memory area (all along the virtual x and y -space). What am I missing when switched from EGL_SURFACE_TYPE = EGL_PBUFFER_BIT to
EGL_VG_COLORSPACE_LINEAR_BIT and this virtual frame buffer?
thanks a lot.
Hi Philip Hatcher,
/dev/fb0
The first framebuffer device. A framebuffer is an abstraction layer between software and graphics hardware. This means that applications do not need to know about what kind of hardware you have but merely how to communicate with the framebuffer driver's API (Application Programming Interface) which is well defined and standardized. The framebuffer is a character device and is on major node 29 and minor 0.
From your post
This could be useful when working with applications/devices that can only render to /dev/fbN device nodes.
Can you please explain with an example.
I am trying to know about this VirtualFB Driver.
There is a README in the package with instructions for building and usage. The sources can be unzipped anywhere you want. The software is a kernel module intended to be built out of tree.
Best Regards,
Philip
Hi Philip Hatcher,
Can you please mention the procedure also.
Where to place in the Kernel Source Code?
Any Changes that we are supposed to make to the Makefile?
thanks & regards :: Krishna Pavan