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
