Recompiling mplayer takes quite some time. I suggest to take the compilation of mga_vid.o to a separate package. The reason: recompiling the kernel would only require to recompile one, very quick to compile package instead of the whole mplayer. Mplayer can depend on the package if needed.
Created attachment 17790 [details] mga_vid-1.0_pre1.ebuild an ebuild for mga_vid
Created attachment 17791 [details, diff] mplayer-1.0_pre1.patch A patch to the mplayer ebuild to finalize the split of mplayer and mga_vid
perhaps we could come up with a better solution ... there are many packages (like svgalib) that have kernel modules which are a small part compared to the rest of the distribution ...
After typing for a while here, I decided to take my comment to gentoo-dev@gentoo.org in a search for a "better solution".
phoenix any comment ?
What about putting it in /lib/modeuls/*/misc/ so that it doesn't get blown away by make modules_install?
Created attachment 31184 [details] mplayer ebuild to put mga_vid.o in misc directory This attachment simply moves the location of the mga_vid.o module to /lib/modules/*/misc/mga_vid.o That should fix the original problem because when the kernel modules are rebuilt, the misc directory will be left alone. Does anybody strenously object to this solution? If not, then I will submit this change in the next few days.
Not sure how this will help. The original problem is that when a new kernel is installed, one has to rebuild the complete mplayer package. I don't see how this would hurt either, so if you feel like -- go ahead and assign it. This would not resolve this bug though. You could mark it as INVALID or WONTFIX though.
Okay, well, that wasn't clear from the original bug request. "recompiling the kernel would only require..." implies to me that we are recompiling the same kernel again. I will probably submit the changes that I made, but not close this bug.
Georgi Georgiev and everyone on this bug: Ok, I was dealing with the matrox issue in another bug, and came across this. My idea was as follows: 1) make sure that the kernel 2.6 matrox patch for 1.0_pre4-r4 works (need a matrox tester for that :). 2) if it does, a modified mplayer ebuild could be created, as I found out from the mplayer site, that technically the mga driver should be compiled first, then the mplayer code. 3) if this was the case, the matrox USE flag could encompass a separate compile process within the ebuild, leaving the intended result. Most important is to see if all is well with 2.6 patch included in 1.0_pre4-r4. If that works, all might be well.
Regarding the order of compilation: it doesn't seem to matter at all. The patch itself: It does work, though it doesn't work for udev, so devices have to be created manually. I was trying to enable udev (sysfs) support, by looking at the basic-sysfs patch for nvidia-kernel, but it didn't work. This shouldn't surprise me, since nvidia-kernel doesn't work with sysfs either. About the ebuild: The current Makefile doesn't compile the module on a KBUILD_OUTPUT enabled kernel. I am using a separate Makefile for 2.6 compilation.
Created attachment 34256 [details] mga_vid-1.0_pre4-r4.ebuild My mga_vid ebuild. To use as a reference for the mplayer ebuild.
Created attachment 34257 [details] Makefile-2.6 The Makefile to compile the module. The current Makefile doesn't work when using KERNEL_OUTPUT
http://thread.gmane.org/gmane.linux.gentoo.devel/19644
Created attachment 37867 [details, diff] patch to mplayer-1.0_pre4-r7.ebuild
Comment on attachment 37867 [details, diff] patch to mplayer-1.0_pre4-r7.ebuild mplayer-1.0_pre4-r7.ebuild does not build mga_vid correctly. The ebuild does: build mga_vid configure make all (This performs a distclean because we just configured, but then it does not build mga_vid again.) install (cannot stat `mga_vid.o': No such file or directory) Attached is a patch to the ebuild to build mga_vid again before the install step. The pre5 ebuilds appear to have the same problem.
I've decided to remove the matrox building sections all together, but the SUPPORT for matrox in MPlayer will still be avaliable. My main reason for doing this comes straight from the README: WARNING ----- WARNING This code messes with your video card and your xserver. It will probably lock up your box, format your hard drive, and cause your brand new g400 MAX to spout 6 inch flames. You have been warned. WARNING ----- WARNING mga_vid is also a monster hack in fact, the whole design sounds very unstable to me. So unstable in fact, that I simply cannot support it, as it sounds like it doesn't want to be supported in the first place. Does this mean you'll won't be able to use MPlayer with matrox support? No, the matrox configure logic still remains, it will be up to you to compile it "at your own risk". I'm sure this may not go down well with some people, and can already see flames comming my way, but I simply cannot support something that the authors themselves consider unstable.
