> On Wednesday 08 January 2003 18:04, Brian S. Julin wrote: > > I'll try to update to -15 and fix tonight. Again, I don't have any > > hardware to test with, so it is very likely broken in runtime. > > It was fine last time with my (taking cover; where's that unreadable > font) nvidia, them non-free s... > thanks, i'm currently looking after it too. mail you, martin -- BSJ: Yeah, It should be easy unless they really tangled things up again. I'm working on it now. -- BSJ: It looks like they did some major internal reworking. �More than I -- BSJ: OK, give it a test I guess... Brian
RCS file: /cvsroot/ggi/ggi-core/libggi/default/fbdev/directfb/directfbglobal.c,v Working file: directfbglobal.c head: 1.7 ---------------------------- revision 1.7 date: 2003/01/10 00:56:35; �author: skids; �state: Exp; �lines: +48 -5 Add new names for old functions and new dummy functions for 0.15. -- MA: Compiles nicely. Thanks! Runs fine except directfb gfxdrvrs don't get loaded. -- MA: The relevant test failing is default/fbdev/directfb/visual.c::326. Now i studied 'some' structures to see what's going. Is this simply libdfb's fault? Yes, it is. Modules using conditional compilation in their probe()s should include the relevant headers defining the symbols used. To make use of accelerated ati/nvidia/tdfx with debian directfb_0.9-15-2 add '#include <linux/fb.h>' to the main modules of said drivers. Guess, i add new directfbglobals with the diff and upload libggi-2.0.2. (mentioned in the changelog naturally) ?? Once directfb gets fixed, there should be accel. When they update, libggi has to be recompiled (as they hardcode version into lib/directfb-version/gfxdrivers and libggi gets this at build time). martin
