Mplayer can not go to (x)vidix modes as non-root user. This tiny addition adds the missing functionality. Reproducible: Always Steps to Reproduce: 1. emerge mplayer-0.90 2. run 'mplayer -vo xvidix foo.video' as normal user 3. watch mplayer die with the following message: [module] Error occured during pci scan: Operation not permitted vosub_vidix: Couldn't find working VIDIX driver Error opening/initializing the selected video_out (-vo) device. Expected Results: Played the video, for example. Portage 2.0.47-r10 (default-x86-1.4, gcc-3.2.2, glibc-2.3.1-r4) ================================================================= System uname: 2.4.21_pre7-gss i686 AMD Athlon(tm) processor GENTOO_MIRRORS="http://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ " CONFIG_PROTECT="/etc /var/qmail/control /usr/share/config /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="/usr/portage-overlay" USE="x86 3dnow apm avi crypt gif jpeg libg++ mikmod mmx mpeg ncurses nls pdflib png quicktime truetype xml2 xmms xv zlib gdbm berkdb slang readline sdl tcpd pam libwww ssl perl python esd imlib oggvorbis gtk motif opengl aalib bonobo gnome cups dvd ggi gtkhtml guile java mozilla nas svga tcltk ogg vorbis objprelink fbcon oss mhash mcrypt encode -alsa -arts -kde -gpm qt directfb X gtk2 ggz cdr evo imap -ldap spell pda mysql gd" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=athlon-tbird -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args" CXXFLAGS="-march=athlon-tbird -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j2" AUTOCLEAN="yes" SYNC="rsync://rsync.gentoo.org/gentoo-portage" FEATURES="sandbox ccache"
Created attachment 11255 [details, diff] patch against mplayer-0.90.ebuild
Created attachment 11257 [details, diff] patch against mplayer-0.90-r1.ebuild Martin was faster. :)
gtk? ( mirror://gentoo/distfiles/default-skin-0.1.tar.bz2 ) should be gtk? ( mirror://gentoo/default-skin-0.1.tar.bz2 )
Patch against mplayer-0.90-r2.ebuild. Come on, apply this patch already. @svrmarty-: Took care of that.
Created attachment 14506 [details, diff] Patch against mplayer-0.90-r2.ebuild
added in -r3
Created attachment 14542 [details, diff] Patch against mplayer-0.90-r3.ebuild Not really. You forgot to add pkg_setup / modify src_compile. However, the SRC_URI is correct. Fix this, please.
*** Bug 24594 has been marked as a duplicate of this bug. ***
quoting mholzers mail ---cut--- $ emerge mplayer-0.90-r3.ebuild Calculating dependencies ...done! >>> emerge (1 of 1) media-video/mplayer-0.90-r3 to / >>> md5 src_uri ;-) MPlayer-0.90.tar.bz2 >>> md5 src_uri ;-) font-arial-iso-8859-1.tar.bz2 >>> md5 src_uri ;-) font-arial-iso-8859-2.tar.bz2 >>> md5 src_uri ;-) default-skin-0.1.tar.bz2 >>> md5 src_uri ;-) svgalib_helper-1.9.17-mplayer.tar.bz2 * Modprobing svgalib_helper modprobe: Can't locate module svgalib_helper !!! ERROR: media-video/mplayer-0.90-r3 failed. !!! Function dyn_setup, Line 436, Exitcode 255 !!! pkg_setup function failed; exiting. ---cut--- Where is this module from, one might ask. Well, svgalib_helper.o comes with media-libs/svgalib. Apparently, media-libs/svgalib only generates a module for the current (booted) kernel, so if you switch to a newer kernel you would have to remerge svgalib. However, i got another (and more correct approach to deal with this problem). This patch (attached) builds svgalib_helper before the actual compile of mplayer and modprobes the resulting module. If there already is a loaded module by the name svgalib_helper, it unloads it and loads the newly compiled version.
Created attachment 14556 [details, diff] Patch against mplayer-0.90-r3.ebuild BUGFIX Fixed: - svgalib_helper.o borkage. - put the code in a new function, namely svgalib_helper_setup() to make it more atomic
bugfixed -r3 in cvs
Excuse my ignorance - but what is more correct about this than having it with svgalib ? If you recompile your kernel, it will still need recompiling itself.
Hey there Martin. This is the interesting part from the mplayer documentation: http://www.mplayerhq.hu/DOCS/video.html#vidix One *could* use the svgalib_helper module from svgalib, yes. But since i don't see a nice way to make sure that the current kernel has a svgalib_helper lying around (sure sh magic could do the trick, but i dont consider that nice) i sticked to compiling the module in mplayer.ebuild itself. The big problem behind this is that a cleanly merged svgalib does not make sure that the current kernel has an svgalib_helper module: Maybe the user just forgot to remerge svgalib after he upgraded to a new kernel. IMO this is a generic problem with the way gentoo handles its kernels: I for one always make sure to remerge ebuilds that provide kernelmodules (on my box these are: emu10k1, ati-drivers and svgalib). There should be a solution to automagically clean these issues: For example watching the uname of the system and remerging (or at least warning the user) packages which provide kernel modules. Your turn again. :) -phoen][x-
The point is, you still have to remerge something currently - wheather its svgalib or mplayer. What this causes for the mplayer ebuild, is unneded cruft - rather plain ugly if you dont mind my saying :P The better solution (IMHO of course), will be to do a svgalib-kernel or something ebuild that you can remember on kernel change.
The svgalib_helper module that comes with svgalib_helper-1.9.17-mplayer.tar.bz2 is a patched version of the original svgalib_helper. A simple diff of both shows only a few (IMO trivial) changes, so it should be pretty safe to use the original svgalib_helper module included in the svgalib ebuild. This still leaves the problem of remerging packages on kernel upgrades: The current way is quite awful. I dont see a point in creating an svgalib-kernel ebuild since it would provide the same stuff svgalib provides. And it would still force users to remerge this ebuild on kernel upgrades.
Created attachment 14988 [details, diff] mplayer-0.90-r3.ebuild.patch Here is another patch which strips everything svgalib_helper.o related from the current mplayer ebuild, but leaves the vidix non-root mode intact. AFAICS, this is what you wanted in the first place. Is that okay with you, Mr. Schlemmer? :) One still needs a decent way to deal with kernel upgrades in gentoo... -phoen][x-
Could work, yes. About the svgalib-kernel .... it will be faster to just remerge the kernel module, than the whole thing.
