They've changed the API, and the current DirectFB-extra sources use the old API. For DirectFB-extra-0.9.23 it comes down to one function call in <path in var>/interfaces/IDirectFBVideoProvider/video_out_dfb/video_out_dfb.c: --- video_out_dfb.c +++ video_out_dfb.c @@ -1881,7 +1881,7 @@ } #endif - dfb_state_init( &this->state ); + dfb_state_init( &this->state, NULL ); this->mixer.b = 0; this->mixer.c = +128; However, other changes to DirectFB-extra have been made, so I can't say if patching the current sources in portage is even a fix or a valid workaround. For one, it only works against DirectFB-extra-0.9.23. With 0.9.22, there are missing struct members in video_out_dfb.c, as well as the above difference: video_out_dfb.c: In function 'vo_dfb_set_palette': video_out_dfb.c:992: error: 'vo_overlay_t' has no member named 'clip_rgb_clut' video_out_dfb.c:993: error: 'vo_overlay_t' has no member named 'clip_color' video_out_dfb.c:994: error: 'vo_overlay_t' has no member named 'clip_color' video_out_dfb.c:995: error: 'vo_overlay_t' has no member named 'clip_trans' video_out_dfb.c:1038: error: 'vo_overlay_t' has no member named 'clip_rgb_clut' video_out_dfb.c: In function 'vo_dfb_overlay_blend': video_out_dfb.c:1114: error: 'vo_overlay_t' has no member named 'clip_rgb_clut' video_out_dfb.c:1125: error: 'vo_overlay_t' has no member named 'clip_left' video_out_dfb.c:1126: error: 'vo_overlay_t' has no member named 'clip_top' video_out_dfb.c:1127: error: 'vo_overlay_t' has no member named 'clip_right' video_out_dfb.c:1128: error: 'vo_overlay_t' has no member named 'clip_bottom' video_out_dfb.c:1170: error: 'vo_overlay_t' has no member named 'clip_color' video_out_dfb.c:1259: error: 'vo_overlay_t' has no member named 'clip_color' A diff against the current CVS and 0.9.23 for just that one file gives this: --- video_out_dfb.c (0.9.23) +++ video_out_dfb.c (CVS) @@ -1452,6 +1452,8 @@ this->output_ratio = 2.0; break; default: + this->output_ratio = (double)(ratio >> 16) / + (double)(ratio & 0xffff); break; } } @@ -1474,13 +1476,11 @@ break; case VO_PROP_ASPECT_RATIO: - if (value >= 0 && value <= 4) { - xprintf( this->xine, XINE_VERBOSITY_DEBUG, - "video_out_dfb: setting aspect ratio to %i\n", - value ); - vo_dfb_set_output_ratio( this, value ); - this->aspect_ratio = value; - } + xprintf( this->xine, XINE_VERBOSITY_DEBUG, + "video_out_dfb: setting aspect ratio to %i\n", + value ); + vo_dfb_set_output_ratio( this, value ); + this->aspect_ratio = value; break; case VO_PROP_BRIGHTNESS: @@ -1545,7 +1545,7 @@ case VO_PROP_ASPECT_RATIO: *min = 0; - *max = +4; + *max = +0xffffffff; break; case VO_PROP_BRIGHTNESS: @@ -1881,7 +1881,7 @@ } #endif - dfb_state_init( &this->state ); + dfb_state_init( &this->state, NULL ); this->mixer.b = 0; this->mixer.c = +128; The differences between CVS and 0.9.22 are even greater.
Hi! I also noticed it breaks not only DirectFB-extra, but also all of SDL, since the SDL ebuilds in portage do not use the new API yet. This is quite serious I think, since so many apps depend on SDL. So, IMHO, this ebuild should be masked until an updated or patched versions of (at least) SDL and DirectFB-extra enter portage. Hugs, ale
Ooops, a correction... it probably only breaks SDL if you have the "directfb" useflag enabled (duh!), so it's not that bad, maybe it's preferred to let people who enable that useflag package.mask DirectFB-0.9.25.1 . unless use of this useflag is very frequent, but I have no idea... thanks (and sorry), ale
That's odd. I had no problem with libsdl.
if this is broken in upstream cvs, it should be fixed there and then ask them for a new release to go with 0.9.25.1+
(In reply to comment #4) > if this is broken in upstream cvs, it should be fixed there and then ask them > for a new release to go with 0.9.25.1+ > It's not that it's broken. DirectFB-extra works fine, as long as you don't use DirectFB-0.9.25+. The problem is, they haven't bothered to put a new tarball together for DirectFB-extra, one that reflects the changes to the API. Until they do, DirectFB-0.9.25+ should probably be hard masked, since it's basically guaranteed to break stuff.
> It's not that it's broken. DirectFB-extra works fine, as long as you don't use > DirectFB-0.9.25+. then it's broken ask them to release a new version
(In reply to comment #6) > > It's not that it's broken. DirectFB-extra works fine, as long as you don't use > > DirectFB-0.9.25+. > > then it's broken > > ask them to release a new version > No, it's broken when it's supposed to work with something and doesn't. It's not supposed to work with DirectFB-0.9.25+, therefore it behaves as it should: it doesn't work. BTW, they already know about this upstream. It's been discussed on the devel list.
DirectFB-extra-0.9.25 is now released
(In reply to comment #8) > DirectFB-extra-0.9.25 is now released ... And it compiles fine using the DirectFB-extra-0.9.23 ebuild renamed to 0.9.25
broken/dated/use whatever stupid semantic wording you prefer ... the point is we're not going to patch old versions ive done the correct thing and version bumped it, thanks for the heads up H
broken/dated/use whatever stupid semantic wording you prefer ... the point is we're not going to patch old versions ive done the correct thing and version bumped it, thanks for the heads up Håvard
(In reply to comment #10) > broken/dated/use whatever stupid semantic wording you prefer ... the point is > we're not going to patch old versions > > ive done the correct thing and version bumped it, thanks for the heads up > H
(In reply to comment #10) > broken/dated/use whatever stupid semantic wording you prefer ... the point is > we're not going to patch old versions > > ive done the correct thing and version bumped it, thanks for the heads up > Håvard > Who said anything about patching old versions? I only put the diff up to show how *different* things were. If I'd been interested in patching it, I'd have submitted a patch. Sure, you could've compiled it, and I did, but my point was that it probably wasn't a good idea.
