My intention is actually two-fold. A repeated problem is that people don't like to upgrade working systems, yet at this time, I cannot bring a new frontend only using packages to load a new .20.2 frontend. I current have a Via system running minimyth currently, an older AMD frontends, an older Intel, and this Core 2 Duo (3Ghz.) I'm thinking to use minimyth for my version control, and make three or four builds to support my systems.
I've successfully compiled minimyth from "source" previously as one of my boxes has a video card that requires a legacy driver. Additionally, I will need to add enough 3D support or libraries to make StepMania useable (the only thing I use MythGame to run.)
1. Prepare minimyth with the latest kernel (126.96.36.199) and MythTV 0.22.2 optimized for the Core 2 Duo.
2. Document the process of creating new backends for older versions of minimyth for maintenance (as in my case.)
3. Install and make working StepMania on the platform.
4. Recompile the sources in step 1 optimized for Via.
5. Recompile the sources in step 2 optimized for AMD (perhaps 2 cards because different legacy NVidia drivers may be required.)
6. Determine if network booting performance is acceptable, or install on local hard drives.
As Intel support grows stronger, I am hoping that HDMI + Audio will be working with no problem, but we'll see how we progress. I'm not as hopeful about the H.264 hardware accelerations, I think they've been working on VA API for a couple of years, and it is still vapor-ware.
Given this plan:
1. Is anyone else interested in the outcome?
2. Are there any suggestions that I need to consider or issues to take into account with this plan?
What 3D support is currently missing?Additionally, I will need to add enough 3D support or libraries to make StepMania useable (the only thing I use MythGame to run.)
I assume that you mean the 188.8.131.52 kernel. Is there something in this kernel that this hardware needs?1. Prepare minimyth with the latest kernel (184.108.40.206) and MythTV 0.22.2 optimized for the Core 2 Duo.
I assume that you mean MythTV 0.20.2. Since multiple people have needed MiniMyth with MythTV 0.20, I have added MythTV 0.20 to the MiniMyth build system. As I cannot test it (other than build it), I hope that it works.
I suspect the x86_64 build should be reasonably optimized for the Core 2 Duo.
Actually, there may not be anything missing. In the past, I've not tried to add stepmania to minimyth. It may just work.Pablo wrote:What 3D support is currently missing?Additionally, I will need to add enough 3D support or libraries to make StepMania useable (the only thing I use MythGame to run.)
I thought I proof-read this message many times, but I guess not close enough. You are correct, the 220.127.116.11 kernel. The 2.6.26 kernel added support for the 82567LM Gigabit Ethernet Controller. In order to bootstrap my fedora 9 system, I downloaded this kernel and compiled the e1000e module against my running kernel and luckily it worked.Pablo wrote:I assume that you mean the 18.104.22.168 kernel. Is there something in this kernel that this hardware needs?1. Prepare minimyth with the latest kernel (22.214.171.124) and MythTV 0.22.2 optimized for the Core 2 Duo.
Again, you are correct, though I had expected Minimyth to build against 20 since I seem to remember when I last built it minimyth supported both 20 and 19...Pablo wrote: I assume that you mean MythTV 0.20.2. Since multiple people have needed MiniMyth with MythTV 0.20, I have added MythTV 0.20 to the MiniMyth build system. As I cannot test it (other than build it), I hope that it works.
I suspect the x86_64 build should be reasonably optimized for the Core 2 Duo.
I've browsed through the build system, and would agree... The only thing missing for me at this time is the updated kernel. Minimyth already includes the 2.4.2 intel video driver that supports the G45 chipset.
Do you forsee any issues with SMP? Or are the items like ffmpeg already compiled with multi-core support?
It's fairly clear to me already that this rig is going to have difficulty decoding h.264 content, though I still have a lot of configuration to do, and bugs in the intel driver to work around. This motherboard suffers from this bug:
I see. I have checked in support for the 2.6.26 kernel.azawacki wrote:The 2.6.26 kernel added support for the 82567LM Gigabit Ethernet Controller. In order to bootstrap my fedora 9 system, I downloaded this kernel and compiled the e1000e module against my running kernel and luckily it worked.
The kernel is compiled for multi-core support. Whether a particular application or library can make use of multiple cores depends on the application or library. In the case of FFmpeg, there is was SoC work to multi-thread decoders such as the H.264 decoder. However, I am not sure the current status.Do you forsee any issues with SMP? Or are the items like ffmpeg already compiled with multi-core support?
Also, I know that some have had issues with S3 and SMP.
I've compiled minimyth with a 2.6.26 kernel and Xorg 7.4 (after fixing the version number check with 7.3 listed twice.) I have tried booting both using a local USB key and with network via pxe / pxelinux. I have the configuration set with MM_X_OUTPUT_DVI='auto'; MM_X_OUTPUT_VGA='auto'; and MM_X_OUTPUT_TV='auto'.
In both cases, while minimyth is starting, I see that no network interface found, defaulting to eth0, but that seems to be normal as it appears to happen before the kernel modules are loaded, so presumably, e1000e hasn't been loaded yet, so defaulting to eth0 will work after the modules are loaded.
In the case of network booting, the system stops responding and seems to start working with the "processing configuration file ..." message on the screen.
In the case of booting from the local usb drive, the error sometimes seems to be a bit more helpful, saying that all of the video output methods have been disabled.
I'm currently connecting the computer to the TV using an HDMI cable. The motherboard does not have a VGA port. I am going to look into getting a DVI->HDMI adapter this weekend and using the DVI port to connect to the TV instead of the HDMI port. Maybe this will keep the DVI port active.
The machine can boot up into fedora 9, are there any commands there that I can run to get a list of the DVI ports? Perhaps the DVI port is port 0 and the HDMI port is port 1 or something like that? Booting in F9, in the Xorg.0.log file, I see indications that Output VGA is disconnected, Output HDMI-1 is connected and output HDMI-2 is disconnected. I tried setting MM_X_OUTPUT_DVI to '1' instead of auto, but it fails in the same way.
Does anyone have any other ideas or suggestions?
Link to the MB:
http://www.intel.com/Products/Desktop/M ... erview.htm
The DVI <==> HDMI adapter didn't work. The screen stays blank. A DVI ==> VGA adapter works fine. The DVI port is supposed to be a DVI-D, which means that either adapter should work. I'm going to hook it back up to the TV to see if I can get HDMI audio working, it's listed in aplay -L, but I haven't tested it yet.
I must have a bug in my minimyth.conf file because when all of the MM_X_OUTPUT_* items are set to auto, it fails to start. I'll look through the scripts to figure out why that is and go from there. Even if I have to disable all of the hardware acceleration to get it working, the 3Ghz C2D should be able to handle all of my tasks for now, either playing DVDs or watching recordings.
2.6.28 kernel (gem enabled kernel)
2.5.1 xf86-video-intel driver (couldn't find out if I needed 126.96.36.199 or not)
1.0.18a alsa (should enable HDMI audio)
The sensor information for this motherboard:
[root@localhost log]# cat /sys/class/dmi/id/modalias
sensor-detect run under fedora 9 reports:
Driver `lm85' (should be inserted):
* Bus `SMBus I801 adapter at f000'
Busdriver `i2c-i801', I2C address 0x2e
Chip `National Semiconductor LM85 or LM96000' (confidence: 7)
Driver `coretemp' (should be inserted):
* Chip `Intel Core family thermal sensor' (confidence: 9)
# I2C adapter drivers
# Chip drivers
I'll be compiling 64 bit .20.2 branch until .22 comes out (nothing compelling in .21 to deserve an upgrade.)
I'm moderately optimistic that things will go well this time around.
As a bit of an update, I've been able to use this frontend under fedora 9 without HDMI audio, and without an video acceleration using xf86-video-intel 2.4.2 running on a 1080p display. It's worked ok, but has a tendency to crash using xine to play back video files not supported by mythtv.
Let me know if this is too disruptive, and I'll work on testing things as best I can...
checking for strcasecmp... yes
checking for strncasecmp... yes
checking for strcasestr... (cached) yes
checking for XDMCP... no
checking for XSERVERCFLAGS... configure: error: Package requirements (randrproto >= 1.2 renderproto >= 0.9.3 fixesproto >= 4.0 damageproto >= 1.1 xcmiscproto xextproto xproto >= 7.0.9 xtrans scrnsaverproto >= 1.1 bigreqsproto resourceproto fontsproto inputproto >= 1.4.4 kbproto >= 1.0.3 videoproto recordproto xineramaproto xkbfile xfont xau fontenc pixman-1 >= 0.9.5) were not met:
No package 'scrnsaverproto' found
No package 'videoproto' found
No package 'xkbfile' found
No package 'pixman-1' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables XSERVERCFLAGS_CFLAGS
and XSERVERCFLAGS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** [configure-work/build.d/xorg-server-1.5.3/configure] Error 1
My customized minimyth.conf.mk in ~/.minimyth/minimyth.conf.mk:
mm_GRAPHICS ?= intel
mm_GARCH ?= x86-64
mm_DISTRIBUTION_RAM ?= yes
mm_DISTRIBUTION_NFS ?= yes
mm_DISTRIBUTION_LOCAL ?= yes
mm_DISTRIBUTION_SHARE ?= yes
mm_HOME ?= $(HOME)/minimyth/gar-minimyth
mm_KERNEL_HEADERS_VERSION ?= 2.6.28
mm_KERNEL_VERSION ?= 2.6.28
mm_MYTH_VERSION ?= 0.20
mm_XORG_VERSION ?= 7.4
At the bare minimum, I do have the follwoing installed on the build machine:
[root@optimus ~]# rpm -qa | egrep -e pixman -e scrnsaver -e video -e xkbfile
==> Running configure in work/main.d/libftdi-0.15
checking for a BSD-compatible install... //home/minimyth-i686/minimyth/gar-minimyth/images/build/usr/bin/install -c
... [snip] ...
i586-minimyth-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../ftdipp -pipe -march=pentium-mmx -mtune=generic -Os -m32 -MT find_all.o -MD -MP -MF .deps/find_all.Tpo -c -o find_all.o find_all.c
mv -f .deps/bitbang_cbus.Tpo .deps/bitbang_cbus.Po
i586-minimyth-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I../src -I../ftdipp -pipe -march=pentium-mmx -mtune=generic -Os -m32 -MT find_all_pp.o -MD -MP -MF .deps/find_all_pp.Tpo -c -o find_all_pp.o find_all_pp.cpp
mv -f .deps/find_all.Tpo .deps/find_all.Po
/bin/sh ../libtool --tag=CC --mode=link i586-minimyth-linux-gnu-gcc -pipe -march=pentium-mmx -mtune=generic -Os -m32 -no-install -Wl,--as-needed -o simple simple.o ../src/libftdi.la -L/home/minimyth-i686/minimyth/gar-minimyth/images/main//usr/lib -lusb
In file included from find_all_pp.cpp:8:
../ftdipp/ftdi.hpp:22:32: error: boost/shared_ptr.hpp: No such file or directory
i586-minimyth-linux-gnu-gcc -pipe -march=pentium-mmx -mtune=generic -Os -m32 -Wl,--as-needed -o simple simple.o ../src/.libs/libftdi.so -L/home/minimyth-i686/minimyth/gar-minimyth/images/main//usr/lib -lusb
/bin/sh ../libtool --tag=CC --mode=link i586-minimyth-linux-gnu-gcc -pipe -march=pentium-mmx -mtune=generic -Os -m32 -no-install -Wl,--as-needed -o bitbang bitbang.o ../src/libftdi.la -L/home/minimyth-i686/minimyth/gar-minimyth/images/main//usr/lib -lusb
In file included from find_all_pp.cpp:8:
../ftdipp/ftdi.hpp:128: error: â€˜boostâ€™ has not been declared
../ftdipp/ftdi.hpp:128: error: ISO C++ forbids declaration of â€˜shared_ptrâ€™ with no type
...... [snip] ...
(68) optimus -> ~/minimyth/gar-minimyth/script/meta/minimyth 
Making all in daemons
make: Entering directory `/home/minimyth-x86_64/minimyth/gar-minimyth/script/system/lirc/work/main.d/lirc-0.8.4a/daemons'
...[snip, a bunch of successful compiles]...
x86_64-minimyth-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -pipe -march=x86-64 -mtune=generic -O3 -mfpmath=sse -m64 -MT receive.o -MD -MP -MF .deps/receive.Tpo -c -o receive.o receive.c
mv -f .deps/receive.Tpo .deps/receive.Po
x86_64-minimyth-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -pipe -march=x86-64 -mtune=generic -O3 -mfpmath=sse -m64 -MT serial.o -MD -MP -MF .deps/serial.Tpo -c -o serial.o serial.c
In file included from serial.c:32:
/home/minimyth-x86_64/minimyth/gar-minimyth/images/main/usr/include/linux/serial.h:164: error: expected specifier-qualifier-list before â€˜__u32â€™
make: *** [serial.o] Error 1
Is this debugging ok, or is it distracting you from a bigger picture type of issue? If this is helpful, I'm happy to continue, but I don't want to slow down overall progress. We're all wanting a 2.6.28 kernel...
SVN 4245 should fix it, but you will need to rebuild.
Also, keep posting problems that you find. They are either problems that I have yet to encounter or will not encounter (due to different build system). Having you posting them helps me track them down sooner.