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-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
