The Stealth Desktop II: Sight and Sound

By Eduardo Sánchez | Jul 15, 2004 at 16:41:55

I hope that
Part I of the Stealth Desktop series was a good start for our
series about using Slackware as a desktop. I would like to thank
our kind readers for the feedback, encouragement and
suggestions.

I would like to stress that this article series was in the making long before the release of Slackware 10.0, so most of the
examples will appear as being geared to Slackware 9.1 and 9.0.
However, please bear in mind that Slackware is very consistent
among versions so you have a good chance of applying what is
shown here to the newest version. As far as myself is concerned,
I've transitioned elrohir and sombragris to
10.0 over the last weekend; and so far, so good. (On the other
hand, denethor still runs 9.0, without a flaw.)

In Part II we will focus on the hardest part: making sound and video work. Sound is not especially difficult; but video is.
Fortunately, after this step, it is an easy ride. Now, do not
despair: I said that this part is hard, not that it is arcane,
difficult to understand, or for "Unix wizards" only. It is hard
because it differs so much from other distros which have, for the
most part, better tools to do the task. But you can certainly do
it and you have a very good chance to succeed.

System setup after the first boot

The first boot leaves you with only one user in a text-only setup. When booting, look closely at the boot messages to check
for signals of trouble (and, especially if you are using
Slackware 10.0, check whether the parallel port is recognized).
As the installer and administrator of the box, having the boot
messages printed on screen instead of being hidden by a so-called
"friendly" bootsplash is not only a bonus; it is also one less
possible point of failure --the bootsplash package requires a
specially patched kernel and I've grown to distrust such an
expensive move to achieve such a frivolous gain.

Once in the login prompt, log in as root. Once you complete the login, you will be notified that you have mail. You can read
your mail using the mail command, which will show you
two messages. Both of them are important and it can be said that
both of them give good suggestions; but one of these, a message
from Patrick Volkerding, deserves special attention. Go and
read it carefully. And then save it for future reference. It
has a lot of useful information, and chances are you'll need some
of it one day.

Checking the init system

One of the first tasks you should do is checking the init system. The init system --the set of system scripts that handles
the task of starting and shutting down the machine-- is located
in /etc/rc.d/, and it is one of the striking differences between
Slackware and other distros. The Slackware init system is based
on the BSD init style, instead of the more complex SysV init that
is used in distros such as Fedora or Mandrakelinux. In stark
contrast with the SysV style init, the Slackware init scripts are
much simpler and leaner, and they're actually
understandable even if you don't know a thing about shell
scripting. They are written with the clearest syntax possible,
and they're well commented, so it is unlikely that you would get
lost in these files.

Now we are going to investigate whether we should make changes to one of these init scripts. Therefore, the one obvious
suggestion before going further is: have a backup ready.
This would save you a lot of grief in case anything goes wrong.
In order to edit the script, you might use any editor; my
personal preference lies between joe and jed,
resorting sometimes to the Midnight Commander's built-in editor
for a quick edit.

