Mark Adams a écrit : >>Unfortunately, the frame buffer driver will be the only work >>I will do, because it's not possible to integrate their patch >>for the libmpeg3 video provider. It's a h*** and just adds another >>PlayTo() method that doesn't use DirectFB for surface management. >>It implicitly uses the video layer via libddmpeg and their kernel >>module. Memory management will collide if you do something more >>sophisticated with DirectFB. > > Oh dear, that's a shame :-( > > Can VIA not be persuaded to release the source for libddmpeg to you?
There was a lot of reverse-engineering work done by people on the open-source unichrome X driver. They in fact went to the point of having a full open-source implementation of libddmpeg, but they tied this to XvMC. I think the best way is to get this implementation and get rid of X dependencies. VIA proved many time that they do not fully support open-source. Just looking at how the kernel frame-buffer driver is coded and distributed is a clue... >>I don't know what VIA is going to do with the enhanced frame buffer >>driver. The last (source) version seems to be from Feb 3rd this year. >>It doesn't compile for me using 2.6.13.2, the cursor stuff needs to >>be updated. I was in contact with them in June... > > There's a newer one than that, here: > > http://www.viaarena.com/default.aspx?PageID=420&OSID=25&CatID=2580&SubCatID=101 > > This compiles with 2.6.11 (albeit with lots of warnings). I haven't > tried loading it. I tried this one with 2.6.11, thus the patch I sent to Denis. > I see they've changed the representation of the TV encoder config but > I'm sure I can provide a patch for a nice 720x576 non-scaled mode. > I'd be happy to take a look at that once you've got a working > DirectFB-compatible framebuffer. I'll follow you with the vt1622 non-scaled mode. -- NH _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
