Thanks again Niels. I'm not sure I follow you to a 100% but am I correct to assume that the system memory in my case is the buffer I allocate in my driver and video memory the overlay buffer that the HW actually use to render the video?
I will try to dig into the code but does anyone have any tips on a good driver to use as a starting point match matches my "needs"? I did a quick hack and verified that it was possible to access the coherent memory that I allocated in my driver via /dev/mem. Is this a big NO NO to do like this and does anyone know if this introduce any risks? cheers, Jonas Romfelt 2010/2/23 Niels Roest <ni...@directfb.org>: > It sounds like you want to have "video" memory. > > DirectFB has two main concepts of memory, namely system (let's say malloc()d > memory) and video (let's say graphics memory) memory. You can make different > types of memory using the memory pools as you see implemented in the > systems. DirectFB picks a pool (system and video are also two pools, try > dfbdump -p) based on the flags passed during allocation. > > Now you can have a layer surface with one video and one system buffer, so > you can access the back buffer in software, and do a hardware-accelerated > blit on flipping the layer. You can also have a layer with two video > buffers, so you can do hardware accelerated drawing in the back buffer, but > then you need to blit a software system memory buffer to the card memory "by > hand". It's all in the drivers. > > Unfortunately this probably needs a longer explanation to be more > understandable. > > Greets > Niels > > Jonas Romfelt wrote: >> >> Thanks for your reply and clarification Niels. >> >> Since I already have a driver that does much more than being a pure >> frame buffer, I plan to go on with implementing a graphics driver, >> obviously(!) raising few questions. >> >> In my kernel driver I allocate a coherent DMA buffer. My plan was to >> allow DirectFB mmap() this buffer and use DirectFB to create the >> graphics overlay in this buffer. Then DMA this content over to my >> overlay HW as an action on calling DirectFB Flip(). >> >> Is it possible to use the system driver "devmem" on memory that is not >> physical memory? As I mention above I would like to use kernel >> allocated memory. Since I have a PCIe device whose DDR RAM is not >> accessible other than via a on-PCIe-board DMA it is not(?) possible to >> address the overlay memory using a physical address directly. >> >> Browsing through the mailing list archive I found a discussion >> concerning "sysmem": >> http://www.mail-archive.com/directfb-dev@directfb.org/msg06842.html >> >> It looked promising and very much like what I'm looking for. I tried >> to dig into the code of DirectFB but couldn't see that any of this was >> in main-line. Am I missing it or isn't it there? >> >> Also, is there a good starting point for a graphics _simplistic_ driver? >> >> Any help is much appreciated, my intention is to document my work >> publically with the intention that it could be helpful for others. >> >> Cheers, >> Jonas Romfelt >> >> >> 2010/2/19 Niels Roest <ni...@directfb.org>: >> >>> >>> Hi there Jonas. >>> >>> DirectFB needs a "system driver" and it can optionally have a "graphics >>> driver". >>> If you go for (1), you can reuse the "fbdev" system driver and leave out >>> the >>> graphics driver, since fbdev already does mapping/flipping etc. >>> If you go for (2), you are best off using the "devmem" system which is >>> basically an empty system which relies on the graphics driver to provide >>> the >>> functionality. so for (1), you only program the linux kernel driver, for >>> (2) >>> you make a new graphics driver. Your choice. >>> >>> Greets >>> Niels >>> >>> Jonas Romfelt wrote: >>> >>>> >>>> Hi, >>>> >>>> I'm new to DirectFB and need some high-level pointers in the right >>>> direction how to add DirectFB support to an embedded system that >>>> working on. I'm adding a custom FPGA via PCIe that provides a >>>> simplistic graphical overlay functionality. Nothing fancy such as HW >>>> acceleration, just a framebuffer, anything that goes into that memory >>>> is displayed. >>>> >>>> I have got a custom kernel module that allows access to the >>>> framebuffer memory via a kernel bounce buffer that can be mmap'd from >>>> user space. The FPGA also handles numerous other things... >>>> >>>> How do support my custom HW from DirectFB? So, should I: >>>> >>>> 1) make my driver appear as a "standard" Linux framebuffer device >>>> driver? >>>> 2) make a custom DirectFB gfxdriver for my custom Linux kernel driver? >>>> >>>> Are both approaches viable? >>>> >>>> Is at simple as (1) if I have a "standardized" framebuffer device >>>> driver I can go ahead using DirectFB without any modifications? And if >>>> I already have a working driver (2) I basically only need to a add a >>>> thin gfxdriver that maps in my custom driver? >>>> >>>> What is the recommended way of doing it? >>>> >>>> Many thanks, >>>> Jonas >>>> _______________________________________________ >>>> directfb-dev mailing list >>>> directfb-dev@directfb.org >>>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >>>> >>>> >>>> >>> >>> -- >>> >>> .------------------------------------------. >>> | DirectFB - Hardware accelerated graphics | >>> | http://www.directfb.org/ | >>> "------------------------------------------" >>> >>> >> >> > > > -- > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
