Selection | Testing | Setup | Software | Top |
As much as possible, I tried to copy the working configurations from Aurora onto Iris. Here is a laundry list of software subsystems that had to be dealt with.
Users' home directories, specifically the watchtv user. [Done.] Plus the /home/video directory with saved media files. These were copied in bulk using rsync, and for the final cutover they were synced again, which went very quickly because there were few changes since the bulk copy.
XDM configuration. Including specially hacked /usr/lib/X11/xdm/libXdmGreet.so [Done.] Oops, it gets a segfault, reverting. Need to rebuild.
X-Windows configuration (/etc/X11/xorg.conf). Issues here:
Without xorg.conf, it picks radeon
driver and rejects
radeonhd
because HD 6310 is only supported by radeon
.
Good. Even so, I'm going to set up xorg.conf because I want
to be able to boot without a mouse or keyboard, for which I need
to insert devices with the void
driver. [Done.]
The names of the outputs (for radeon) are:
DisplayPort-0: Connected to TV, EDID screen size 1920x1080px, 148.5MHz dot clock, or 1360x768px 85.5MHz. Display dimensions 1600x900mm (this is a lie). It connects this port. No DPMS capability reported; disabled DPMS. (HDMI cable is connected.)
HDMI-0: No EDID on what it calls HDMI-0.
3D graphics: Initially I used the X-server native to OpenSuSE
11.4, which is xorg-x11-server-7.6_1.9.3-15.26.1 and
xorg-x11-driver-video-7.6-53.58.1 . In /var/log/Xorg.0.log it says
screen 0 is neither DRI2 nor DRI capable. There's a message No
DRI yet on Evergreen
. Evergreen is the code name of the
rendering engine in the Radeon HD 6310.
The X.org Radeon feature cross-reference says that in recent versions DRI2 is operational. The presently latest version is xf86-video-ati-6.14.3. Correlating this with SuSE build numbers is not easy.
From the SuSE Build Service I obtained their latest versions (these have to be installed coordinately because of an ABI version change):
Also a forum posting (didn't save the URL) said that proper
HDMI output requires the radeon module from kernel 3.x. I obtained
the latest reasonable kernel from the SuSE Build Service. It's a
good idea to get all your kernel packages at once because the
kernel's minor version advances every two or three weeks. I got
these versions; I think most people will only need the kernel
itself but not the sources and devel packages. The desktop kernel
has a lot of normal
modules hardwired whereas the default
kernel has everything as modules. The desktop kernel can boot
slightly faster, while the default kernel allows a lot more
flexibility in responding to screwups. Kernel version:
Also, the feature cross-reference says that audio is (no longer?) on by default; you need a module parameter of audio=1. You can make this happen by putting radeon.audio=1 on the kernel command line, or by putting a file in /etc/modprobe.d . The name is semi-arbitrary but I used 50-radeon_audio.conf with this content: (radeon space audio, not radeon dot audio)
options radeon audio=1
Now (after rebooting), disab/var/log/Xorg.0.log reports that these items were enabled:
But mesademo fire
and glxgears
produced chewed-up
video, i.e. alternate pixel rows are shifted about 16px. We're
using freeglut-100529-4.1.i586 which is the standard version and
is the latest available on the SuSE Build Service.
HDMI video output -- Works! Comparing HDMI and VGA of the same content (a static photo with greenery) at the same dot clock speed and screen resolution (1920x1080px, 148.5MHz), it's hard to be quantitative, but my impression, using a magnifying glass, is that high spatial frequencies in the X direction are rolled off so that VGA has about half the effective resolution as HDMI.
Power when showing the static photo: 16 watts. 14 watts when DPMS is engaged (monitor off).
For me there's a perennial problem: I like to stick X-Windows on VT2 (/dev/tty2). But if there's a getty on that tty, the X-server will go into an infinite loop flushing the tty and getting an I/O error. I need to remember to edit /etc/inittab to deactivate the getty on VT2 when in runlevel 5. Most people let the X-server pick an unused VT at random, so will not see this problem.
Sound issues:
HDMI audio output, will the TV perform it? Yes! See the discussion above with 3D graphics, for how to turn it on. The ALSA device is hw:1,3 or hw:0,3, depending.
AC'97 audio output, 3.5mm stereo jack in front. Works, and the TV will perform it while showing HDMI video. The ALSA device is hw:0,0 or hw:1,0.
Microphone jack, need to test it.
LIRC (infrared) configuration and startup scripts. Not working. See below under MythTV for the current status.
MySQL database for MythTV. Works.
MythTV startup and housekeeping scripts. Works.
Suspending to RAM or Disc: you need s2ram --force
because
the machine is not recognized, but it sleeps in 1 second and wakes in 2
seconds. While s2ram always flips to VT1, if you echo mem >
/sys/power/state
it suspends properly either when showing a text
console (VT1) or graphical (X-Windows on VT2). You can wake it with
Wake on LAN or by pressing a key on the USB keyboard (both of these per
BIOS setting). But don't press the power button; this will totally
confuse it, unlike on an Intel box, and to get it back you'll have to
pull the plug. In suspend state the blue circle will pulsate (unless
disabled) but the power light will be off, which is confusing.
Sometimes suspending to RAM is not successful; after waking the
machine gets into an unresponsive state. I haven't yet figured out
what sets this off. The cure
is to pull the plug and reboot.
After extensive testing I estimate that there's about a 20% probability
of getting stuck, which makes suspend to RAM kind of unuseable.
See Bios Update for how to fix
this.
Suspending to disc: either s2disk or echo disk > /sys/power/state
takes it down in 12 secs. Wake on LAN or pressing a key on the
keyboard will wake it. It goes through a complete boot sequence, but
once Linux is booted it diverts to restore the saved image. The whole
process took 27 seconds. So far, suspend to disc has been reliable.
The machine can get into a state where you can't change virtual
terminals. This is associated with a botched attempt to suspend to
RAM. The symptoms are, starting from VT2 showing X-Windows,
chvt 1
sits there forever, same with the --userwait hack,
s2ram does the same (but Ctrl-C/SIGINT breaks out of the wait and
it goes on to suspend normally), and Ctrl-Alt-F1 does nothing.
To get out of this mode, turn off the machine and pull the plug,
then reboot.
Howto pick the
arguments for s2ram. I went through most of the recommended
combinations (omitting those that were clearly doomed to failure and
did not find any that worked reliably. The most successful was to do
just s2ram --force
(no special hacks); I suspended 13 times and
it failed to wake 4 times. Running vbe_post (reinitialize the graphics
chip) surprisingly caused instant death.
On the other hand, I ran s2disk 16 times with no failures. It's slower and klunkier, but it works. This is the mode I'm going to use. (From history: the old Iris had the same issue.) Update: After I flashed the new BIOS, s2ram was fixed, so I reverted to this suspend style.
Cronj for putting the machine to sleep. Works, if you pick a working suspend style.
Webserver features:
backup.pln files. Copied, except I missed /usr/share and hence backed up a zillion bytes of crap. Fixed.
DNS: Client's /etc/named.conf needs to be set up properly. Done on Iris.
Which graphics driver am I going to use? This is a comparison of
radeon vs. fglrx.
The radeonhd driver was excluded because it does not support the
HD 6310 device. On the 3D tests, ragged
means that alternate scan
lines were shifted about 16 pixels.
radeon | fglrx | |
---|---|---|
Political Status | Open Source | Proprietary |
Supports AMD HD 6310 | Yes | Yes |
KMS (Kernel Mode Setting) | Required | Forbidden |
2D Graphics | Perfect | Perfect |
glxgears | Ragged | Perfect |
mesademo fire | Ragged 60fps | Perfect 157 fps |
Play Theora (CPU utilization on each core) | 25% + 25% | |
Play MPEG-2 | 12% + 12% | |
Play MPEG-4 | 6% + 6% | |
HDMI audio | Works | Works |
Suspend to RAM | 1/5 hang | Similar, hangs |
Suspend to disc | Perfect | Perfect |
Notes for MPEG-2 and MPEG-4 playback:
1. Wikipedia article about MPEG-2 for digital television and DVD. The video component is designated as ITU-T H.262 or ISO 13818-2. Audio is similar to MP2 but extended to 5.1 channels. MPEG-2 AAC is an alternative audio format. Transport (container) stream is ITU-T H.222.0.
2. Index of test clips for Apple QuickTime in various formats: H.264, MPEG-4, MPEG-2, 3GPP.
3. To test, I played the Apple test clips for MPEG-2 and MPEG-4 in repeat mode using Parole which uses the GStreamer engine.
Clearly the open source Radeon driver is not going to fly in this application, at least until the raggedy problem is fixed. But compiling and installing the ATI proprietary module fglrx is always traumatic and messy.
AMD website. The fancy Javascript code to select a driver fails in Chromium, but works in Firefox. To get fglrx,
The one I used was titled
AMD Catalyst® 12.2 Proprietary Linux x86 Display Driver
version 12.2 dated 2012-03-07, 105Mb. When you click on the download
link you get a self-extracting archive (shell script). Make it executable
and execute it. (Alternatively: /bin/sh
amd-driver-installer-12-2-x86.x86_64.run
.) It shows an X-Windows
GUI; take all defaults. It will take a long time (60 secs?) to produce
the kernel module and will fail.
You also need this patch to fix a compile error in fglrx, by Ginluca Gennari (gennar1), 2012-02-21. Get the 3rd version, which works on our kernel.
To build and install the module:
On SuSE 11.4 the module sources are in /lib/modules/fglrx/build_mod/ .
cd
to that directory.
patch < the_patch
. (No -p option.)
Then ./make.sh
. Output will be captured in ./make.sh.log .
Then follow instructions: cd /lib/modules/fglrx
,
execute ./make_install.sh .
The module ends up in /lib/modules/3.2.10-1-default/kernel/drivers/char/drm/fglrx.ko (with my kernel version and variant).
To make sure the fglrx module is loaded and the real
radeon
module isn't, I blacklisted the one I was not using. I already have a
file /etc/modprobe.d/50-radeon_audio.conf , and I added this line:
blacklist radeon
ALSA sound is the most frustrating of all Linux subsystems due to arcane configuration and fungoid evolution of the design. Here's what I did t get ALSA sound under control.
First, on this system there are three sound devices.
ATI HDMI audio. This is a single virtual object sending S/PDIF over the HDMI interface, on device number 3 (there is no device 0). It usually but not always becomes card 0. It is simiar to Intel Azalia and uses the snd_hda_intel driver.
Onboard ATI SoundBlaster emulation, similar to Intel Azalia and using the snd_hda_intel driver. This device sends to the front 3.5mm stereo jack (levels suitable for headphones or line out) and to the rear optical S/PDIF port, and captures from the front 3.5mm microphone jack. This device usually but not always becomes card 1.
C-Media Electronics, Inc. CM102-A+/102S+ Audio Controller (marketing name Turtle Beach) using a Realtek audio chip (can't tell which one). Although this device can accept up to 7.1 channel surround sound, its output is one 3.5mm stereo jack with levels for line out and/or headphones. Its driver is snd_usb_audio. This device usually becomes card 2.
The normal default audio device of hw:0,0 exists only rarely. Numerically based card assignments are subject to change without notice. This situation of course is unacceptable for daily use. The goal at this point is to specify the three sound devices using keys that are unique and immutable. Here is what I did to bring some sanity to the sound configuration.
If your sound devices are each served by different modules, the easiest way to nail them down is to specify the index parameter of each relevant driver; this parameter determines the card number(s). Following forum postings I tried (unsuccessfully) the following method. Look in /etc/modprobe.d . Files therein have the form: number hyphen basename .conf, e.g. 50-radeon_audio.conf . In this file I put:
options snd_hda_intel index=0,1 options snd_usb_audio index=2(Use e.g.
modinfo snd_hda_intelto determine which drivers have the index parameter.) These settings were obeyed, and if each driver served only one device this fix would have been sufficient, but I have multiple devices on the Intel driver, so I had to use a different solution. It is possible to specify a
modelparameter on the Intel driver, but I could not get it to cue on the IDs.
Next, let's look at /proc/asound/cards .
0 [Generic ]: HDA-Intel - HD-Audio Generic HD-Audio Generic at 0xfeb44000 irq 44 1 [SB ]: HDA-Intel - HDA ATI SB HDA ATI SB at 0xfeb40000 irq 16 2 [Device ]: USB-Audio - USB Sound Device C-Media INC. USB Sound Device at usb-0000:06:00.0-2.4, full speedThe integers are the card numbers, determined by the drivers' index parameters, or the order in which their respective driver modules are loaded (if the index is unspecified), which occurs in parallel threads and so is not deterministic. The third column, e.g.
USB Sound Device, comes from the idProduct attribute on USB, and I can't find it for PCI. The last whitespace separated word of this attribute gives the value for the
idattribute, which appears in the second column of /proc/asound/cards . These values are kind of lame and could easily be non-unique.
If your ID values are not satisfactory, use this solution to set the ID attributes to something consistent and unique, by a udev rule. Do this for each sound device. Pick a device inode associated with each sound device: /dev/snd/controlC2 (substitute each card number) always exists. Now do:
udevadm info --attribute-walk --name=/dev/snd/controlC2Find its ancestor that has the
idattribute, which you're going to change. The output will say something like ATTRS{id}=="Device". Now look for one grand-ancestor with unique attributes, like the vendor and product. Finally you will assign ATTR{id} (singular) (one = for assignment, 2 for comparison). Here are my rules, in /etc/udev/rules.d/26-soundJ.rules .
ATTR{id}=="*" ATTRS{vendor}=="0x1002" ATTRS{device}=="0x4383" ATTR{id}="Azalia" ATTR{id}=="*" ATTRS{vendor}=="0x1002" ATTRS{device}=="0x1314" ATTR{id}="AMD_HDMI" ATTR{id}=="*" ATTRS{idVendor}=="0d8c" ATTRS{idProduct}=="0103" ATTR{id}="TurtleBeach"
Explanation:
idattribute. ATTR not ATTRS. Singular keywords refer to the object being modified; plural ones are for the ancestor.
If you have multiple devices with the same vendor and product codes, you need to find another unique attribute to cue on. Some devices have a serial number. I believe the KERNEL uniquely identifies the port or slot that the device is plugged into, so it will be satisfactory as long as you do not move the device, which can be a problem with USB.
To make this rule effective, remove all the sound driver modules like this:
lsmod | grep ^snd_
modprobe -r -v snd_usb_audio # (pick an unused driver)
modprobe -r -v snd_hda_intel
etc. etc.; repeat from the lsmod step until all are gone.
Then reload the keystone drivers. Instead you might simplify your life by rebooting, just like on Windows. Check your work by inspecting /proc/asound/cards and make sure your ID values are now shown in the second column.
Now that you have useful ID values, you can use them like this. For the user who is going to play the sound, change to its home directory (the value of the HOME environment variable when the sound program executes). For MythTV I have a special user called watchtv. ALSA is configured from these files:
ati_hdmiis arbitrary, but avoid sleeping dragons and don't try to replace a system-defined PCM.
pcm.ati_hdmi { type hw card AMD_HDMI device 3 } ctl.ati_hdmi { type hw card AMD_HDMI } # The ! is important; without it, ALSA lib gets an error. pcm.!default pcm.ati_hdmi
You need to define both the pcm and ctl devices (mixer). While the card is normally specified as an integer, you can give the ID attribute as appearing in /proc/asound/cards . With this default override, the sound generating program will send output over HDMI no matter how the module order is randomized at boot time.
How to run setup or the frontend over a SSH connection:
mythtv-setup -geometry 640x480-0+3 -O ThemePainter=qtBut don't try to perform video because it's a total slug. It puts a borderless window at the location specified by the geometry, and the mouse cursor disappears when inside (use the keyboard).
mythfrontend -w -geometry 640x480-0+3 -O ThemePainter=qt
Database starts, backend starts and connects to it.
MythWeb can connect to the database and show its information.
You can connect to the backend status port (6544) if you use the host's IPv4 address (same as on Aurora). MythTV does not support IPv6.
Frontend connects to database and to backend.
Sound needed to be fixed, see the previous section about sound, but now it works. Frontend - General - Audio has the settings. For Output Device, you can't just fill it in; the choices are:
Playing recorded video: showing 2 half screens, as if it failed to de-interlace. See the next section for how to fix it. Ignoring the above defects, it plays 480i video.
With the default settings, playing 1080p video (MPEG-2 I think) it gets a segfault. Frontend - Utilities Setup - Setup - TV Settings - Playback - Playback Profiles needs some love. Here's what I did to it.
I activated the OpenGL paint engine (vs. qt). Bad choice: several times, every time I tried, I did mythfrontend - Setup Utility Setup - Setup - TV settings - Playback, and it froze, stays showing that menu. There's a hint that the program may have gone to the first page of that setup category but failed to show the image. I changed back to the qt paint engine. It's perfectly satisfactory on this hardware. Remember I'm using fglrx.
Selected profile CPU++ -- uses ffmpeg and XVideo (xv-blit) for everything. This only works on a powerful CPU (like the E-350), but is simple to set up because there's only one choice, so this is what I customized.
Decoder choices -- to be used to decode MPEG-2 video.
Renderer:
De-interlacer: Set it up on the next sub-page. See this
HOWTO on
de-interlacing. While it is needed for other decoders
(XvMC is one), ffmpeg includes de-interlacing, so I
left the de-interlacer as (none)
. When I tested XvMC,
the primary deinterlacer was bob-2x, which didn't de-interlace
480i content. I changed to GreedyH (1x) with a fallback to
linear blend. This combination seemed to be using CPU to
deocde the content (and play the sound), but all you could
see was Please Wait
. Same for 1080p except it used
more CPU.
Which choices will I use? Here is the CPU load as a function
of which video codec was used. ffmpeg was assigned only one core.
Even so, in the last row, both cores were over 50% utilized, each.
The de-interlacer was left at none
and it produced one complete
image (versus two, for XvMC).
Decoder | Renderer | De-interlacer | Format | Myth CPU | X CPU |
---|---|---|---|---|---|
ffmpeg x1 | xv-blit | (none) x1 | 480i | 14% | 9% |
(none) x1 | 1080p | 62% | 38% | ||
ffmpeg x1 | opengl | (none) x1 | 480i | 25% | 3% |
(none) x1 | 1080p | 96% 2x | 3% |
No more investigation, this is what we'll use. Assigning 2 cores to ffmpeg. OSD renderer changed from softblend to opengl2.
Playing commercial movie DVDs:
South Pacific (digitally remastered, don't know the digital vintage): navigation OK, played all content. This disc has a fairly long interval of black screen during introductory music, but eventually the main title appears. This also happened on Aurora. I think this has to do with Mplayer cracking the encryption.
Ratatouille (2007) showed preliminary crap but got into an infinite loop, showing the various trailers over and over. Gave up.
Crouching Tiger Hidden Dragon (2000) Please Wait
state, 14%
CPU, was not playing sound. Never got to any content. ESC was not
honored to stop this. libdvdread was taking a long time to crack the
encryption (76 secs and gave up, for one track). Likely I would have
gotten content if I had waited long enough, omitting the tracks for
which the key could not be discovered.
The theme was the default Terra
. Changed to MythCenter
Wide
and Retro-OSD
.
Microsoft wireless keyboard: does nothing. Replaced batteries, now it works.
Infrared remote control: whereas we used the Philips eHome infrared receiver on Aurora, it produced no keycodes on Iris. 99.9% sure that it's a driver problem; there's a new driver paradigm and I probably don't have it set up right. See the section on LIRC problems for its current state, but I switched to use the HDHomeRun's IR receiver.
Another line of attack: our HDHomeRun has an IR receiver. See these instructions to set up the HDHomeRun on Linux. Obtain the configuration utility from SiliconDust and compile it per their instructions. However, the configuration GUI does not configure infrared. The required hdhomerun_config program is hiding in the libhdhomerun directory and you have to install it by hand (/usr/local/bin suggested).
For my model the procedure to configure the HDHomeRun and capture the IR codes is:
hdhomerun_config discover #Prints the device ID
hdhomerun_config ${devID} get /ir/target #Shows previous setting
hdhomerun_config ${devID} set /ir/target udp://192.168.1.203:5000
#Sets where to send IR codes, give IP address where MythTV runs
lircd -H udp -d 5000
irw #Press buttons, prints received codes, ^C to exit.
On SuSE you need to set the parameters of lircd in
/etc/sysconfig/lirc ; the LIRCD_DRIVER is set to udp
and the LIRCD_DEVICE is set to 5000 (the port).
This gives us a working IR remote control.
We encountered a problem: programs were being captured, but not written
to disc. Missing filenames:
3181_20120326120000.mpg
3181_20120327180000.mpg
3181_20120327190000.mpg
Checked storage; plenty is free. For /home/video, 222Gb total, 184Gb used, 11Gb reserved for root, 27Gb available (not reserved). I also deleted about 50Gb of old programs that we couldn't watch due to Myth being unavailable (after the above df output). And rebooted Iris.
A few shows were recorded, but after a sleep-wake cycle the next show was not recorded. Forum postings indicated that whenever this symptom was seen, the problem was in the capture device. I rebooted the HDHomeRun; now shows are recorded.
After the next sleep-wake cycle, the next show was missed. Restarted mythbackend; now it records the program and two following. This pattern repeated over several days of testing, including both suspend to disc and to RAM. That's where it stands now.
The problem is not fixed, but a workaround is to stop and restart the backend when the machine sleeps. This has been effective in getting our programs recorded.
Selection | Testing | Setup | Software | Top |