On Sun, Feb 14, 2010 at 12:54:09AM +0100, Lionel Landwerlin wrote: > Le samedi 13 février 2010 à 23:41 +0200, Ville Syrjälä a écrit : > > On Sat, Feb 13, 2010 at 07:49:37PM +0100, Lionel Landwerlin wrote: > > > The null system avoids dependency on a particular system (like fbdev, > > > devmem, etc...) > > > when you're writing a gfxdriver for relaying on proprietary interfaces, > > > which can't be > > > exposed in an opensource project. > > > The behavior of this system is to answer "no" to any memory allocation > > > request, so the > > > requests are redirected to the gfxdriver which implements its own > > > allocation system. > > > > > > Signed-off-by: Lionel Landwerlin <llandwer...@gmail.com> > > > --- > > > configure.in | 68 +++++++----- > > > src/core/system.h | 7 +- > > > src/misc/conf.c | 12 +- > > > systems/Makefile.am | 10 ++- > > > systems/null/Makefile.am | 38 +++++++ > > > systems/null/null.c | 187 +++++++++++++++++++++++++++++++++ > > > systems/null/null.h | 14 +++ > > > systems/null/null_surface_pool.c | 211 > > > ++++++++++++++++++++++++++++++++++++++ > > > > Why exactly do you need this dummy pool when it does nothing? > > It's just a suggestion. Some people are working with proprietary source > and non standard driver interfaces. None of the existing systems matches > such interfaces. Instead of integrating a specific system in the > DirectFB's sources (which can't be released anyway), we propose the > following solution.
I can understand the reason for the null system module but not the null surface pool. > In order to allocate video memory through non standard interfaces, we > could rely on such "null" system that implicitly redirects the memory > allocations requests to the next memory pool. Hopefully, the gfxdriver > might have registred its own buffer allocation pool. But it would work exactly the same without the null surface pool, right? I don't think there's any rule that a system module must register a surface pool. -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
