I'm trying to keep the notes here generic (not distribution-specific) - so please don't ask me 'How do I do X on RedHat, Mandrake, etc...' I might actually have the answer... but the distribution-specific tools really bug me when it comes to giving out useful tips. I'd like to think I'm promoting *understanding* when I have a choice.
I hope you will never hear me say 'Click on X' when I'm talking about anything Linux/Unix =)
One other note... I'm usually pretty liberal about trying new things on my systems - and I'll definitely advocate upgrading to a newer version over fighting a battle with an antiquated setup. Just for reference... I have 2.4.2 kernels and XFree86-4.0.2 on all but one of my systems - and I strongly recommend upgrading to the latest XFree86 and kernel versions for many graphics server enhancements, USB support, and a number of other things that should make your computer more fun under Linux ;-) On the other hand... I've also run into specific problems with cheapo hardware - and your mileage may vary.
Funny this comes right after the 'Click on X' comment ;-)
So... I really don't like 'clicking around' with a mouse if I can avoid it - but I figured this was probably FAQ material that people might like to see.
You should find a lot of useful information at http://www-sop.inria.fr/koala/colas/mouse-wheel-scroll/ - and I'll just add one comment for some of the more recent versions of XFree86 (4.0.x?)
For XFree86-4.0.x? (I'm using XFree86-4.0.2) - the Pointer section in XFree86-3.3.x? configuration files is gone... and has been replaced by InputDevice sections - typically for your mouse and keyboard.
The old ZAxisMapping 4 5 in the Pointer section of an XFree86-3.3.x configuration just needs a minor adjustment to agree with the new InputDevice section:
Option "ZAxisMapping" "4 5"
I've seen comments about turning off gpm if you decide to make these adjustments for wheel-mouse scrolling, etc... but my motivation for buying a wheel mouse has always been to get a traditional middle-button paste. I guess some people really like the wheel for scrolling around - and it is definitely easy to accidentally 'click' (and cause a middle-button paste) - so I can appreciate the reasoning here.
Maybe a track-ball mouse would provide the best of both worlds without the trade-off? ;-)
Serving a Specific Printer to Windows machines via Samba
I'll probably put together a more complete Samba section later... but until then - here's a tip to serve a specific printer (or printers via Samba)
(I'm assuming you do have a working Samba setup... and you are just making this adjustment)
It's easy enough to just have Samba discover all of the printers on your machine with a typical load printers = yes line in /etc/smb.conf - but that might not be what you really want (especially if you notice that a bunch of your printer aliases are showing up attached to your Linux machine in the Windows Network Neighborhood)
So... first you want to comment out the load printers = yes in /etc/smb.conf with ; or #
Now you just need to create a share definition in /etc/smb.conf for the printer you want to serve.
The printer = lp line assumes that you already have an lp alias in your /etc/printcap file that represents a valid configured printer on the server. The lp example might seem pretty lame - but I only have one printer on my system (it could just as well be any other printer defined on your system).
If you are still wondering why I am bothering with the lp alias...
If I let Samba just scan for all the printers defined on my system... I end up with three printer aliases shared from my Linux machine in the Windows Network Neighborhood (lp, lp2, and raw) - and I thought this was pretty annoying... since they are essentially different 'modes' for the only 'real' attached printer. But... printer jobs sent to the different aliases might actually behave differently... depending on the filter the job is going through. So... lp is the most general case... and things will get sorted out from there.
The /var/spool/lpd/bjc-4200 directory needs to be created if it doesn't already exist... and you'll want to chown the directory root.lpd 775.
(chown root.lpd bjc-4200 && chmod 775 bjc-4200)
Finally... you want to restart smbd and nmbd
ps -ef | grep [sn]mbd
kill <smbd|nmbd pid(s)>
(This is the location of smbd and nmbd on my system... so you might need to make some adjustments for your own machine)
Trivial Remote Printing between Linux machines
I want to be clear that I'm only running through a very simple example for letting a number of Linux machines print to a printer attached to some other Linux machine on your network.
For example... I have a Canon BJC-4200 printer that I configured with the apsfilter SETUP script (on a Slackware 7.1 machine) - but the relevant part should be that the printer is working on the machine to which it is physically attached via a parallel cable.
So... /etc/printcap is set up correctly for 'local' printing on the machine that will act as the print server.
In order for other (Linux) machines to remotely print via 'lpd' - you need to add the 'allowed' machines to /etc/hosts.lpd
One of the Linux machines on my network is acting as nameserver and gateway for all of my other machines... but if you don't have a nameserver configured... just make sure the various machines can resolve other machine names (via /etc/hosts... if you don't have anything better)
The machine on my network acting is the print server is named rusty - so I need to edit the /etc/hosts.lpd file on rusty to include the names of the other machines that are 'allowed' to print through this machine.
(just enter the host names in /etc/hosts.lpd)
Finally... on each of the machines in /etc/hosts.lpd - I need to add an entry to /etc/printcap to indicate that I want to print to rusty.
(lp|bjc4200:\ is on one line... and the line below should fit on a single line - you might want to use \ for line continuation to make things look neater)
So... the spool directory on each machine is /var/spool/lpd/bjc4200 as written above - so you need to create a /var/spool/bjc4200 directory on each machine. The bjc4200-errs file should be created automatically under /usr/adm... when you have your first printing error ;-) - if that ever happens. Of course I assume you already have a /usr/adm directory on your system.
Again... you want to chown the /var/spool/lpd/bjc4200 root.lpd 775 as in the earlier spool example.
Finally... kill/restart lpd on all of the affected systems.
ps -ef | grep [l]pd (to show any/all lpd processes)
kill <lpd pid(s)> as necessary
/usr/sbin/lpd (restart lpd)
(That's it... go ahead and test it now ;-) )
True-Type fonts, Netscape, etc... with XFree86-4.0.2/3
If you're into 'bleeding edge' stuff... I just grabbed the latest version of the Qt libraries (2.3.0) - and the anti-aliased font support in combination with KDE 2.1 and XFree86-4.0.2 is incredible!
Here are some screenshots of KDE with AA fonts...
And a couple more... in Windowmaker - but using anti-aliasing...
I already had tons of true-type fonts for Netscape, but I noticed that KDE 2.1 didn't pick up all the fonts on my system... until I caught the note about updating your XftConfig file (/etc/X11/Xftconfig) with the modified version at http://keithp.com/~keithp/fonts/XftConfig. I just adjusted the second font path entry to point to /usr/local/share/fonts/truetype - since that's where all the truetype fonts are on my system. Here's the /etc/X11/XftConfig file that I use on a Slackware 8.0 install.
Keep in mind that the XftConfig is important for Type1 and true-type fonts, with the relevant dir entries near the top of the file looking something like
For XFree86-4.0.x - you could read some of the documentation on True-Type font support via the 'freetype' module and the ttmkfdir utility mentioned there (assuming you grab the freely available 'Web fonts' from Microsoft or some other .ttf fonts) - but you might end up going in circles before you figure out what you really need to do ;-)
It's a good idea to do a 'clean' install of XFree86... rather than install over previous versions - so I apologize if this creates a hardship for your system. My initial Linux installation is always *without* XFree86 - so this isn't a problem for me... but the popular advice seems to be that it's better to install clean if you have a previous XFree86 version installed.
So... if you are going to bother compiling XFree86 - you might as well grab the source code for the latest and greatest (4.0.2 when I'm writing this) version.
True-Type font support is accomplished with the 'xfsft' - better known as freetype (not to be confused with xfstt below or 'xtt') The only catch - you *have* to make some adjustments to build the support in the X server.
Assuming you unpacked all of the .tgz source packages - you should see an xc subdirectory. Inside the xc directory... there is an extras folder with a freetype2 directory. 'cd' into the freetype2 directory... and keep reading -
If you happen to have an older version of the freetype libraries installed... you'll want to remove it - since earlier versions are not compatible with XFree86 for the job we are trying to accomplish.
So... in the freetype2 directory - you want to do the following -
For good measure... you might want to run ldconfig to make your system notice the libraries you just installed.
Now... move back up to the xc directory... and then down to the config/cf directory. You'll want to create a host.def file with at least the following -
#define Freetype2Dir /usr/local
Finally... move back up to the xc directory and start your XFree86 compilation -
make World >& /tmp/World.log
make install >& /tmp/install.log
make install.man >& /tmp/install.man.log
You'll probably want to switch to a different terminal (Alt-F2, etc...) to watch the progress of each step in order... with something like tail -f /tmp/World.log
This *will* take a while... especially on a slower machine
Once you've compiled and installed XFree86 - you'll want to configure display stuff... so that you have a working XF86Config file.
(I used to put my true-type fonts in /usr/local/share/fonts/truetype, but /usr/X11R6/lib/X11/fonts/truetype is more consistent with XFree86, so the paths are adusted below.
Assuming you didn't get stuck on the XF86Config file... you can decide where you want to keep the true-type fonts on your system. I put my true-type fonts in /usr/X11R6/lib/X11/fonts/truetype - but it doesn't really matter.
You'll want to grab the ttmkfdir utility mentioned on the XFree86 documentation (section discussing true-type font support). There is a compiled version in the .tar.gz file... so you won't have to deal with a significant amount of work to compile the program from scratch.
I just copy the ttmkfdir.linuxbin.glibc2 binary to /usr/local/bin/ttmkfdir
The primary purpose of the ttmkfdir program is just to make it easy to create a fonts.scale file from a specific directory of true-type fonts. So... 'cd' to /usr/X11R6/lib/X11/fonts/truetype and do the following -
ttmkfdir -o fonts.scale
Next... you want to generate fonts.dir and encodings.dir file for the current directory - running the mkfontdir command with -e
mkfontdir -e /var/X11R6/lib/fonts/encodings
The /var/lib/X11R6/lib/fonts/encodings directory *might* be different on your system - worst case you should be able to find the directory with a bunch of .enc files for the fonts already on the system.
Last adjustment - add your true-type fonts directory to your XF86Config file - with an additional FontPath entry.
You also want to make sure that you're loading the 'freetype' module in your XF86Config configuration -
That's it... you can start up X and check the Fonts menu in your Netscape preferences - to verify that you now have the additional true-type fonts in your list of choices.
NOTE - I did this on three of my PC's at home... and everything worked flawlessly - copied a bunch of true-type fonts from an assortment that I had on a CD that came with my Canon printer (I knew there was good reason not to throw this out ;-)) But... on my machine at work - I didn't have my CD loaded with fonts... so I grabbed all the .ttf files from my windows\fonts directory on a dual-boot machine. I'm pretty sure the XFree86 freetype module might have been choking on some of the math fonts that were part of my Mathematica installation under Windows... but I finally tested with a smaller subset of the true-type fonts... and it worked fine.
I guess I was just lucky that I had seen my setup work before it choked at work... or I probably would've been scratching my head for even longer ;-) If you happen to be 'borrowing' fonts from your Windows installation to test if things are working... keep in mind that specific fonts might cause similar problems. Just keep in mind that I have *tons* of true-type fonts on my machines at home... and only noticed a problem on a machine at work... where I could pretty well account for the variation.
I'm really not an expert on making the true-type fonts available to other programs (via resource files, etc...) - but you can probably search for the information on google if you really want to tweak things.
My personal experience is that monospaced fonts look best in editors - but you could play around things on your own... to see if you find something you like. If you've never used the xfontsel utility to look through the fonts on your system - now is the time to check it out. xfontsel lets you select the foundry, family, and all of the other available attributes... showing a sample of the font as you go through the different choices. The select button just copies the corresponding font description to the system clipboard in a format that you can use in your resource files (.Xdefaults, .Xresources, etc...)
The actual details for tweaking the appearance of programs, menus, etc... are somewhat specific to the window manager you are using - so it's difficult to give tips that would work with a given environment. I suppose that the more user-friendly desktops like KDE or GNOME make this a little easier... if none of this sounds familiar ;-)
Keep in mind that the font anti-aliasing will not impact all of your programs... but you'll probably see the most programs if you happen to use KDE for your window manager - since KDE uses the QT libraries extensively.
It is possible to use KDE/QT applications in another window manager (my favorite is Windowmaker) - and still enjoy the font anti-aliasing if you make sure you set the QT_XFT environment variable to 1. I just add something like the following to my .bashrc file -
and somewhere near the bottom with the rest of the EXPORT statements -
(Remember you need to either run source .bashrc or just logout and login again for the changes to .bashrc to take effect)
Then I just added a shortcut for Konqueror in my Windowmaker menus... and voila! - I run Konqueror with anti-aliased fonts under Windowmaker.
You can also make Java programs look a bit better... if you set up font mappings to the true-type stuff - but I don't have a how-to for this at the moment.
XFree86-4.1.0 and true-type support
Setting up true-type fonts with XFree86-4.1.0 is very similar to 4.0.x, with a few minor adjustments -
I still recommend compiling your own XFree86 from source... but the freetype stuff mentioned in the tips above for 4.0.2/3 is built by default, so you can get away with very simple compile instructions -
make World >& /tmp/world.log
make install >& /tmp/install.log
make install.man >& /tmp/install.log
Add your true-type fonts in /usr/X11R6/lib/X11/fonts/truetype and do the regular stuff with ttmkfdir and mkfontdir in that directory.
ttmkfdir -o fonts.scale
mkfontdir -e /usr/X11R6/lib/fonts/encodings
(The second command generates fonts.dir and encodings.dir files for that directory)
Make the necessary adjustments to /etc/X11/XF86Config
Add an entry to /etc/X11/XftConfig in the dir section for your truetype directory if it's not there
(You should also notice an entry for Type1 fonts)
That's it - if you're running KDE, turn anti-aliasing on in the Look & Feel section of the Control Panel... or check out the notes about QT_XFT in the tips for XFree86-4.0.2/3 section above if you want to use anti-aliasing for KDE/QT apps in another window manager.
XFree86-3.3.x adjustments for true-type support
Grab xfstt from freshmeat, compile, and install to give yourself a true-type font server - it's not perfect, but it's a huge improvement over the stock fonts... especially for Netscape.
If you run xfstt --sync, you should get a message about the true-type fonts it is trying to look for (/usr/share/fonts/truetype) - which could just be a symlink to the Windows fonts on a multi-boot machine... or a real directory with true-type fonts.
I've found that on startup... you should give xfstt 3 - 5 seconds to process any true-type fonts before starting up the server... if your script returns success or failure for the process.
I have the following in /etc/rc.d/rc.local:
Make sure you add the following to the end of your FontPath entries in XF86Config - wherever it may be (/etc/XF86Config or /etc/X11/XF86Config)
For Netscape... I've seen all kinds of long-winded explanations, but I see the solution as the following to force 100-dpi fonts for documents:
Copy your Netscape.ad file from the directory where you have Netscape installed (/usr/lib/netscape, /opt/netscape, etc...) to /usr/X11R6/lib/X11/app-defaults/Netscape
Edit the copied file and pay attention to the comment in the file:
! To use e.g. 100 DPI fonts, change the final "*" to "100".
(changed * to 100) - make sure you actually have the 100 dpi fonts installed for XFree86 =)
Save the modified file... start up Netscape - and adjust the font preferences to taste. The 'stock' Adobe Helvetica settings look a lot better at 100 dpi, but I like to use the true-type Arial for the variable-width font... and Courier New for the fixed-width font (assuming you grabbed a typical set of true-type fonts)
Dial-Up Networking, PPP connection, etc...
I'm always amazed when people tell me they still haven't figured out how to get a dial-up connection working with a modem under Linux. Silly GUI tools aside... the easiest way I see to do this is to grab wvdial - it's a very intelligent program that will help you setup your modem, user/password settings for the connection... and it works like a charm after you configure it.
Do a query on freshmeat.net for the source, download, do a make, make install, and maybe the following suggestions:
First of all, you might want to create a 'modem' group or something similar to limit modem access to specific users.
Next do the following:
You should see it scan your serial ports and find your modem, negotiate the best setting, etc... I'm not considering 'problem' modems here, but this even works correctly on one of my cheap PCTel winmodems after the serial communications, etc... are setup correctly with driver and char major/minor settings (short explanation)
In other words... if you're having technical difficulties - you probably shouldn't blame wvdialconf
The important consideration here is that 'pppd' needs to run with root privileges, so you could change permissons on pppd to make it suid... or I see the more direct solution as making wvdial suid so that it is running with root permissions for when it needs to start pppd after it negotiates your connection. At least the '4750' root/modem permissions limit execution of wvdial to the modem group you created.
SuSE Linux has a wvdial setup utility as part of Yast, but I really don't care for the config file it creates - unnecessarily complicated to make wvdial work. A very short version created with wvdialconf without the extra bells and whistles is a lot less confusing... and it works fine.
I've been hooked on wvdial ever since I first discovered it with SuSE =)
BTW... Slackware is my distribution of choice - in case anyone gets the urge to ask me SuSE questions after the wvdial/SuSE statement. I really think SuSE is an excellent distribution... but I like Slackware better for it's clean, no-nonsense approach that leaves *you* in complete control of your own system (no training-wheels, please ;-).
After wvdial is setup... run 'wvdial' in the foreground in a terminal window to connect. I just 'roll-up' the wvdial window after I get a connection... and 'unshade' and give it a Ctrl-C when I want to disconnect.
Linux IDE/ATAPI CD-burner tips
The burner is either a real scsi device... or you need to use scsi emulation for an IDE/ATAPI drive.
On x86 Linux and many Unix variants... you want to do the following:
grab the 'cdrecord' source from http://freshmeat.net (do a search for 'cdrecord' - one word and follow the link to the homepage, etc... and download the latest source, compile, install, etc...
If you're bored - the 'cdrecord' homepage has a comprehensive set of links pointing to everything you ever wanted to know about CD-burning and all the low-level hardware details.
For an IDE/ATAPI drive... scsi emulation is accomplished with a kernel module (ide-scsi) and a couple of configuration details. I add an 'append' statement to the image section for linux in /etc/lilo.conf
If your CD-RW is a *real* SCSI device... jump down to the notes about running 'cdrecord -scanbus' now.
Adjust /etc/lilo.conf to 'ignore' your IDE/ATAPI CD-rom drive...
Example... with /dev/hdc as IDE/ATAPI cd
(/dev/hdc corresponds to secondary IDE controller, master)
The append statement tells your machine to ignore hdc as an IDE/ATAPI drive... The hdc=ide-scsi doesn't actually do anything at this point, but you'll take care of that later in the boot process.
image = /boot/vmlinuz
*NOTE* - I recently updated the kernel on my system to 2.4... and noticed some interesting behavior on the 'emulated' SCSI chain.
I assume my experience is somewhat dependent on my kernel configuration... but here is what I have at home (most of the notes here are based on a single CD-RW drive, configured as the master drive on my secondary IDE controller)
hda = hard drive
hdb = empty
hdc = IDE/ATAPI CD-RW, master
hdd = IDE/ATAPI zip drive, slave
On my 'updated' configuration... 'cdrecord -scanbus' output shows both drives on the emulated SCSI chain.
[ Insert output from home later ]
I recompiled my kernel a few times... and tried various options with SCSI and ATAPI/IDE support via 'make menuconfig', but my final attempt consisted of the following:
[ Fill in kernel configuration details ]
(Some combinations of kernel and/or SCSI configuration left me with a CD drive that wouldn't mount as expected (/dev/scd0, /dev/sr0, etc...) - even when it showed up in the 'cdrecord -scanbus' output)
For the 'final' kernel configuration... I had the following 'append' statement in /etc/lilo.conf :
After you edit /etc/lilo.conf... you need to run 'lilo' to make it rewrite LILO with the modified configuration.
Next you'll need to setup your machine to load the 'ide-scsi' module on boot. You can make the addition in a couple of places... but /etc/rc.d/rc.local is a typical choice.
/etc/rc.d/rc.local is one of the standard places to add custom site-specific commands to be executed on boot.
You probably want to check that you actually have the 'ide-scsi' (ide-scsi.o) module on your system before you bother doing much else.
All kernel modules should be organized in subdirectories below /lib/modules/
[ Add 2.4 kernel example ]
You might see a /lib/modules/2.2.16/scsi, but the module is not guaranteed to be in that directory.
If all else fails...
find . -name "ide-scsi.o"
Assuming you actually found the module... put the following in /etc/rc.d/rc.local
Notice I don't add a specific path for the module - all subdirectories below /lib/modules/
Reboot the computer so the computer starts with the modified LILO configuration.
Test the scsi emulation with 'cdrecord -scanbus' (as root)
You should see something like:
root@mymachine # cdrecord -scanbus
Cdrecord 1.8.1 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling
Using libscg version 'schily-0.1'
0,0,0 0) 'LG ' 'CD-RW CED-8080B ' '1.04' Removable CD-ROM
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
In other words... the CD-RW drive is at (controller,lun,id?) 0,0,0 on the emulated scsi bus, etc... as far as linux is concerned
You'll want to adjust your link to /dev/cdrom to point at the new scsi version of your CD-RW
if you type:
ls -l /dev/cdrom
You will probably see something like:
jbyrne@mymachine $ ls -l /dev/cdrom
lrwxrwxrwx 1 root root 9 Oct 17 16:58 /dev/cdrom -> /dev/hdc
you actually want /dev/cdrom to point to /dev/scd0 - based on the 'cdrecord -scanbus' output
*NOTE* - for the 'updated' kernel configuration, I decided on the following reality (please don't take this as gospel - these is just my own conclusion) :
The assignment of devices (/dev/scd0, /dev/scd1, /dev/sda, /dev/sdb, etc...) seems to depend on the *order of appearance* and *type* of disk as you move from 0,0,0... 0,1,0, etc...
I originally *expected* the /dev/scd[0-?] to match the corresponding LUN value on the SCSI chain... but my CD-RW drive showed up at 0,1,0... and mounted correctly at /dev/scd0 (not /dev/scd1)
Since the IDE/ATAPI zip is a different type of disk... it actually mounts at /dev/sda (ignoring the typical 'fourth' partition mounting... eg /dev/sda4 that is typical of most pre-formatted zip disks)
In other words... the emulated SCSI chain is independent of the primary/slave/master/slave configuration on the IDE controller(s)
ln -sf /dev/scd0 /dev/cdrom
ln -s /dev/scd0 /dev/cdrom
if you want to do it in two steps =)
(ln -sf is 'symbolic link', forced - overwrite previous /dev/cdrom without prompting for confirmation)
Finally... you want to adjust your CD-RW entry to point to /dev/scd0 in /etc/fstab
(addition/modification to /etc/fstab)
/dev/scd0 /cdrom iso9660 noauto,user,exec 0 0
If you prefer a different mount-point for your CD (/mnt/cdrom? instead of /cdrom) - adjust accordingly.
The 'user' option lets ordinary users (not just root) mount the cd-rw. This doesn't take care of ownership/group permissions to allow users to actually 'burn' CD's.
A possible alternative would be to create a 'cdrw' group, add the desired users, and change group ownership and permissions (660 might be appropriate?) on /dev/scd0 accordingly.
so... that should help with the hardware configuration
There are a variety of software choices (GUI's for cdrecord and others - to actually burn CD's, make ISO images, etc... (read the man pages, README's, etc... for your program of choice)
You should find tips regarding non-root cd-burning and other related information in the documentation for your burning software of choice...
Getting your sound to work with Alsa
First - I assume you downloaded the latest versions of the three related source archives - alsa-driver, alsa-lib, alsa-util, etc... from www.alsa-project.org.
bunzip, untar the sources... bzip2 -dc alsa-blah.tar.bz2 | tar xvf -
configure, compile, install the alsa-driver package first
In the same directory - run the 'snddevices' script to add the necessary devices and symlinks, etc...
Now install the alsa-lib package
Finally, install the alsa-util package
You need to set up your /etc/modules.conf before you have a hope of getting everything to work correctly.
(This is explained in the INSTALL file in the alsa-driver source - remember to substitute snd-card-intel8x0 with the appropriate module for your soundcard)
alias char-major-116 snd
alias char-major-14 soundcore
alias snd-card-0 snd-card-intel8x0
alias snd-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
The oss entries are important for programs that expect /dev/dsp, etc...
Now you can try to load some of the modules...
At the command line... run these commands one after another (as root)
Check if the modules are loaded...
(you should hopefully see a bunch of modules... including the ones you just tried to load)
All the sound channels are muted by default with alsa... so you need to run 'alsamixer' at the command line to adjust the levels.
The 'M' key will toggle the muted on/off on each of the bars for the various sound devices, arrow keys will move levels up and down, etc...
When you are done adjusting the levels... hit ESC to exit alsamixer.
If you try to play a CD, mp3, etc.. at this point... you will hopefully hear something.
To save the mixer settings... run 'alsactl store' (writes configuration to /etc/asound.conf)
Now... you want all this stuff to get loaded and have the mixer settings restored when you boot your computer...
Add a handful of lines to /etc/rc.d/rc.local (on a Slackware install... I add the 'modprobe' lines to /etc/rc.d/rc.modules near the existing sound-card area - but the solution below is more generic)
# one more line to restore mixer settings
That's it - hopefully you won't have to touch the sound again after this.
On a more general note... the typical difference between setting this up for *your* sound-card will be in replacements for the following two lines in /etc/modules.conf and /etc/rc.d/rc.modules, respectively.
(in /etc/modules.conf) might change to
and you would make a similar adjustment to the first 'modprobe' statement in /etc/rc.d/rc.local (or /etc/rc.d/rc.modules if you went witht the Slackware tip)
Also... some cards don't have midi and/or sequencer support - and you might need to eliminate the following line to avoid trying to start up the 'sequencer' related module.
SBLive Value! (probably ok with SBLive)
SB16 (I use this with an ISA PnP card - might work with newer PCI... not sure)
USB support - basic stuff (USB zip drive, keyboard, mouse)
I never played with USB devices until I started looking at the 2.4.x kernels - so I can't say with any certainty how the tips here will apply to earlier kernels that claim at least some level of USB support.
It's also difficult to present working USB scenarios... without some discussion of kernel compilation (and the potential issues in upgrading a kernel) - so if you happen to see this before it's a 'complete' section - don't blame your pitfalls on me ;-)
Worst case... take this as my intent to provide a USB section... rather than a claim that there is enough information here to guarantee *your* success.
If all else fails... you should read the related notes in the kernel source Documentation directory for specific hints that I might leave out.
Assuming you have a 2.4.x kernel built with the relevant USB, HID, USB mass storage support - I just noticed the following considerations -
First of all... you want to make sure your mouse is set up before you start gpm - or gpm will complain.
The USB mouse wants a /dev/input/mice character device with major 13, minor 63.
If you don't have such a device... you could create it by doing something like the following:
mknod input/mice c 13 63
You will need to use either usb-ohci or usb-uhci support - as a module... or compiled into the kernel... in additon to usbcore support.
(I compiled usb-ohci and usbcore support into my kernel... so I just need to take care of a few other necessities.
I put the following into /etc/rc.d/rc.modules on a Slackware installation... but you could do something similar on a more typical System V runlevel setup.
On my system... the first command also causes the input module to be loaded.
usb-[ou]hci are usbcore are implicit here... (already compiled into my kernel... so they don't need to be loaded - but you need to account for them on your machine)
I also had to adjust gpm and my X configuration slightly in consideration of the mouse device changes -
(/etc/X11/XF86Config change in "InputDevice" section)
Option "Device" "/dev/input/mice"
gpm -t ps2 -m /dev/input/mice
Now... USB Zip drive
The USB zip drive works without a hitch... with USB mass storage and related modules compiled into my kernel.
'Hot swapping' works as expected with USB - hard-drive spins for a moment... and a usb-storage-0 directory appears below /proc/scsi
Viewing /proc/scsi/scsi shows the following:
Note - I also have an internal zip drive in this system... so please make sure you are looking at the ZIP 250 entry.
In other words... the USB zip drive is at (0,0,0) and I can mount it at /dev/sda or /dev/sda4 - depending on how my zip disks are partitioned (The fourth partition is typical if you haven't changed the partition table on the disk)
One consideration... the mount point of the USB zip drive may vary - depending on whether it was attached when you booted your machine... or you added it later... after Linux was already up.
It might be useful to add an entry to /etc/fstab for the new drive -
/dev/sda /zip-usb vfat user,exec,noauto 0 0