The Stealth Desktop II: Sight and Sound

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.

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.

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.