On Tuesday 12 December 2006 16:20, Mark Adams wrote: > > Iam trying to compile xineplug_decode_cle266-0.1 and I hope this is right > > place to ask. I have the latest directfb snapshot as of 12/11/2006. I > > > guess "dfb_surface_hardware_lock" is changed. > > > > Here is my make stdout which is resulted with an error: > > Yes, unfortunately, there was an API change that will have broken that. If > you can fix it, send me a patch. Really, I should re-write the xine > plug-in so that it doesn't use the internal API (which I think I may be > able to do now that there are public methods to get the hardware addresses > of surfaces) but I won't have time to do that for a good while I suspect. > > Your other option is to use DirectFB-1.0.0-rc1 which I think predates the > non-backwards compatible change. > > Mark
I will do my best to write a patch. But dont have that much experience in directfb. What would be the best place to dig in? BTW is it possible to findout and hardcode the surface hardware address in xine_decoder.c? I know it is not nice but at least I can have it working. I am going to try DirectFB-1.0.0-rc1. However, what would be the compatible DFB++ and DirectFB-extra packages in order to compile xine-plugin? At least I want to play with a working device. Two more little questions if you don't mind: 1. Is libcle266 also incompatible with the latest DirectFB packages? 2. I have another topic about xine and hardware-osd problem which has "df_xine-hrwOSD and viafb" topic in the directfb users mailing list. Any idea? _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
