Robert Hildinger wrote: > The problem that I keep running into with the driver approach seems to be > with surface pools and my incomplete understanding of the code. Is it a true > statement that DFB disallows gfxdriver functions when the surfaces in > question are not allocated in video memory? In my particular case, my > gfxdriver function never gets called because DFB attempts to negotiate a > surface pool allocation and fails because I have requested that the surface > of the window be created in video memory, whereupon DFB tries to allocate > the surface there and fails with an out-of-memory error.
That's true, DirectFB 1.2.x assumes the accelerator needs a video memory instance. There was a flag CCF_READSYSMEM, but I'm not sure it's still working in 1.2.x, while it did in 1.0.x before the surface pools. > Is there any way to write a gfxdriver that just offers custom software > blitting functions without requiring that the apps themselves be rewritten > to allocate all their surfaces in video memory? With 1.3.x the still only the surface pool can give directions, indicating support for 'GPU' reads/writes, but with 1.5.x it will be the surface pool and surface accessor information that have to match. > Also, do you have any hints as to why video memory allocations always fail > on my platform? Frame buffer device? Maybe just enough space for the visible area, i.e. no offscreen memory available. -- Best regards, Denis Oliver Kropp .------------------------------------------. | 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
