As I added a new ebuild for media-libs/vidix in bug #117582 will provide a patch to mplayer-1.0_pre7-r1.ebuild
Created attachment 76074 [details, diff] mplayer-1.0_pre7-r1.ebuild-vidix.patch Test compiled on x86. the useflags (the logic when svga and vidix interact) might be a bit off, somebody that has the knowledge, please look at this.
Shrug... This has already been discussed in Bug 76420, the result being that vidix does not work without svgalib for most users (not sure whether external or internal does matter here).
So, then... The normal case should be USE="svaga vidix" ... According to the vidix page, it is now separate from ... mplayerxp (Aha, see the XP? I did now :-( ) Let me think a bit if I can tweak the patch...
vidix.sf.net isn't ready for stand-alone consumption
not to mention that isn't endorsed by upstream developers.
Created attachment 76080 [details, diff] mplayer-1.0_pre7-r1.ebuild-vidix.patch This is a quite better patch, IMHO. It works (emerges with no error) for USE="svga vidix". Right now I am on i810 video, so no vidix drivers and cannot run test. As long as I can see, this patch does not change the result of the emerge, apart from adding a new dependency ( >=media-libs/vidix-0.9.9.1). ALA comment #4 goes, yes it does lack some docs, but as it was once said "if it compiles, emerge it" comment #5 : couldn't find anything on the MPlayer site, maybe the ML? Not subscribed since quite a while. I had a look with meld (a powerfull diff util) at: /var/tmp/portage/mplayer-1.0_pre7-r1/work/MPlayer-1.0pre7try2/vidix /var/tmp/portage/vidix-0.9.9.1/work/vidix-0.9.9.1/vidix And I see a bit of differences. Some of the drivers look newer in mplayer, some in vidix. Probably a CVS log dissection will help here, or just ask on the mplayer list what is the status of this external vidix. I am OK with RESOLVED LATER, just trying to make things better.