The init script you should especially check is /etc/rc.d/rc.modules/, which loads extra drivers into
the Linux kernel. You can load each module by uncommenting the
relevant entries. (In shell scripts, comments are denoted by a
hash mark, #. Deleting the hash mark makes the
line active.) As for what should be edited, it is left to you,
and it will depend on whether you have some hardware that was not
detected by the kernel or some module you want to load because
some program requires it. A special case is when you happen to
run Slackware 10.0 and have some need to use the parallel port
(especially for printing). If this is so, I advise you to
uncomment the parallel port modules; as far as I can tell, the
kernel of Slackware 10.0 comes with parallel support disabled
(Why? I don't know.).

The portion below would be the uncommented part of /etc/rc.d/rc.modules for my machines. I use the APM part
for sombragris, my laptop, and the rest would be
required by a Slackware 10.0 setup:

#### APM support ###
# APM is a BIOS specification for saving power using several different
# techniques. This is mostly useful for battery powered laptops.
/sbin/modprobe apm

#### PC parallel port support ###
if cat /proc/ksyms | grep "[parport_pc]" 1> /dev/null 2> /dev/null ; then
  echo "parport0 is built-in, not loading module" > /dev/null
else
  if [ -r /lib/modules/$RELEASE/misc/parport_pc.o 
       -o -r /lib/modules/$RELEASE/misc/parport_pc.o.gz 
       -o -r /lib/modules/$RELEASE/kernel/drivers/parport/parport_pc.o 
 -o -r /lib/modules/$RELEASE/kernel/drivers/parport/parport_pc.o.gz ]; then
    # Generic setup example:
    /sbin/modprobe parport_pc
    # Hardware specific setup example (required for PLIP and better
    # performance in general):
 #/sbin/modprobe parport_pc io=0x378 irq=7
  fi
fi

#### Parallel printer support ###
if cat /proc/ksyms | grep "[lp]" 1> /dev/null 2> /dev/null ; then
  echo "lp support built-in, not loading module" > /dev/null
else
  if [ -r /lib/modules/$RELEASE/misc/lp.o 
       -o -r /lib/modules/$RELEASE/misc/lp.o.gz 
       -o -r /lib/modules/$RELEASE/kernel/drivers/char/lp.o 
       -o -r /lib/modules/$RELEASE/kernel/drivers/char/lp.o.gz ]; then
 /sbin/modprobe lp
  fi
fi

Once you're finished with the editing, reboot in order to have these changes brought into effect. Of course, you could avoid
having to reboot by loading each module manually; but rebooting
helps you to see the whole process in the context of the init
system works. I prefer to do things that way.

Check if the sound system is working

Second order of business after logging in as root is to check whether the sound is working. Slackware 9.1 ships with ALSA 0.9x,
which is an excellent sound architecture (Slackware 10.0 ships
ALSA 1.0). However, ALSA has all the channels muted by default.
First unmute the sound and set appropriate values using
alsamixer, which is shown in Figure 2. Then check your
sound using aplay:

# aplay /usr/share/sounds/phone.wav

If the sound system is working, you will hear a phone ringing with the following console output:

Playing WAVE '/usr/share/sounds/phone.wav' : Signed 16 bit Little Endian,
Rate 44100 Hz, Stereo

In that case, you should save the mixer settings as the default ones using the alsactl store command.

Figure 2

The ALSA Mixer (only a handful of the controls are shown).

Usually, the sound system works without problem at the first boot. If it doesn't, check the documentation, available locally
at /usr/doc/alsa-*, and online at the ALSA website, which may have
some pointers useful in solving your sound problems.

Even after unmuting the sound card, it is possible that normal users might be unable to use the sound card. If that's the case,
then check the ownership of the sound card device (usally
/dev/dsp), and then add any relevant user to the same
group of the sound card (in my system, that's the 'audio' group).
We'll see how to add and manage users and groups in Part III of
the series.

Lastly, I would like to comment about a strange problem that I've experienced in elrohir and its subsequent
workaround. While working as a normal user, I had no trouble
accesing the sound card in the console. However, sound was muted
in KDE. After a lot of checking, I've found that somehow KDE
manages to put a control called 'VIA DXS' to zero. The solution
is: (1) Use KMix to unmute the relevant control and to set all
the controls according to your preferences; and (2) in the KDE
Control Center, go to Sound & Multimedia > Mixer, check
"Load volumes on login" and click on "Save Current Volumes".

Setting up the X Window System

Setting up the X Window System is always a tricky undertaking. This is furthermore complicated by the fact that Slackware does
not offer good tools to perform this task. None of the X setup
tools available in Slackware is comparable to the config tools
offered by other well-known distros such as Mandrake or Fedora.
You might, however, have more than a fair chance to get a good,
working and functional X setup with a little patience.

There are at least six ways to configure X in Slackware without having to resort to completely edit a config file from
scratch. (Note: Settings specific to X11R6.7/Slackware
10.0 are shown in parentheses.)

1. Use the default configuration: For starters, let's see whether X can start with the default configuration, using
   the startx script. If you're lucky, you'll get a
   "failsafe" X setup. It is likely going to be very slow and
   low-res, but a good start. The particulars will vary with each
   machine because the Slackware X server will try to guess
   appropriate values for your display. In some special cases, the
   default configuration might be good enough for your needs.
   
   
   
2. If this does not work, you might try the X server autoconfiguration. Type in your console the command X
   -configure in order to perform the autoconfiguration. The
   screen will blink briefly and then you will have a file named
   XF86Config.new (xorg.conf.new) in the root
   home directory. You can move this file to /etc/X11/ and rename
   it to XF86Config (xorg.conf) in order to use
   it. The config file obtained in this way is a starting point;
   but in my experience this method produced the config file that
   needed the most work and adjustments.
   
   
   
3. Use the xfree86setup (xorgsetup) script: This is essentially a wrapper around the
   -configure option of the X Window System (discussed
   above) which adds some checks for a pre-existing configuration
   and lets you choose the color depth. The resulting
   configuration file is very bare-bones but it is a starting
   point for further customization. Even though the wrapping and
   features that the script add are in fact minimal, the amount of
   work needed to bring the resulting config file to a fully
   usable status was far lower than with the previous step. This
   script was especially useful to figure out the best driver for
   some exotic or strange video chips.
   
   
   
   A screenshot of the xfree86setup initial screen is
   presented in Figure
   3. The newer utilty xorgsetup is essentially the
   same.
   
   
   
4. 
   
   Figure 3
   
   The initial screen of the xfree86setup script.
   
   
   
   
   
5. Use the xf86cfg (xorgcfg) graphical utility. This is a graphical tool, contributed by Brazilian
   distro maker Conectiva S.A., that uses X -configure as
   a starting point, and then goes on to start the X Window System
   with a number of graphical utilities using the twm window
   manager. With this toolset you can configure practically every
   aspect of the X Window System in a graphical setting, and this
   includes advanced settings such as modelines. The only drawback
   is that the tools, despite the fact that they're graphical, are
   not exactly very easy to use or intuitive. However, with a
   little effort you will be able to produce a fully customized
   config file.
   
   
   
6. Use kxconfig from KDE 3.1x. If in fact you were able to start X, chances are that almost half of your woes
   are over. If you use the stock KDE 3.1.4 system that ships with
   Slackware 9.1, and provided that you chose KDE as your default
   desktop, and provided that you were able to boot into
   KDE properly, you might use the kxconfig utility.
   Invoke the KDE command line with ALT+F2 (assuming you're using
   the standard KDE keyboard shortcuts) or with "Run Command..."
   from the K menu, and type kxconfig. This utility,
   shown in Figures 4
   and 5, is comparable
   in some ways to the X config utilities you get with other
   distributions (and in fact this little tool was contributed by
   cough Caldera cough).
   
   
   
   The kxconfig utility is reasonably friendly and easy
   to use, but its options are rather limited and, moreover, you
   should keep in mind that in order to get this app to work you
   must have a pre-existing X setup that works. Its limitations
   showed when I was unable to find the correct setting for my
   keyboard, for example, so it is not a complete solution. It may
   work for you, though.
   
   
   
   Furthermore, kxconfig was dropped from the KDE
   distribution starting with the 3.2 release. The tool was
   unmaintained and abandoned, and was deemed too complex and
   hardware-dependent for its further inclusion in KDE. So, if you
   use KDE 3.2 (as is the case of Slackware 10.0) you must look
   into other alternatives.
   
   
   
7. The xf86config (xorgconfig) tool.
   This is a small program that helps you to prepare a good X
   configuration by a walkthrough on several set of options. The
   program can generate a very good file, but it is entirely
   dependent upon your input; i.e., it doesn't do any kind of
   probing, and you must know the details of the system hardware
   before using it.
   
   
   
   I found this program very useful and in fact for me it was
   the easiest method to get a good X configuration. The only
   caveat, besides the ones I mentioned earlier, would be this.
   Note this screen in the program:
   

   Now we want to set the specifications of the monitor. The two critical
   parameters are the vertical refresh rate, which is the rate at which the
   the whole screen is refreshed, and most importantly the horizontal sync rate,
   which is the rate at which scanlines are displayed.
   
   The valid range for horizontal sync and vertical sync should be documented
   in the manual of your monitor. If in doubt, check the monitor database
   /usr/X11R6/lib/X11/doc/Monitors to see if your monitor is there.
   
   Press enter to continue, or ctrl-c to abort.
   

   The problem here is that the file referenced
   (/usr/X11R6/lib/X11/doc/Monitors) does not exist --even in
   Slackware 10.0--, so you must know beforehand the horizontal and
   vertical sync frequencies of your monitor (hint: Google is your
   friend). That issue aside, everything should work as expected.
   

Figure 4 The main screen of kxconfig. (728×569, 62K)

Figure 5 KDE's kxconfig showing the monitor selection screen. (728×569, 41K)

This ends the most difficult part of our setup. Here is an area where Slackware really needs better tools; or
perhaps it is the X Window System that needs better configuration
tools so that users and administrators would not be so reliant in
distro-specific tools. However, I hope you are able to produce a
good setup with the pointers presented here; and I trust that a
little guidance and experience can go a long way.

What's next?

Our next article will focus on how to add and manage users and groups, install fonts, and how KDE can simplify those tasks
greatly. Keep going!

Eduardo Sánchez is a Contributing Editor of Open for Business. He is married to Gloria, and lives with his
wife in Asunción, Paraguay (South America), where he works
as pastoral assistant of Villa Morra Baptist Church. You can
reach him at esanchez@ofb.biz.