In this document I describe how I set up the infrastructure for a Home Theater PC, so it can perform multimedia content.
Linux is the major competitor of Microsoft WindowsTM. Its partisans want to enjoy the use of Linux for tasks for which others use Windows, and for political reasons they want Linux to be seen to to do well in comparison. In the area of multimedia Windows performs well, much of the time, while Linux has historically been at a disadvantage.
In recent years a lot of work has been done on Linux to co-opt the areas
that Windows does well, while evading the design problems that pull down
Windows in areas where Linux does better. Late in 2008 SuSE (Novell) released
OpenSuSE version 11.1, which contains
the best results so far. Nonetheless, my out-of-box experience was far from
smooth. Perhaps the best way to characterize progress is to ask, would I
sic this product on my wife?
Not very likely, until quite a number of
issues were improved, which I describe in this document. The comments are
mostly specific to this distro version, but likely will give useful guidance
for other contemporary distros, or for versions not too far ahead or behind.
At present we have a Home Theater machine running Windows Vista with Media
Center Edition. This software has been unsatisfactory, and
MythTV on Linux
has been given a chance to prove itself. Quite a bit of the configuration was
trouble-free, but the infrastructure changes needed to make it ready for
prime time are described here. Some are what you would normally expect when
setting up a machine for a non-mainstream role, though several often turn out
to be showstoppers for less experienced system administrators, as I judge from
forum postings. Project managers should ask themselves, is my project
relevant for end users (and if not, why am I putting out the effort?) and
if so, could a grandmother with limited system administration experience
manage to install and configure it? Microsoft puts considerable effort
into making the answer yes
(not to say that the effort always succeeds),
and we Linux enthusiasts should do the same.
Problems begin before the user has even pressed a button. The home theater machine is controlled not by a conventional keyboard but from a remote control, so the first step was to install IRDA drivers and the LIRC daemon, and locate the pre-made configuration file appropriate for our remote control.
Now we have arrow keys; what will the user do with them? She wants the
display manager to start a login session for her. Specifically, she wants
to use the remote control's arrow keys to move focus to an appropriate icon,
and to then to press the OK
key to log in, without a password. This
is how it works with Windows Media Center Edition.
A truly paranoid system administrator would be horrified and would refuse
to allow any machine or user on his net that logs in without a
password, but it's a fact of life that different rules apply in the home
theater role, and requiring a keyboard is a showstopper. A system
administrator who wants to maintain marital harmony will need to use other
means to maintain internal security. In particular, I have defined a specific
account called watchtv
which is only able to run the MythTV frontend.
Several of the display managers can handle autologin, in which a particular
user is logged in unconditionally without a password, or timed login, doing
the same thing but allowing thirty seconds or so for some different user to
usurp the console. However, the home theater needs to put itself to sleep
when it is neither showing a program nor recording it, and at least on the
test machine this is not feasible unless the watchtv
user is actually
logged off the machine, precluding autologin.
So which display managers can handle the required user interaction? The recognized display managers and their dispositions are:
This is the original display manager from X11R5, but it lacks many modern features. If all the others fail, this one can probably be bent to my will.
From the K Desktop Environment
, kdm would be a
front-runner on a machine based on KDE, but I am not too familiar with
it and I would prefer to use one of the others. Several years ago kdm
messed up its use of PAM for authentication, preventing it from obtaining
the user's Kerberos ticket, and I had to give it up in favor of gdm.
Possibly the PAM problem is now fixed.
From Gnome, gdm version 2.20 is my preferred display manager from the previous version. However it had a number of very troublesome design areas, and in Gnome-2.22 it was completely rewritten, but not all the features are yet finished.
One can configure gdm to show a list of loginIDs of some or all users,
and a face
icon for each (can be a photo) may be shown. In this
mode it is feasible to select the watchtv
user using just arrow
keys and the enter
button.
However, gdm-2.24.0 from OpenSuSE 11.1 has these problems, which will/may be fixed in the future:
XML-based greeter themes (pictures, prompt text, etc.), as found in version 2.20, are no longer supported. Although it must be possible to configure a different background picture than the default, I have not yet done the research to learn how to do this.
The configuration GUI, gdmsetup, is missing. (On gdm-2.20 I hand edit /etc/gdm/custom.conf anyway.)
I have not discovered how to add arguments to the X-Server's command line. This is a problem on desktop hosts because you need to lie about the resolution to make things print right. One could override the display's physical size in xorg.conf, but there are other command line arguments that one might want.
It does not seem to obey ~/.dmrc (though that's an advertised feature, and it writes the current session type in this file), so you have to manually select a session type every time, otherwise you get the default Gnome session. This is a showstopper for the home theater use-case.
Thus I reluctantly abandoned gdm on the home theater PC.
The WINGs Display Manager
is the one remaining.
I used it previously in a project for a handheld device, and I was
impressed by its simplicity and small resource requirement. It turns
out to be satisfactory also for the home theater PC. These are its
good points:
However, the autologin user's password has to be in the
configuration file, and if it is null wdm goes into an infinite
loop. Therefore I gave watchtv
a pro-forma nonnull
password, knowing that it offers little protection because it is
present in plain text on the machine (though at least not publicly
readable).
So we have a display manager that one can log into using the home theater machine's remote control.
When the user operates the home theater PC she needs to use these hardware devices; and in more conventional machine roles the console user will need at least some of these:
Users do not automatically have permission to use this hardware. In the last three or four years the procedure for granting permission has gone through several revolutions, about one per year. In the bad old days a Linux hobbyist would simply add the relevant user (himself) to the groups assigned to these devices, but groupwise management clearly is not feasible in an enterprise or educational context. The current paradigm involves an extensive set of interacting packages:
This is an internal network by which the various components notify each other of relevant actions.
It creates all the device inodes, with ownership and permissions according to policy. Particularly, it creates an inode when a device is hotplugged, and removes it when the device vanishes. /etc/udev/rules.d contains the policies.
HAL listens for messages requesting actions which require root privilege, such as changing the permissions on a device inode, and executes or refuses them according to policy.
It provides configuration files and subroutines to read them, that HAL uses to decide which actions to allow.
When notified that a user has logged in to the console, it passes a request to HAL that the user be given access to related hardware. It is aware authoritatively when the user's session ends, and asks HAL to withdraw the permission. It can also deal with a shared machine with multiple displays, keyboards, and sound.
As part of session setup, the PAM script should execute pam_ck_connector.so, which will notify the ConsoleKit daemon that the user has logged in. There is also a dbus connection that ceases if the session ends for any reason, by which ConsoleKit knows when the session ends.
When the user logs in, the display manager
needs to configure a seat
which ConsoleKit ultimately uses to
decide which hardware the user should get permission for. For example,
on a multi-seat shared machine a particular display and USB sound unit
would go with each keyboard, and the user logging in should get
permission only for those.
In a well-configured distro like OpenSuSE 11.1, all these components work
together reliably. In particular, gdm and kdm know to do their parts in
setting up the seat
concept. However, the distro did have one
misconfiguration that denied permission to the DVD drive.
See here for what to edit to fix it. Expect an online update soon for
this problem. For completeness, the fix is to edit
/usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy
changing the access code, for active
users, for the key
org.freedesktop.hal.device-access.removable-block
from no
to yes
. DVDs are not just big CDs, however mere humans think of them,
and they appear to be more similar to removeable hard discs than to CD drives.
The wdm display manager, however, was not on the minds of the distro
managers, and it needed some help to get device permissions right.
Specifically, although PAM announces the existence of the session to the
ConsoleKit daemon, wdm does not specify the seat being used. To make this
happen, I modified some startup files. After creating a new session file
or otherwise modifying the wdm configuration you need to run
SuSEconfig --module wdm
. SuSEconfig will extract
from every .desktop file in /usr/share/xsessions the Exec line, and these will
not only be execed by wdm but they become the labels in the login
GUI (hiss, boo).
So here are the changes I made:
First I created a new startup script, /usr/local/bin/MythTV-start (link here). Then I made a new session file in /usr/share/xsessions that execs it, by copying and editing the provided mythtv.desktop. (Link to desktop file)
For my personal account I use XFCE. I modified /etc/xdg/xfce4/xinitrc to do:
exec ck-launch-session dbus-launch --exit-with-session startxfcebut with the segments conditional on what the display manager had or had not already accomplished. (Link to xinitrc file)
These fixes were mostly effective, except that the console user still did not get permission for the nVidia graphics acceleration, /dev/nvidia0. This is not surprising since this device file is created by the nVidia proprietary driver. The proprietary driver for ATI graphics cards has the same issue except it uses the more normal filename of /dev/dri/card0. Where is a file that could bring access to the console user for 3D acceleeration? My guess goes like this:
videoto do 3D rendering, unless the following hack is done.
So now the device permissions are straightened out, and we can proceed to the next area.
The main purpose of this machine is to record and play back television
programs, and I'm going to document my experiences with MythTV in a separate
page, but an important subsidiary goal is to play commercially purchased or
rented movie DVDs. The consumer thinks of the multimedia datastream as a
unified whole, but separate software performs each portion: both video and
audio, and subtitles, and sometimes other extras. Hence the designation as
multi
.
When a DVD is inserted in a Windows machine, it will be played by Windows
Media Player (except when it gets so tangled up with digital rights management
and copy protection that it refuses to play your legally owned media). The
situation is very different in Linux. Begin by reading
SuSE's explanation of the
legal situation; this page describes Xine, but all codec frameworks are
affected similarly. Quoting the page: Unfortunately there is, to our
knowledge, no legal DVD player for Linux currently sold by anyone.
USA persons who wish to scrupulously avoid breaking the law should stop reading at this point. However, the following discussion can be useful in other countries where the legal problems discussed are inoperative.
Many formats, of which MP3 is the most notorious, are covered by software patents. Microsoft has purchased, on behalf of the end user, licenses for the patented codecs; for MP3 the minimum license payment is USD $10,000 per year, or $0.50 for playback and $2.50 for compression, per licensed device, if the proposed quantity would push the payment over the minimum. An unlimited commercial license such as a distro vendor would need costs USD $50,000 per year. These amounts are trivial for a big company like Microsoft but it is prohibitively expensive for an individual to do the right thing and pay for a MP3 license.
Producing a movie is expensive, ranging up to hundreds of millions of US dollars, and the artists would like to be paid for their work. Also the financial managers, advertising companies and similar functionaries associated with the movie. To this end the studios have forced hardware and software vendors, if they want to play content on their various machines, to go along with various copy protection and digital rights management schemes. Microsoft Windows is closed source, and there is plenty of security by obscurity to prevent a hacker from intercepting the content, but it is not possible for an open source system like Linux to satisfy the studios' (justified) paranoia about their work being copied and given out with no payment to the studio.
The program that converts multimedia content to a useable form is called a
codec
, or coder and decoder. Multimedia involves, of course, multiple
codecs. First, there is a container stream, with its corresponding codec, in
which the audio, video and subtitle streams are interleaved and can be
extracted in synchrony. Then, the audio and video are compressed by a choice
of algorithms each of which has its own codec to decompress it. If you are
creating multimedia streams, as when recording analog TV, you also need
compression codecs.
To make matters more complicated, there are several codec families: four of them on the machine I'm setting up.
This codec suite is well developed and, very important for the home theater application, it has a working DVD navigation codec which can be obtained from non-USA sources, plus codecs for the commonly used patented formats. Quite a number of media players use the Xine suite beyond just the Xine player itself. Xine is on the machine because it is the suite adopted by MythTV and used to compress and play back the TV programs.
Modern media players use this codec suite. It has two big advantages over Xine. First, technically, it is self-organizing in that the media player makes a few very simple calls and GStreamer auto-detects the container and content formats and puts together a codec pipeline to send the decompressed content to the screen and the sound card. (For special cases the user can influence or completely replace the autogenerated pipeline.) Second, legally, Fluendo sells, for a very reasonable price, a legal set of patented codecs for GStreamer, greatly easing some (but not all) of the legal issues in Linux multimedia.
Since GStreamer is newer it started out with fewer codecs than Xine, but it has been catching up. Its major missing piece is the DVD navigation codec: the existing one is seriously unreliable, a rewritten open source codec is not quite ready for prime time (as this is written), and Fluendo is working on one but does not yet have it for sale. (Future readers should check the company's web site.) GStreamer is on my machine because the media player I prefer uses it, although I will be using it for music and possibly some recorded video, not DVDs.
This is an older player and codec suite, of the same general vintage as Xine. It is on the machine because it is an explicit dependency of mythvideo, the plugin for MythTV that actually plays the DVD. However, the user can override mythvideo's choice of player. I will not be using MPlayer because movie DVDs are encrypted, and its program to break the encryption takes about five minutes each time a disc is inserted, while the other three codec suites use libdvdcss which takes just a few seconds.
Produced by the VideoLAN Project, VLC is a recent but aggressively developed player and codec suite, a favorite of media engineers because it is more flexible and less fragile than other players and has good diagnostic output. While I do not have the experience to say whether it can play more formats than some of the others, it has played everything I have tried on it. It is on the machine because I plan to use it for the DVD playback task. I picked VLC because it could do the job in preliminary testing while none of the other suites could. Since then I have added non-SuSE codecs and Xine and MPlayer now can play DVDs, but I will stick with VLC because I was impressed by its functionality.
While all the codec suites can handle open source media formats and those close to the border of legality, none can play a movie DVD out of the box. What non-SuSE packages would have to be added to play DVDs? And where can one get these packages?
Here are links to the toplevel directories of some reputable package sources:
OpenSuSE Build Service. Remember to select your version of OpenSuSE before hitting the search button. Being sponsored by Novell and having mirrors in the USA, the Build Service hosts only packages that are legal in the USA.
Other distros generally have a repository for supplementary packages that are not included on the normal installation media.
Packman. Volunteer package managers build and upload new versions promptly as they come out. This site and its mirrors are in the European Union and are governed by its laws. You can configure Packman as a YaST repository so that dependencies will be obtained automatically, but Packman has a lot of packages and initializing or refreshing the package index is going to take a long time.
VideoLAN Project. This site is in France and is governed by E.U. law. Unlike with Packman, configuring VideoLAN as a YaST repository is an effective way to get all the needed dependencies; see the instructions on their site. There are repositories, or at least directories, for quite a number of distros including Windows and Mac OS-X.
Here is where you can get the various keystone packages, that is, packages that the user selects and which nothing else drags in as a dependency.
The basic package is part of the main OpenSuSE distro, but necessary additional packages are listed below.
The basic package is part of the main OpenSuSE distro, but necessary additional packages are listed below.
It is not available from the SuSE build service, and
I simply installed the whole thing from Packman. The keystone package is
called MPlayer
. Its various dependencies, listed below,
were obtained from the same source.
It is obtained from the VideoLAN website. The keystone packages (in addition to numerous dependencies) are:
While the MythTV
site has source code for downloading, prebuilt packages can be obtained
on Packman. The main package is called mythtv
while the plugins are
listed under mythplugins
.
Here is a list of optional or required dependencies of MythTV and the codec suites. I have tried to make this list complete, but I'm sure there are interlocking dependencies; in particular, the codec libraries dragged in by VLC (not shown) are surely also dependencies of some or all of the other codec suites.
plugins-goodset. Some of the DVD reading codecs are here, not the legally encumbered ones. I'm using the version from the SuSE build service, which includes the new experimental open source DVD navigation codec.
A machine to play multimedia, in particular a Home Theater PC, can actually be constructed on Linux provided one picks and configures the right window manager and other infrastructure, hacks some configuration and startup files, and finesses some legal details.
It shouldn't be like this. I hope my distro managers take notice of the Home Theater use case and provide configurations that a less experienced system administrator can install easily, and I hope my government representatives, in the coming administration with its attention to reality rather than business fantasy, will overhaul the ridiculous legal situation surrounding media formats and codecs.