Hi Bernd. Not sure what you know and what you don't so I will just answer your questions. Screen = the screen that you are looking at. Representation of your LCD/CRT. Layer = single 'hardware' layer. You should visualize these as being stacked on top of each other like a pile of transparent papers, while you are looking at the top one (screen). In embedded devices, you normally have a number of layers with different sources, e.g. YUV for video sources and RGB for graphics or OSD. These are mixed together in hardware. If you use the framebuffer device, you normally have just 1 layer. DirectFB will take care of mixing in software.
If you don't use the FB device, you have to do a number of things yourself; this means tinkering with the IO space of your card. Basically, this means you will have to implement the screen functions and the layer functions. Since you mention sh7722, these are called here sh7722ScreenFuncs and sh7722LayerFuncs (don't forget to register them). have a look at sh7722_layer.c etc. to get you started. Acceleration is not needed yet, software fallback is used when no graphic acceleration functions are passed via GraphicsDeviceFuncs. Memory is reserved from memory pools. Normally, surfaces (such as front/backbuffers) are reserved from these pools. If you have only one single pool (this can be useful if you have a flat memory architecture) these reserved ranges that you mention are not further interesting. Otherwise, you will have to create a special video memory pool of size 20 MB, DirectFB will then simply allocate from that (if there is no other pool in your system). dfbdump -a or dfbdump -p might interest you. hth, Niels Weber, Bernd wrote: > > Hi all, > > I’ve been trying to write a graphic driver for DirectFB for some time > now but always end up with the same problems. It seems that the memory > addresses I get from the underlying architecture are not working when > I perform operations on them (I used > state->src->phys/state->dest->phys). The result is just > black/transparent (0x00000000) for some regions on the screen. > > Anyway I looked around and found the sh7722 driver in the system. Till > now I used fbdev as a system. So now I want to give it a try with devmem. > > The thing I don’t completely understand though is the different parts > of the architecture I have to implement there, like screen and layers. > So what does each of them really stand for? What part of the system > would be the memory region that actually maps into the framebuffer (I > guess this is the frontbuffer) and what part stands for the > composition buffer (I guess the backbuffer?!)? How do I have to set up > the screen and the layers so that the frontbuffer lies in the > (visible) framebuffer region and the backbuffer lies in the rest of > the allocated framebuffer region that is not visible. I reserve 20MB > of space when initializing the frambuffer device. Of these 20MB 8MB > are used for a 1920x1080x32 visible framebuffer. Maybe I’m doing this > completely wrong?! > > The goal would be to have all regions of memory that are drawn into in > that 20MB framebuffer memory region. Or do I have to have the > framebuffer as 8MB and create another memory region with ?? MB as > backbuffer to do the window creation there and have blitting > operations move stuff in between the two of them?! > > I’d be very grateful for any advise or help anybody can give me on this! > > -Bernd > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ > > _______________________________________________ > 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
